Like SimpleSax from my previous post, SimpleForm is another simple demo component. A lot of GUIs display forms with text fields and pull-down menus. A good example is a GUI that asks for name, address, phone number, social security number, etc. For a GUI like this it is very useful to separate then Model and Controller from the View in a Model-View-Controller (MVC) architecture. This component provides a simplified example of how such a separation can be implemented. In this component the view, i.e. the topPane panel in class SimpleForm, is separate from the model, the SimpleForm instance, that actually controls the behavior and the persistence. Unlike Java Beans where the component extends a GUI, a Verdantium component like SimpleForm has a GUI through aggregation. I think this is a much cleaner architecture. It makes more sense to build topPane from an external model/controller than it does to effectively "extend" topPane.
Another problem with JavaBeans is that making the bean "extend" topPane and implement Serializable tends to create a class that serializes the details of its GUI (i.e. all the text fields, labels, etc.). Verdantium intentionally puts the persistence methods in class VerdantiumComponent so that the component only serializes its data model.
Give this one a try by loading its ".xnl" file through the Discovery component.
Monday, September 24, 2007
Thursday, September 20, 2007
Added SimpleSax component to Verdantium Downloads
One of my goals with Verdantium is to provide a large number of demo conponents so that developers have lot of examples that show how to write different applications. I've observed that a lot of other Java-enabled frameworks, particularly Jini, were not adopted (at least in part) because there were few real examples for a developer to work from, and I wanted to make sure that Verdantium did not fall into a similar trap. Toward this end, I have added the Simple Sax component as a package of the Verdantium project on Sourceforge.
The typical Verdantium object persistence serializes Externalizable objects to XML, which is good enough for most applications. However, there are occasions when one wants to persist object data in a particular XML format or in a format using a particular XML schema. Simple Sax shows how to do this. The conponent writes its data as XML text, and then reads the data back using a SAX parser. This shows how to build customized persistence into a Verdantium component. It shouldn't be hard to retrofit this to use DOM, or some other XML parser.
Like the other demo components I have blogged about previously, the easiest way to load SimpleSax into Verdantium is to use the Discovery component. By the way, someday I need to modify the Verdantium-related online help files so that they refer to using Discovery instead of making modifications to the Verdantium apps.cfg file.
The typical Verdantium object persistence serializes Externalizable objects to XML, which is good enough for most applications. However, there are occasions when one wants to persist object data in a particular XML format or in a format using a particular XML schema. Simple Sax shows how to do this. The conponent writes its data as XML text, and then reads the data back using a SAX parser. This shows how to build customized persistence into a Verdantium component. It shouldn't be hard to retrofit this to use DOM, or some other XML parser.
Like the other demo components I have blogged about previously, the easiest way to load SimpleSax into Verdantium is to use the Discovery component. By the way, someday I need to modify the Verdantium-related online help files so that they refer to using Discovery instead of making modifications to the Verdantium apps.cfg file.
Tuesday, September 18, 2007
Sent feedback to JSR-296
I sent a suggestion note to the JSR-296 people late yesterday. The archive of it is here:
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1015
I tried to keep the note very simple and concise. I could have written some very flowery sentences about compound documents, but I decided to not do that for a first E-Mail. The full text is here:
Content-Type: multipart/alternative; boundary=Apple-Mail-1--818406117
From: Thornton Green
Date: Mon, 17 Sep 2007 22:27:54 -0600
Subject: Suggestions for enhancing JSR-296
Hi,
To quote the appframework web page:
"So we're looking for feedback at this point. Constructive feedback
would be great; ranting and raving is OK too, particularly if it's
funny. We're not looking to adopt an existing framework or even for
code contributions however if there's an existing Swing application
framework you're fond of, then feedback of the form: "framework X has
a feature that JSR-296 lacks and the reason X is important is ...",
would be great."
And hence I hereby submit my suggestions. In my case, "framework X"
is Verdantium as described here:
http://verdantium.blogspot.com/
And with code posted here under GPL:
http://sourceforge.net/projects/verdantium/
http://sourceforge.net/projects/jundoruntime/
http://sourceforge.net/projects/meta/
This is an opening precis about features in Verdantium that do not
exist in JSR-296. The reason why these are important? If anybody
has questions about these items I can address them on a case-by-case
basis. Here is a partial list of features:
* Built-in Print / Print Preview / Page Setup Support
* Support for changing page size for printing (e.g. A4 versus Super-B)
* Built-in support for Printable interface
* Support for macro recording and playback
* Model-View-Controller separation of application from GUI (i.e. the
application isn't a frame).
* Better Multi-level undo. The Swing APIs implemented undo based on
the inverse-command pattern. Inverse commands are almost impossible
to write for a lot of applications. Undo really needs to be data-
driven to work across all application domains (similar to temporal
undo in JUndo).
* Visual embedding of one application within another to produce
compound documents. This allows applications to leverage each
other. I think this is very important, and it really takes advantage
of the strengths of the Java language and its ClassLoader APIs.
* Ability to embed applications directly in online help pages. This
simplifies the process of creating certain kinds of online help.
* Data oriented application loading. Framework looks at the file
being opened, and the selects the most appropriate application to
open the file.
* More support for reading and writing files in multiple formats,
including binary formats and XML.
* Better support for versioning of persistence formats.
* Larger set of lifecycle states. For instance, an embedded
application inside a container with multi-level undo can exist in
"hidden but not deleted" states that currently part of appframework.
* Support for running in MDI (e.g. JDesktopPane), as opposed to only
running in a JFrame.
* Remote loading of applications.
* More example programs. For instance, one of the applications in
Verdantium that could be used for example code is
verdantium.standard.DrawApp a drawing/container application that
support multi-level undo. I think it is important to provide several
examples of full application that provide support for container
embedding, multi-level undo, macro recording, printing, etc.
I'll stop here. I might think of more later. If you want to see
more detail, the source code for the complete framework is on
Sourceforge. I understand that you don't want to adopt a framework,
but perhaps we can find a way to cooperate.
-- Thorn
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1015
I tried to keep the note very simple and concise. I could have written some very flowery sentences about compound documents, but I decided to not do that for a first E-Mail. The full text is here:
Content-Type: multipart/alternative; boundary=Apple-Mail-1--818406117
From: Thornton Green
Date: Mon, 17 Sep 2007 22:27:54 -0600
Subject: Suggestions for enhancing JSR-296
Hi,
To quote the appframework web page:
"So we're looking for feedback at this point. Constructive feedback
would be great; ranting and raving is OK too, particularly if it's
funny. We're not looking to adopt an existing framework or even for
code contributions however if there's an existing Swing application
framework you're fond of, then feedback of the form: "framework X has
a feature that JSR-296 lacks and the reason X is important is ...",
would be great."
And hence I hereby submit my suggestions. In my case, "framework X"
is Verdantium as described here:
http://verdantium.blogspot.com/
And with code posted here under GPL:
http://sourceforge.net/projects/verdantium/
http://sourceforge.net/projects/jundoruntime/
http://sourceforge.net/projects/meta/
This is an opening precis about features in Verdantium that do not
exist in JSR-296. The reason why these are important? If anybody
has questions about these items I can address them on a case-by-case
basis. Here is a partial list of features:
* Built-in Print / Print Preview / Page Setup Support
* Support for changing page size for printing (e.g. A4 versus Super-B)
* Built-in support for Printable interface
* Support for macro recording and playback
* Model-View-Controller separation of application from GUI (i.e. the
application isn't a frame).
* Better Multi-level undo. The Swing APIs implemented undo based on
the inverse-command pattern. Inverse commands are almost impossible
to write for a lot of applications. Undo really needs to be data-
driven to work across all application domains (similar to temporal
undo in JUndo).
* Visual embedding of one application within another to produce
compound documents. This allows applications to leverage each
other. I think this is very important, and it really takes advantage
of the strengths of the Java language and its ClassLoader APIs.
* Ability to embed applications directly in online help pages. This
simplifies the process of creating certain kinds of online help.
* Data oriented application loading. Framework looks at the file
being opened, and the selects the most appropriate application to
open the file.
* More support for reading and writing files in multiple formats,
including binary formats and XML.
* Better support for versioning of persistence formats.
* Larger set of lifecycle states. For instance, an embedded
application inside a container with multi-level undo can exist in
"hidden but not deleted" states that currently part of appframework.
* Support for running in MDI (e.g. JDesktopPane), as opposed to only
running in a JFrame.
* Remote loading of applications.
* More example programs. For instance, one of the applications in
Verdantium that could be used for example code is
verdantium.standard.DrawApp a drawing/container application that
support multi-level undo. I think it is important to provide several
examples of full application that provide support for container
embedding, multi-level undo, macro recording, printing, etc.
I'll stop here. I might think of more later. If you want to see
more detail, the source code for the complete framework is on
Sourceforge. I understand that you don't want to adopt a framework,
but perhaps we can find a way to cooperate.
-- Thorn
Monday, September 17, 2007
It's Time For Open Source-- Part 2
A chinese student has recently sued Microsoft for using Windows Genuine Advantage (WGA) to infringe in his privacy. See the link below.
http://news.xinhuanet.com/english/2007-09/13/content_6718045.htm
This highlights a much bigger problem. Without the source code one simply doesn't know how much information a product (e.g. Microsoft Office) is collecting about its users and then sending back over the network to some other location like a corporate headquarters. The ability to collect information plus the ability to apply a reduced functionality mode (see my previous blogs) adds up to a lot of power.
Open source is not only THE choice for the protection of privacy, it is potentially the ONLY choice for the protection of privacy. Perhaps Verdantium, perhaps something else, but I think an open-source productivity suite makes a lot of sense today.
http://news.xinhuanet.com/english/2007-09/13/content_6718045.htm
This highlights a much bigger problem. Without the source code one simply doesn't know how much information a product (e.g. Microsoft Office) is collecting about its users and then sending back over the network to some other location like a corporate headquarters. The ability to collect information plus the ability to apply a reduced functionality mode (see my previous blogs) adds up to a lot of power.
Open source is not only THE choice for the protection of privacy, it is potentially the ONLY choice for the protection of privacy. Perhaps Verdantium, perhaps something else, but I think an open-source productivity suite makes a lot of sense today.
Finalization in the JUndo Runtime
Sun has a new article on its website about Java finalization:
http://java.sun.com/developer/technicalArticles/javase/finalization/
The JUndo runtime uses finalization methods to reclaim memory, and hence finalization issues such as those described in the above article by Tony Printezis affect the design of the JUndo runtime. The article seems to assume that finalization is used in cases where a native resource needs to be managed from within the Java Virtual Machine. The JUndo runtime is using the same finalization techniques to address a different set of problems that do not include the managing of native memory.
To understand the JUndo finalization mechanism, one needs to grasp how JUndo addresses the problem of declarative memory management. In a typical intensional language, declarations are written recursively with an expression like the following:
x = 1 fby ( 2 * ( prev x ) )
Hence, x at time=0 is 1, x at time=1 is 2, x at time=2 is 4, etc. Assuming that no high-level optimizations are performed, each calculation of "x" at time 38 in the example above requires making 37 recursive calculations. This is an expensive process, so intensional languages often use cache memory. The result for "x" at time 38 is stored after the first time it is computed, and then the cached value is used for subsequent requests for "x" at time 38. This raises the question "what items need to remain in the cache, and what items can be removed at a later time?" That is to say, is there a time when a particular item in the cache expires?
JUndo addresses the cache expiration problem in the context of object-orientation. When objects are allocated, their milieu states are added to the cache. When an assignment operation operates on the member of a class, new milieu states are added to the cache. When a particular JUndo object ID is no longer reachable all milieu states related to that object ID can be removed from the cache. Milieux also get collected. The milieu is a primitive type in the JUndo language, but it maps to a JUndo runtime ExtMilieuRef in the generated object code that executes on top of the runtime. ExtMilieuRef instances are garbage-collected by the JVM when they are no longer reachable, i.e. when they are no longer being used by any piece of JUndo code. Milieu go out of scope and/or become unused, and hence it makes sense to get rid of the underlying objects at that point.
When an ExtMilieuRef is collected all milieu states related to that ExtMilieuRef (all object creations, object changes, etc.) can also be collected. This requires some amount of processing, and hence ExtMilieuRef uses Java's finalization APIs to setup that processing. Each definition of a milieu A in terms of a milieu B (e.g. through object creation) makes a B that is access-wise identical to A with the exception of a finite set of changes (e.g. B has an object that A doesn't due to the object creation). At the time B is created A already exists in the JUndo runtime cache in the form of an EntMilieuRef. Hence, the JUndo runtime often creates an EntMilieuRef for B that contains a set of changes (e.g. the object creation) in a table, and delegates the rest of the changes to A. Even more often, the JUndo runtime will structure the delegation so that A delegates to B (rather than the other way around). However, such reversal of the direction of delegation is beyond the scope of this blog post. The important thing to understand is that performing several operations in sequence causes a linked chain EntMilieuRef delegations to be constructed in memory. That is to say, E delegates to D which delegates to C which delegates to B which delegates to A, etc.
Consider the chain running from E to A in the previous paragraph. References can become unreachable in any other in a Java program, so suppose that C gets collected first. C can't just disappear because the delegation path from D to B would be broken. Instead it changes the delegation path so that D delegates directly to B. Moreover, some of the change information that was originally in C is migrated into D. For instance, suppose that an object was created in C and D expects to be using this new object. Just because C was collected doesn't mean the object is going away. It's still valid to use that object from D and E. Hence, information about the object creation has to find its way into D.
To free its memory properly, an EntMilieuRef must know about both its delegators and its delegates. As a result, the chains of EntMilieuRef instances have bidirectional references. An EntMilieuRef can't just be left to garbage collection for this reason-- it won't collect until the chains are broken. Even if it could be collected, one wouldn't want to collect it until the chain has been properly reformatted.
The basic procedure for solving this problem is as follows. Each ExtMilieuRef points to an associated EntMilieuRef. First, the ExtMilieuRef garbage collects. When the ExtMilieuRef collects its finalization method runs, and this finalization method executes a request that asks its associated EntMilieuRef to reformat itself for garbage collection. The reformatting has to be done carefully from a thread standpoint. The finalization method is called on one thread, while the milieu delegation chains are being accessed on another one. Synchronization was ruled out as being inefficient. Instead, it is observed that Verdantium typically runs on the Swing Event Dispatch Thread. At least for the time being, the thread issue is solved by having the reformatting invoked on the Swing Event Dispatch Thread. To use the JUndo Runtime with something other than Swing, one probably should change the threading of the invocation code that causes the EntMilieuRefs to be reformatted.
In summary, the JUndo runtime solves a series of sophisticated finalization problems in order to provide efficient memory organization. This contrasts with the idea that finalization is used to manage objects that reference blocks of native memory, and code for the JUndo runtime on Sourceforge represents the current solution. The reduction in the length of the delegation chains through garbage collection also reduces the number of delegations through which the runtime might need to perform a lookup. As a result, there is a significant performance benefit in addition to the efficient finalization of unused memory.
http://java.sun.com/developer/technicalArticles/javase/finalization/
The JUndo runtime uses finalization methods to reclaim memory, and hence finalization issues such as those described in the above article by Tony Printezis affect the design of the JUndo runtime. The article seems to assume that finalization is used in cases where a native resource needs to be managed from within the Java Virtual Machine. The JUndo runtime is using the same finalization techniques to address a different set of problems that do not include the managing of native memory.
To understand the JUndo finalization mechanism, one needs to grasp how JUndo addresses the problem of declarative memory management. In a typical intensional language, declarations are written recursively with an expression like the following:
x = 1 fby ( 2 * ( prev x ) )
Hence, x at time=0 is 1, x at time=1 is 2, x at time=2 is 4, etc. Assuming that no high-level optimizations are performed, each calculation of "x" at time 38 in the example above requires making 37 recursive calculations. This is an expensive process, so intensional languages often use cache memory. The result for "x" at time 38 is stored after the first time it is computed, and then the cached value is used for subsequent requests for "x" at time 38. This raises the question "what items need to remain in the cache, and what items can be removed at a later time?" That is to say, is there a time when a particular item in the cache expires?
JUndo addresses the cache expiration problem in the context of object-orientation. When objects are allocated, their milieu states are added to the cache. When an assignment operation operates on the member of a class, new milieu states are added to the cache. When a particular JUndo object ID is no longer reachable all milieu states related to that object ID can be removed from the cache. Milieux also get collected. The milieu is a primitive type in the JUndo language, but it maps to a JUndo runtime ExtMilieuRef in the generated object code that executes on top of the runtime. ExtMilieuRef instances are garbage-collected by the JVM when they are no longer reachable, i.e. when they are no longer being used by any piece of JUndo code. Milieu go out of scope and/or become unused, and hence it makes sense to get rid of the underlying objects at that point.
When an ExtMilieuRef is collected all milieu states related to that ExtMilieuRef (all object creations, object changes, etc.) can also be collected. This requires some amount of processing, and hence ExtMilieuRef uses Java's finalization APIs to setup that processing. Each definition of a milieu A in terms of a milieu B (e.g. through object creation) makes a B that is access-wise identical to A with the exception of a finite set of changes (e.g. B has an object that A doesn't due to the object creation). At the time B is created A already exists in the JUndo runtime cache in the form of an EntMilieuRef. Hence, the JUndo runtime often creates an EntMilieuRef for B that contains a set of changes (e.g. the object creation) in a table, and delegates the rest of the changes to A. Even more often, the JUndo runtime will structure the delegation so that A delegates to B (rather than the other way around). However, such reversal of the direction of delegation is beyond the scope of this blog post. The important thing to understand is that performing several operations in sequence causes a linked chain EntMilieuRef delegations to be constructed in memory. That is to say, E delegates to D which delegates to C which delegates to B which delegates to A, etc.
Consider the chain running from E to A in the previous paragraph. References can become unreachable in any other in a Java program, so suppose that C gets collected first. C can't just disappear because the delegation path from D to B would be broken. Instead it changes the delegation path so that D delegates directly to B. Moreover, some of the change information that was originally in C is migrated into D. For instance, suppose that an object was created in C and D expects to be using this new object. Just because C was collected doesn't mean the object is going away. It's still valid to use that object from D and E. Hence, information about the object creation has to find its way into D.
To free its memory properly, an EntMilieuRef must know about both its delegators and its delegates. As a result, the chains of EntMilieuRef instances have bidirectional references. An EntMilieuRef can't just be left to garbage collection for this reason-- it won't collect until the chains are broken. Even if it could be collected, one wouldn't want to collect it until the chain has been properly reformatted.
The basic procedure for solving this problem is as follows. Each ExtMilieuRef points to an associated EntMilieuRef. First, the ExtMilieuRef garbage collects. When the ExtMilieuRef collects its finalization method runs, and this finalization method executes a request that asks its associated EntMilieuRef to reformat itself for garbage collection. The reformatting has to be done carefully from a thread standpoint. The finalization method is called on one thread, while the milieu delegation chains are being accessed on another one. Synchronization was ruled out as being inefficient. Instead, it is observed that Verdantium typically runs on the Swing Event Dispatch Thread. At least for the time being, the thread issue is solved by having the reformatting invoked on the Swing Event Dispatch Thread. To use the JUndo Runtime with something other than Swing, one probably should change the threading of the invocation code that causes the EntMilieuRefs to be reformatted.
In summary, the JUndo runtime solves a series of sophisticated finalization problems in order to provide efficient memory organization. This contrasts with the idea that finalization is used to manage objects that reference blocks of native memory, and code for the JUndo runtime on Sourceforge represents the current solution. The reduction in the length of the delegation chains through garbage collection also reduces the number of delegations through which the runtime might need to perform a lookup. As a result, there is a significant performance benefit in addition to the efficient finalization of unused memory.
Friday, September 14, 2007
There is a lot of overlap between Verdantium and the proposed JSR-296 Specification
Verdantium and JSR-296:
http://jcp.org/en/jsr/results?id=3801
are trying to solve similar problems. JSR-296 is trying to provide a framework for Swing applications running as standalone entities from a main() method. Verdantium provides a framework for application COMPONENTS-- classes that can run as standalone applications (they have a main() method) but are also flexible enough to be visually embedded inside other applications.
There is a lot that JSR-296 could learn from looking at the current Verdantium implementation on Sourceforge and/or this blog. The scope of Verdantium is in many ways larger than what JSR-296 is proposing. For instance, Verdantium has lifecycle states related to embedded components participating in multi-level undo that do not exist in the current proposal for JSR-296.
While there is still time, perhaps it would be in the best interest of the future of the Java platform if Verdantium and JSR-296 interacted and shared information in some useful way. I'm looking at joining the JCP, and hopefully people associated with JSR-296 might look at this post and/or my code on Sourceforge for ideas.
To be continued in a subsequent post...
http://jcp.org/en/jsr/results?id=3801
are trying to solve similar problems. JSR-296 is trying to provide a framework for Swing applications running as standalone entities from a main() method. Verdantium provides a framework for application COMPONENTS-- classes that can run as standalone applications (they have a main() method) but are also flexible enough to be visually embedded inside other applications.
There is a lot that JSR-296 could learn from looking at the current Verdantium implementation on Sourceforge and/or this blog. The scope of Verdantium is in many ways larger than what JSR-296 is proposing. For instance, Verdantium has lifecycle states related to embedded components participating in multi-level undo that do not exist in the current proposal for JSR-296.
While there is still time, perhaps it would be in the best interest of the future of the Java platform if Verdantium and JSR-296 interacted and shared information in some useful way. I'm looking at joining the JCP, and hopefully people associated with JSR-296 might look at this post and/or my code on Sourceforge for ideas.
To be continued in a subsequent post...
Thursday, September 13, 2007
Re-adopted opensourcecomponents Yahoo Group
In the past I used to moderate an opensourcecomponents Yahoo group related to Verdantium and similar technologies. Later I got too busy to fuss with it, Yahoo seemed to be deteriorating in general, and the group only had about five members anyway.
I just happened to be visiting Yahoo recently, and to my great surprise I found that the site seemed to have gained its own momentum (30+ people have joined). Moreover, Yahoo seems to have improved. Or at least it seems to be better about accepting my password. I'm updating the original group profile, and integrating it with this blog. Hopefully, this will provide a place for people who are interested in this blog to interact.
Yes, people could interact by posting comments to this blog. And yes, I could use the discussion group features related to the Sourceforge projects for Verdantium, Meta, etc. Yahoo seems to be more popular, though. I will probably try to funnel discussion to either this blog or the Yahoo group. I don't think I could handle posts on multiple discussion groups hosted by multiple Sourceforge projects. That would require more time than I have. Besides, I want to use my time to write more code.
The discussion group is here:
http://tech.groups.yahoo.com/group/opensourcecomponents/
Sign yourself up! Things blogged here should cross-post to the Yahoo group.
I just happened to be visiting Yahoo recently, and to my great surprise I found that the site seemed to have gained its own momentum (30+ people have joined). Moreover, Yahoo seems to have improved. Or at least it seems to be better about accepting my password. I'm updating the original group profile, and integrating it with this blog. Hopefully, this will provide a place for people who are interested in this blog to interact.
Yes, people could interact by posting comments to this blog. And yes, I could use the discussion group features related to the Sourceforge projects for Verdantium, Meta, etc. Yahoo seems to be more popular, though. I will probably try to funnel discussion to either this blog or the Yahoo group. I don't think I could handle posts on multiple discussion groups hosted by multiple Sourceforge projects. That would require more time than I have. Besides, I want to use my time to write more code.
The discussion group is here:
http://tech.groups.yahoo.com/group/opensourcecomponents/
Sign yourself up! Things blogged here should cross-post to the Yahoo group.
Posts on blog should cross-post to opensource components.
Posts on blog should cross-post to opensource components.
Wednesday, September 12, 2007
Microsoft Reduced Functionality Mode-- It's Time for Open Source Software
Microsoft has recently announced that it has activated a "Reduced Functionality Mode" for Windows that allows it to defunctionalize particular copies of Microsoft Windows. It is also believed that Microsoft will extend their technology for "reduced functionality" to other products such as Microsoft Office (if they haven't done so already). According to the following news report:
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9035478
the reduced functionality includes reducing one's computer to a black screen after one hour of browsing, no start menu or task bar, and no desktop.
Certainly this is legal, conforms with Microsoft license agreements, etc. But who's to say that the functionality will only be reduced for legitimate purposes? Suppose Microsoft doesn't want people using Google. Who is to say Microsoft couldn't defunctionalize Windows for those people? Suppose Microsoft doesn't like your business. Who is to say Microsoft couldn't defunctionalize all of your copies of Windows? The only way to know for sure is to look at the source code, and Microsoft always jealously guards the source code so that nobody knows the extent to which functionality can be reduced. One could seek remedy using a civil suit against Microsoft, but the suit would drag on for years. Meanwhile, you have no working computers and no revenue. And of course the fact that you signed your life away by accepting Microsoft's license agreement will be raised in court. Your business will probably end its death spiral before the case is resolved (i.e. shades of Stac vs. Microsoft).
One of the advantages of open source projects over software such Microsoft Office is that in the open source world there isn't a large entity that can remotely defunctionalize your software. You can see the source code. Other people can see the source code. There are no surprises. I think the time for open-source productivity software has come. Perhaps Verdantium, perhaps something else. But definitely something that can't be defunctionalized on a whim.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9035478
the reduced functionality includes reducing one's computer to a black screen after one hour of browsing, no start menu or task bar, and no desktop.
Certainly this is legal, conforms with Microsoft license agreements, etc. But who's to say that the functionality will only be reduced for legitimate purposes? Suppose Microsoft doesn't want people using Google. Who is to say Microsoft couldn't defunctionalize Windows for those people? Suppose Microsoft doesn't like your business. Who is to say Microsoft couldn't defunctionalize all of your copies of Windows? The only way to know for sure is to look at the source code, and Microsoft always jealously guards the source code so that nobody knows the extent to which functionality can be reduced. One could seek remedy using a civil suit against Microsoft, but the suit would drag on for years. Meanwhile, you have no working computers and no revenue. And of course the fact that you signed your life away by accepting Microsoft's license agreement will be raised in court. Your business will probably end its death spiral before the case is resolved (i.e. shades of Stac vs. Microsoft).
One of the advantages of open source projects over software such Microsoft Office is that in the open source world there isn't a large entity that can remotely defunctionalize your software. You can see the source code. Other people can see the source code. There are no surprises. I think the time for open-source productivity software has come. Perhaps Verdantium, perhaps something else. But definitely something that can't be defunctionalized on a whim.
Monday, September 10, 2007
Creating Non-Rectangular Visual Components in Verdantium
Subclasses of java.awt.Component have rectangular bounds, but within those bounds a component can have a non-rectangular shape. Sun documented this capability but I am not aware of Sun releasing any demonstration classes that take advantage of it. Non-rectangularly shaped components fit perfectly into the Verdantium paradigm, so I do provide example code for this seldom-used feature of the JDK. See the NonRectangular package of the Verdantium download.
In the NonRectangular demo component, I chose a circular shape for the non-rectangular component because it was the simplest non-rectangular shape to implement (I try to keep things as simple as possible). However, any arbitrary shape is possible. A non-rectangular JComponent usually has three things:
* A transparent background.
* An overridden paint() method that draws the non-rectangular shape (and possibly an overridden update() method that calls the paint() method).
* Optionally, an overridden contains() method that returns whether the mouse position is inside the shape.
Because of the transparency of the background, the isOpaque() method of the JComponent should return false. For some JComponents, calling setOpaque() will work. For others, isOpaque() may need to be overridden to return false. Transparency essentially means that the JComponent element doesn't do an initial fillRect() on its extent before calling paint()-- there isn't much point to making something non-rectangular if the surrounding rectangular bounds get filled anyway.
The paint() method is where the non-rectangular shape is shown to the world. Java-2D provides general APIs for doing this.
The contains() method is a rather strange and interesting invention from Sun. In several other APIs that perform similar tasks (e.g. collision detection in Sun's own Java-3D), the geometry is passed to the framework and then the framework solves the inside/outside/collision relationships using a high-efficiency algorithm (e.g. binary space partitioning). Instead, AWT polls your JComponent every time the mouse is moved to determine if it is inside or outside the non-rectangular shape. If your shape contains complex geometry, then you get to write your own space partitioning framework in order to make inside/outside calculations efficient. What you need to do is the following: override contains() so that it returns true iff. the X-Y position in the parameters is inside your non-rectangular shape. If this is properly implemented, then AWT will send your JComponent mouse entry/exit events when the mouse enters and leaves your non-rectangular shape.
That covers it. The ability to display non-rectangular components has been a differentiator for component frameworks such as OpenDoc, so give this a try.
In the NonRectangular demo component, I chose a circular shape for the non-rectangular component because it was the simplest non-rectangular shape to implement (I try to keep things as simple as possible). However, any arbitrary shape is possible. A non-rectangular JComponent usually has three things:
* A transparent background.
* An overridden paint() method that draws the non-rectangular shape (and possibly an overridden update() method that calls the paint() method).
* Optionally, an overridden contains() method that returns whether the mouse position is inside the shape.
Because of the transparency of the background, the isOpaque() method of the JComponent should return false. For some JComponents, calling setOpaque() will work. For others, isOpaque() may need to be overridden to return false. Transparency essentially means that the JComponent element doesn't do an initial fillRect() on its extent before calling paint()-- there isn't much point to making something non-rectangular if the surrounding rectangular bounds get filled anyway.
The paint() method is where the non-rectangular shape is shown to the world. Java-2D provides general APIs for doing this.
The contains() method is a rather strange and interesting invention from Sun. In several other APIs that perform similar tasks (e.g. collision detection in Sun's own Java-3D), the geometry is passed to the framework and then the framework solves the inside/outside/collision relationships using a high-efficiency algorithm (e.g. binary space partitioning). Instead, AWT polls your JComponent every time the mouse is moved to determine if it is inside or outside the non-rectangular shape. If your shape contains complex geometry, then you get to write your own space partitioning framework in order to make inside/outside calculations efficient. What you need to do is the following: override contains() so that it returns true iff. the X-Y position in the parameters is inside your non-rectangular shape. If this is properly implemented, then AWT will send your JComponent mouse entry/exit events when the mouse enters and leaves your non-rectangular shape.
That covers it. The ability to display non-rectangular components has been a differentiator for component frameworks such as OpenDoc, so give this a try.
Sunday, September 9, 2007
Extending Java Beans to support a Compound Document Model: Project Verdantium
This is a paper that I wrote years ago for the OOPSLA conference as a representative of Arizona State University. It was rejected for publication mainly due to some of the comments it made about XML. My more recent comments/observations are in brackets: "[ text ]".
Extending Java Beans to support a Compound Document Model: Project Verdantium
Thornton Green
Arizona State University
ABSTRACT
Client-side visual Java Beans are poorly suited to the implementation of document-level software components such as text editors. This reduces the applicability of visually displayed Beans, limiting the client-side API primarily to a means for interchanging widgets between different integrated development environments (IDEs). By using an alternate API (Verdantium) for the embedding of beans in a visual context, clients-side code can implement a full compound document display model while leaving server-side APIs (Enterprise Java Beans) and the fundamental bean property model unchanged. Fully functional applications (i.e., word processors, illustration programs, equation editors, etc.) can be implemented as individual software components that can either run independently or be embedded in other applications using the same API. [Java Beans hasn't changed much since this was written; all of this is still true today]
Keywords
Component software, compound-documents, embedding, Java Beans.
1. INTRODUCTION
When Sun introduced the original container application for visually embedded Java Beans [5, 14, 16 18], the Bean Box, it included as sample components a couple of buttons, a molecule viewer, and some other components with a similar level of sophistication. Since then, little has changed. The APIs introduced by the Bean Box have been used as a way to build applications from simpler widgets in a development environment, but have not led to the widespread sharing of visual components between Java applications outside of the software development world. The term “widget” refers to a subclass of java.awt.Component (or its equivalent in another framework). This paper sometimes uses “widget” instead of “component” so that the term “component” can be used in the context of component software.
To understand the problem, one must first answer the question, “what is a Java Bean?” There are three different senses in which the term “Java Beans” tends to be used:
* As a programming standard for specifying “get” methods, “set” methods, property change events, etc [18]. The resulting components can be visually manipulated regardless of whether the have GUIs. For instance, a ComboBoxModel can be manipulated in Symantec Visual Café [22].
* As a server-side API for interacting with transaction environments and legacy code (Enterprise Java Beans) [16].
* As an API (on the client side) for subclasses of java.awt.Component to be read by the Bean Box (or similar program) from a jar file.
It is the latter of the three that creates problems for document embedding. Container applications that emulate the functionality of the BeanBox are difficult to write. Further, pure Java implementations of bean containers have inherent display problems. Many visual beans are “heavyweight” widgets, making it difficult for the pure Java container app. to superimpose a resize widget over the top of the bean.
Support for native or legacy file formats is lacking in the visual beans’ persistence standards. A class written for the Bean Box can serialize itself by implementing one of two interfaces, Serializable or Externalizable. Neither of which can support foreign file formats, unless they are object-based. This means that for example a text editor bean would need a second entirely separate persistence mechanism in order to load or save plain text files saved on the local disk. There is also no built-in mechanism for two beans to support the same persistence format. For instance, a PDF distiller bean can not serialize itself in such a way that the serialized format will be read by the free PDF reader bean when opened. Instead, the identity of the object’s class (in this case the PDF distiller bean) is “hard-coded” into the persistent data. When the file is loaded from persistent storage, the hard-coded class is used to read the object data. [Sun effectively deprecated Externalizable for XML object persistence, and uses a new system for XML. Nevertheless, the above is still true for non-XML formats.]
The way that beans are embedded into a container also presents a number of less fundamental problems that nevertheless present a series of practical difficulties. One of them is the use of subclassing of AWT components (i.e. widgets) to create beans. One of the original articles on the JDK 1.1 event model, [17], states “subclassing should be reserved for circumstances where [AWT] components are being extended in some functional or visual way.” Java Beans do not adhere to this principle. To make a bean that can be displayed in the Bean Box, the developer must subclass a widget regardless of whether she intends to extend the base widget in a functional or visual way. To quote this same page again, subclassing of AWT components “does not lend itself well to maintaining a clean separation between the application model and the GUI because application code must be integrated directly into the subclassed components at some level.” To be fair, the latter quote is referring more to using subclassing to handle events. However, it would also seem to apply to subclassing widgets in order to use them as visual beans. Any methods that talk to an interface implemented by the bean or to the bean’s “get/set” methods must necessarily go through the subclass of the widget, and can not be routed directly to the application code.
Because the APIs for visually displayed beans were created with the assumption that heavyweight widgets could be used, there is no unified API support for beans that are visually transparent. This makes it difficult for a text label bean to overlay (with a transparent background) the display content of a graphics bean with predictable results. Unfortunately, even the most basic presentation software requires this capability from its components. For instance, imagine how ugly a Microsoft Powerpoint presentation with a gradient-filled background would look if all the text labels had individual opaque rectangular backgrounds of a single color. As a practical matter, transparency support is necessary for getting useful results from visual components in a variety of situations.
Multi-page printing also presents a problem from a practical perspective. A Java Bean has one method, print(), with which to print itself into a graphics context. Unlike the APIs generally available to applications, the print() method does not support multi-page printing because it is a widget-level operation as opposed to a document-level operation. This gives the writer of the bean two choices: restrict the bean to something that only prints single pages, or implement a custom set of printing routines entirely separate from the Beans APIs.
The ability to read previous versions of the serialized state of a bean can be difficult to accomplish. The Serializable and Externalizable interfaces attach versioning information to the persistent state of a class based upon the bytecode information of the classes being serialized. If the bytecode of the class changes even slightly, older serialized files are no longer compatible. This can be remedied to an extent by defining the serialVersionUID field of each class. This will make the class able to read serialized information made by any other version of the class using the same serialVersionUID. However, this does not in itself solve the versioning problem. The class must still read a set of objects from a linear stream, attempt to ascertain which version of the software these objects refer to, and employ some type of filter to derive meaningful data from the object stream. Filtering data from a linear stream of objects can be difficult because in general there are no tags indicating what instance member name each object of the stream belongs to. As a result, it may be very difficult to derive the proper meaning from the object stream when two previous versions of the class had similar but not identical formats, and several instance members of the same class. [XML persistence using Serializable no longer seems to be using serialVersionUID.]
2. THE SOLUTION
Verdantium, a prototype API based on a set of software components the author developed to support his Ph. D. dissertation [10], extends client-side beans by implementing a compound-document model for visual components. The idea behind this model is to be able to construct complex documents by having a series of software components (beans) working together to represent the document’s various parts. For instance, a word processor and its equation editor can be separate beans that cooperate to allow the user to insert equations into a paper that she is editing. Instead of having very large monolithic applications as illustrated in Figure 1, a series of smaller beans cooperate to replicate the functionality typically seen in large applications. The construction of documents using components is more flexible because components for editing different parts of a document can be added and/or interchanged.
Figure 1 An example of modern software with all of its toolbars turned on. Taken from a screenshot of a 800 x 600 display. Note the amount of functionality that has been packaged in a single monolithic application.
Verdantium’s document model is implemented using the Model-View-Controller (MVC) philosophy. That is to say, the user interface for a certain kind of document is kept separate from its application logic [7]. Beans that are displayed in the Bean Box are subclasses of a view class, with no inherent support given to the underlying model. The VerdantiumComponent by contrast is a Java interface implemented by the model class, with the GUI stored in a separate object (though one may optionally integrate the two). The major design principles supporting the use of an interface are flexibility and pluggability as noted in [4]. Components based on interfaces are more flexible because they can extend any chosen base class, and they are pluggable in the sense that one implementation of an interface can be replaced by another that uses the same methods. One important aspect of the flexibility of using an interface is that the VerdantiumComponent does not need to subclass a widget. Instead, the user interface of the VerdantiumComponent is the Swing JComponent returned by the VerdantiumComponent’s getGUI() method.
package verdantium;
import javax.swing.*;
import java.awt.*;
import java.awt.datatransfer.*;
public interface VerdantiumComponent extends
EtherEventHandler
{
public JComponent getGUI();
public void handleDestroy();
public DataFlavor[]
getPersistentOutputDataFlavorsSupported( );
public void loadPersistentData( DataFlavor flavor ,
Transferable trans );
public Transferable savePersistentData(
DataFlavor flavor );
}
Figure 2 The definition of a VerdantiumComponent.
The defintion of a VerdantiumComponent is as given in Figure 2, where EtherEventHandler is a Verdantium-defined interface for handling scriptable events. The simplest Verdantium components do not need to handle any such events, and can simply provide a stub implementation of EtherEventHandler’s only method. In addition, a VerdantiumComponent capable of being used in a compound document must have a null constructor, and implement one required method not shown in the listing above. The method’s signature is as follows:
public static DataFlavor[]
getPersistentInputDataFlavorsSupported( )
This method is called at runtime using the Java Reflection API. By studying the interface definition above, one can see that every VerdantiumComponent must do three basic things. It must present a Swing GUI, it must be able to handle its own destruction, and it must be able to support a persistence architecture based on AWT’s Transferable and DataFlavor concepts. Different components implement the same interface, but provide different behaviors. In other words, the interface provides the basis for implementing a Strategy pattern with respect to multi-flavor persistence and GUI presentation [9].
The mandatory use of Swing widgets to implement Verdantium GUIs greatly simplifies the implementation of the overall framework. Heavyweight widgets make certain kinds of controls difficult to implement because the heavyweight widgets tend to display in front of any widget that does not have a peer [This has generally been true since JDK 1.1, but Sun announced during a session at JavaOne 2007 that they wanted to change this. For essentially all current JDK implementations this is still they way Java Z-Orders heavyweight instances of jaav.awt.Component]. Because Swing widgets are entirely lightweight, there are fewer problems to contend with when attempting to design controls that resize or translate the widgets. For example, Swing already provides JDesktopPane and JInternalFrame classes that implement Multiple-Document Interface (MDI) resize controls on other Swing widgets in a robust manner.
2.1 Persistence Support
To support persistent storage, a VerdantiumComponent reads and writes Transferable objects in multiple data flavors. The use of the Transferable object in the loading and storing of persistent states can be thought of as similar to the Memento pattern in [9]. The Transferable object is the Memento, the VerdantiumComponent is the originator, and the persistence system is the Caretaker. The main differences are that the VerdantiumComponent does not have to deal with a constraint solver in the same sense as the systems that served as the motivation for the Memento pattern, and that the VerdantiumComponent contains support for through data flavors for creating Transferable data in multiple formats.
The data flavors that a component can support fall into two general types. The first type is object data intended to be read from or written to a Java object stream. This allows the component to use the standard Java Beans persistence mechanism with Serializable objects. However, there is an important semantic difference between Verdantium’s object serialization and that in client-side beans. Client-side beans tend to serialize data from the widgets they inherit from, including the full view hierarchy. This has two problems. First, Swing widgets tend to store a very large amount of data to persistent storage. Much of this information is of little real use to the overall application. Second, Swing’s persistence format is still under revision as of Java 2. Verdantium components avoid these problems because they serialize the model, not the view. For instance a text editor component serializes the text of the document, not the details of the view hierarchy. There is a drawback in that the Verdantium component has to do more work to load a file than its bean counterpart. Sometimes a component written in Verdantium has to take a representation of a document and map it to an appropriate set of widgets and layout managers, or vice versa . However, the author feels that the benefits outweigh the drawbacks. [In recent versions of Verdantium the format for this has shifted from binary object streams (i.e. class ObjectOutputStream) to XML object streams. Newer versions of Verdantium also contain logic that map most implementations of Externalizable to XML. The author feels that Externalizable is much simpler, more elegant and more object-oriented than Sun's XML callback mechanism, and hence it makes sense to use the XML callback mechanism to bridge Externalizable into the XML format.]
The second general type of data flavor that Verdantium supports is raw data from a file stream. For instance, a text editor can read a standard plain text document as a set of bytes that have been loaded from an input stream. The Verdantium system has the responsibility of mapping the input file to an appropriate MIME type, and then sending this MIME type to the Verdantium component in the form of a DataFlavor object. The surrounding Verdantium system can determine if a component can read a particular file type by calling the getPersistentInputDataFlavorsSupported( ) method and then ascertaining whether the MIME type of the file is a match for one of the MIME types returned.
One drawback of this approach is that loading of persistent data fails if the Verdantium system maps a file to the wrong MIME type. This is similar to what happens in Microsoft Windows if a file extension is mapped to the wrong application. Some care must be taken to make sure that the mappings are complete and correct. Also, the particular mapping scheme that should be used seems to be highly platform-dependent. For instance Windows and Unix distinguish file types by using file extensions, while the Mac OS uses a special four-letter code stored separately from the file name [This has changed now that Mac OS X runs as a Unix variant]. How to unify the mapping schemes of all platforms under a single bytecode implementation is unclear at this time. The current version of the system runs on the Windows platform.
If a particular component is missing, Verdantium can query all other registered components and determine which component(s) can respond to an input file of a particular data flavor. To provide faster indexing, it also uses a series of hash tables to map data flavors to components, and to map file extensions to MIME types. This querying system provides an ability to interchange visual components that is not found in client-side Java Beans. One component can replace another if there is an appropriate mapping of MIME types. This gives developers greater flexibility in deploying components. Consider how Adobe Acrobat has been successful because Acrobat Reader, a free product, is able to read files of the same MIME type as the sold-for-profit Acrobat and Acrobat Distiller. Verdantium can replicate this kind of relationship more readily than client-side Java Beans.
2.2 Verdantium’s User Interface for Embedding
In order to provide appropriate support for embedded documents and take full advantage of JFC/Swing functionality, Verdantium uses a very different user interface than that exemplified by the Bean Box. One of basic problems in any compound document system is that of how the user interface distinguishes between the operations that can be performed on embedded documents. These operations fall into three basic types:
* Resizing the embedded document in the container.
* Translating the embedded document to different positions in the container.
* Editing the embedded document’s content (e.g. drawing onto an embedded paint program using the mouse).
Almost all embedding systems perform the resizing and translating of embedded documents by placing a border around the document that can be dragged with the mouse. Borders have some advantages. Large borders are easy for the user to find and drag with the mouse. They can also have distinct on-screen controls for translating as opposed to resizing. However, borders also have serious drawbacks. The display of borders moves the container document away from a WYSIWYG appearance. Borders also tend to obscure part of the document’s content. This can frustrate people attempting create complex documents because the display of borders while resizing can interfere with the user’s ability to determine whether the embedded component is the “right size” to fit neatly into its surrounding content.
Apple’s OpenDoc [1, 2, 8, 12] system uses two approaches to address this design problem: only place a border around the currently selected component, and use a really thin border. OpenDoc attempted to make resizing versus editing an embedded document as modeless as possible. That is to say, one doesn’t have to select a particular mode from a palette or a pull-down menu in order to switch from resizing to editing or vice versa. However, Apple the lack of modes also meant that there was no way to completely turn the border off. So to compensate for the fact that the selected component will always have a border (with the drawbacks that entails), OpenDoc displays a border that is about four pixels in width for translating the component. The drawbacks of this approach are that the border is very difficult for naïve users to select with the mouse, and is so small that even intermediate users who are not already familiar with OpenDoc would likely not recognize the border as a translation control.
Several container applications such as the BeanBox, Microsoft Office [13], and Symantec Visual Cafe [22] keep the concept that only the selected component has a border displayed for translating and resizing, but use a larger border with individual controls for different kinds of resize operations. The larger borders fix the selection and recognition problems, but make it more difficult to see a document in the context of the surrounding space. Also, the fact that one has to select an embedded component before resizing it creates inherent problems. Suppose the embedded component is a button. Does clicking on the button mean that a button-press event should be sent, or does it mean that the user wants to resize it? So many common components rely on single-click operations that using mouse-click selections to control the display of borders is not entirely practical outside of IDEs, which have separate “Design” and “Execute” modes that determine whether the embedded components respond to the mouse.
Verdantium takes a very different approach to the problem of how to distinguish resizing and translating from the editing of content. The Verdantium approach is based on the MDI window concept, which many users are already familiar with from their use of popular office applications. Translating a document equates to dragging the title bar of the MDI window, and resizing the document is performed by dragging the MDI’s resize control. The MDI control in the typical form found in other software is large enough that users can easily drag it and is familiar enough that users understand what to use it for, but it displays too large a border to work well in a variety of situations. To fix this problem, Verdantium requires that users accept a somewhat modal interface with the associated learning curve. The property editor palettes for the Verdantium container applications provide push-button controls for determining whether or not the MDI frames are displayed around the embedded components. The frames display differently depending on the mode of the pushbutton control (see Figures 3, 4, and 5). At the risk of sounding ridiculous, the author decided to use very simple names for each of the modes (such as “Move Mode”) to avoid names that throw too many long words at the naïve user (such as “Translate Mode”).
Figure 3 Simple components displayed in “Move Mode.”
Figure 4 Simple components displayed in “Resize Mode.”
Figure 5 Simple components displayed in “Edit Mode.”
Verdantium’s container app. MDI frames have one more important difference versus typical MDI implementations: Verdantium frames have transparent backgrounds (see Figure 6). This allows for Verdantium components to be used as semi-transparent overlays in a container application (thanks to Swing’s transparency support). There are a number of compound document scenarios where this is an extremely important capability. For example, the transparency support provides the means to lay text over graphics (see Figure 7). One drawback of this transparency implementation is that the Verdantium code tends to delve deeply into Swing’s Pluggable Look And Feel (PLAF) code in order to produce a subclass of JInternalFrame with the proper border and transparency characteristics. At least for the time being, this results in the container frame being hard-wired for a particular look-and-feel. The Java Look-And-Feel (JLF) is being used for the current implementation [this has since been extended to include Windows and Mac LAFs].
Figure 6 MDI container app. frames in Verdantium have transparent backgrounds, and take advantage of Swing’s transparency support. This allows the document creator to overlay non-rectangular shapes. A component can avoid the use of transparency by drawing an opaque background.
Figure 7 An example of why support for transparency is useful. In this illustration, a graphics component is displaying a curve, and an embedded text component that is rendering text over the top of the graphics. Note how the text is inside the curve, but the resize rectangle of the text component extends outside at the top corners.
2.3 Document-Level Printing Support
Unlike Java Beans, which only provides widget-level printing, Verdantium provides a document-level printing interface called BookPrintable. BookPrintable gives the component total control over the printing process from the time the user selects the “Print” command on the component to the time that the component decides the print operation has concluded. Verdantium also keeps the widget-level printing functionality from AWT / Java Beans. This means that there can be as many as two separate execution paths by which a Verdantium component may be printed (a document path and a widget path). The reason for this is that embedded components need to have a different printing protocol from the component that gets the original request. That is to say, there is a “master” component and there are “slave” components in the printing process, and the slaves (the ones embedded somewhere in the master’s document) do not get all of the privileges of the master. The master gets to select how many pages to print, and what will show up in each page at a document level. The slaves’ responsibility is to respond to calls to their GUIs’ print() method in a reasonable way. In most cases, the default implementations of the print() method supplied by AWT already work well enough to support the slave side of the relationship. The use of multiple paths of execution for printing allows a Verdantium component to properly support printing as either a stand-alone application or an embedded component.
2.4 Versioning
Support for persistent versioning is very important for applications software. Almost all applications have legacy file formats from previous versions of the software, and being able to interrogate these legacy formats in a useful manner helps to convince customers to spend money on regular upgrades. Versioning of serialized objects is also a tremendously difficult problem. Verdantium provides the ability for an Externalizable object to save itself in a more versionable way using an object-oriented version of a property list. The class’ implementation of the writeObject() method of the Externalizable interface creates this property list object, writes a series of objects to the property list with different property names, and then sends the property list down the stream to be serialized. The advantage of the property list is flexibility in dealing with versioning issues. For instance, an object reading persistent information from a property list can query the list to see if certain property names have objects associated with them. Also, different versions of a class can write data to different property names regardless of how or whether the schema of the class changed. The property list can then be interrogated on the read side to determine which set of property names is contained in the list. Another key advantage of the property list is that objects do not have to be read in the same order in which they are written. For instance the writeObject() may write the property for the number of items in a list after the list items because the list was read using an iterator. However, the readObject() method for the same class read the number of items first, and then loop through the property name of each list item using a simple for-next statement. The ability to arbitrarily order the reading of items from the property list greatly aides the ability to perform non-trivial versioning because the schema for the latest version of the class may not be well-suited to reading data in the order saved using previous versions of the class.
It may be useful in a future version of Verdantium to modify the existing property list system to serialize in terms of XML [20, 24]. XML would provide an ASCII representation of the object property files that could be analyzed using a standard text editor. This is a topic for future research. [This has been implemented in more recent versions. Serializing property lists to XML provides the best of both worlds. The file format is standard XML, but the object read/write system has the flexibility of object properties.]
2.5 Creating Actual Components
All of Verdantium’s capabilities would be useless if they made Verdantium components and Verdantium container applications impossible to write. In contrast to the complexity required to replicate the Bean Box, a great deal of work has been put into streamlining the number of lines of code required to construct simple Verdantium components. The Verdantium HelloWorld component currently requires 140 lines of code, including comments (not counting the optional class providing online help). The DemoContainerApp, an example class that demonstrates how to write a simple container application, currently requires 440 lines of code with comments (not counting code for an optional class devoted solely to providing online help).
3. Verdantium as a Document Model
Verdantium was created with the idea that a client-side component should be able to support all the functionality that a typical GUI application does so that the components can have wider applicability. The VerdantiumComponent revises and extends the Beans component model to support these features. Perhaps the most important of these extensions is the expanded support for persistence. Components in Verdantium can read and write files of any MIME type through a Transferable interface, or save and load Serialized objects to persistent storage. Assuming that the Verdantium system can map each file to an appropriate MIME flavor and load the raw data stream into a Transferable object, the component can support any number of file types simultaneously. Multiple components can share the same file type, allowing more flexibility in how they can be distributed. Finally, Verdantium makes it easier for Externalizable objects to be compatible with future versions of the software using alternate persistence formats.
Verdantium supports multi-page printing at the component level, allowing applications such as word processors and illustration programs to be written as components. The AWT widgets’ print() method is also supported for imaging embedded components to a particular rectangular region of the printed page. Some might argue that giving the component total control over multi-page printing makes it incompatible with use in a Java applet. However, multi-page printing can not be allowed in any form from an applet because an errant applet can request an arbitrarily large number of pages. Hence, the applet’s security manager simply would not allow a print request to be fully processed. Moreover, the browser can still perform widget-level printing of the applet through the standard interface. [This point is moot now that newer versions of IE have made it very difficult to write an HTML block that executes the Java Plug-In across all browsers (e.g. removing support for Netscape plugins). Applets are probably dead, and Verdantium is now really a framework for Java applications, and components pulled in from the network through the Verdantium Discovery system. Verdantium Discovery is probably a lot more reliable than using Applets anyway.]
Verdantium components can be used to build compound documents. Complete container applications can be written as Verdantium components in significantly less than 1000 lines of code, and structured using a robust MVC architecture. Because Verdantium code is based on Swing and the container functionality is based on JDesktopPane, the resulting GUIs are both stable and easy to use. Hopefully this will lead to a larger number of container implementations to be included with general-purpose applications such as illustration programs. Embedded components can fully utilize Swing’s support for transparency, allowing embedded components to act as transparent overlays.
One might argue that Verdantium is not compatible with many IDEs because of the techniques they use for building GUIs visually. The visual builders of many IDEs express GUI code in terms of the subclassing of java.awt.Container (or some subclass thereof), which is precisely what Verdantium was designed to avoid. In this case, there are two approaches that one might use. First, allow the model class and the view class to merge. That is to say, have the generated view class implement VerdantiumComponent. This isn’t a perfect solution, but it can work. The second is to express the entire GUI in terms of UI panes, and have each VerdantiumComponent create an instance of the appropriate IDE-generated UI pane class as a member and then return it using the getGUI() method. The disadvantage of this approach is that it may produce a series of independent pane classes where none may be necessary.
4. RELATED WORK
In many ways the environment that is architecturally the most similar to Verdantium is Apple’s now-defunct OpenDoc [1, 2, 8, 12] project. OpenDoc was a cross-platform compound-document model implemented using IBM’s System Object Model (SOM). OpenDoc components were typically written in a language such as C or C++ with a binding that allowed them to be compatible with SOM’s more sophisticated object model. The need to communicate with a separate object model through an API created extra work for the programmer and made components more difficult to write. Also, typical OpenDoc components on the Macintosh platform did not use a set of layout managers to automate GUI interactions as is often done with JFC/Swing or X-Motif widgets. For instance instead of using the equivalent of a JScrollPane to manage the GUI of a document, many OpenDoc components would have code to respond to each individual scroll bar action. This further contributed to the complexity of constructing workable OpenDoc implementations.
Among OpenDoc’s notable features were its cross-component scripting architecture, its support for embedded components, and its ability to have a component read and write files to arbitrary formats while still supporting embedding. One problem with OpenDoc was a lack of memory-protection to keep errant objects from overwriting each other. In particular, on the Mac platform there was no memory protection at all. On other platforms, components were protected from each other, but the objects that comprise a component could still compromise each other in that component’s memory space. Contrast this with the Java VM, where objects are not allowed to clobber each others’ memory. OpenDoc’s lack of memory protection meant that a single ill-behaved component could crash other components in a document, seriously affecting the robustness of the architecture. OpenDoc is no longer supported by its original vendors, and very little development of new OpenDoc components has been done in the past two years.
Java Beans [5, 14 16, 18], the standard component architecture for Java, is more robust than OpenDoc in the sense that the Java VM prevents ill-behaved objects from clobbering each other. Moreover, Java Beans are easier to write in many ways because the Beans object model is the same as that for the Java language. The use of Java layout managers automates many of the more complex tasks related to the GUI, allowing the developer to focus on those events that actually affect the domain logic of the component. The problems with client-side beans were discussed earlier in the paper. For the sake of brevity, they are not repeated here.
Object Linking and Embedding (OLE) is Microsoft’s environment for creating compound documents in the form of custom controls with a WYSIWYG appearance [11]. OLE uses Microsoft’s COM object model to provide an interface mechanism for components to communicate. Like OpenDoc’s SOM model, COM components are written in a language like C or C++ with wrappers that allow them to work in the COM model. OLE components also require a host application to support their display. Microsoft Office applications use OLE as a means to interoperate. ActiveX, a close cousin of OLE, provides an architecture for controls to be displayed on the web.
Aldus developed the Vamp environment as a compound-document implementation designed to streamline the development and maintenance of software components within the company, and to aid in the porting of code between the Macintosh and Windows platforms [6]. The architecture of Vamp was based on Model-View-Controller with the use of event-driven state machines to alter component states. Vamp allowed large programming teams at Aldus to be divided into smaller groups working on individual components. Reenskaug and Skaar [15] developed a documentation environment with a number of compound-document capabilities, and with the additional ability to collapse part of a document. Embedded components included class and method definitions. Netscape worked on a compound document extension to Java Beans two years ago [23]. However, little information has been released about this project.
Faustini’s Visual Java, an early ancestor of the Bean Box, provided a purely visual environment for building GUIs in a container application as mentioned in [21]. Not only were the GUIs visually built, but the algorithms tied to the GUI actions were also built from visual components. Visual Java used a data model based on the programming language Lucid expressed using an operator net concept. Each operator in the net was capable of running on independent threads of execution and could potentially operate in either a deterministic or nondeterministic fashion. The name “Visual Java” is now used for a different product. The closest environment to Faustini’s Visual Java today is Java Studio [19].
Improved persistence models for Java Beans have recently become a topic of much interest. One persistence standard seeing increasing use is XML [20, 24]. XML is an HTML-based language for representing object-oriented data [This sentence was one of the major reasons why the paper got rejected. Should I have written "HTML-like" instead of "HTML-based"? Should I have written "SGML-based" instead of "HTML-based"? Both HTML and XML owe their lineage to SGML. SGML is a meta-language that doesn't describe a particular format (i.e. how to define tags). HTML defines a format for part of SGML. XML also defines a format for part of SGML, and defines the tag format (e.g. use of angle brackets for tags) the same as HTML. As a result, XML loads directly into many browsers designed for HTML, but the browsers simply don't recognize the content of the tags. So XML was IMHO based on many tag format concepts from HTML, but the paper got rejected anyway.]. Objects are represented in XML by a set of tags that describe the states of each of the objects’ members. The XML format also provides a means to support versioning. A program can accomplish this by parsing the XML data to interrogate its format, and then converting the old format to match that required by the current software. One of the advantages of XML is that it is not dependent on a particular object model. XML data can be read and written by systems outside the Java architecture such as relational databases. Because XML is HTML-based, XML parsers can not read or write formats such as non-HTML plain text files or images. [As noted before, Verdantium now persists objects in XML].
XML can be used in a variety of applications. An example of XML’s flexibility is the Simple Object Access Protocol (SOAP) which uses XML as the basis of a wire format for remote method invocation using HTTP [3]. The Java implementation of SOAP has some architectural similarities to Verdantium in the sense that they both use Java interfaces as opposed to base classes to represent the fundamental object types of the system. The element types in SOAP are implemented using an interface hierarchy to provide the methods supported by each type of SOAP data. Instead of the properties list metaphor used by Verdantium, SOAP represents data as a linked collection of structured types: arrays, simple types, compound records, and object references. [It could be said that XML describes "nouns and verbs" but it doesn't describe any kind of "vocabulary". As a result, Verdantium has classes that scan the format of the XML file, and then determine which component should load it. In a sense, it answers the question, "which component speaks in this vocabulary?"]
5. ACKNOWLEDGMENTS
The author would like to thank all the people who made helpful suggestions about the architecutre: Dr. Edward Ashcroft, Dr. Timothy Lindquist, Dr. David O. Hestenes, Dr. David Halliday, Al Butkus, Pat Reany, and Dwain Desbien. I would also like to thank Dr. Tony Faustini, without whom I may never have discovered the Java language.
6. REFERENCES
[1] Apple Computer. Inside Macintosh OpenDoc Cookbook, Addison-Wesley, Menlo Park, CA (1996).
[2] Apple Computer. Inside Macintosh OpenDoc Programmer’s Guide, Addison-Wesley, Menlo Park, CA (1996).
[3] Chappell, D., “Simple Object Access Protocol (SOAP) and Firewalls,” Web Page, http://msdn.microsoft.com/xml/ general/soap_white_paper.asp
[4] Coad, P., and P. Mayfield, Java Design, Printice Hall, Upper Saddle River, NJ (1999).
[5] Feghhi, J. Web Developer's Guide to Java Beans, Coriolis Group Books, New York, NY (1997).
[6] Ferrel, P. J., and R. F. Meyer, “Vamp: The Aldus Application Framework,” Proc. ACM OOPSLA, 185-189 (October, 1989).
[7] Fowler, M., Refactoring, Addison-Wesley, Menlo Park, CA (1999).
[8] Fuller, J., and A. Meadow. Essential OpenDoc, Addison-Wesley, Menlo Park, CA (1996).
[9] Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns, Addison-Wesley, Menlo Park, CA (1995).
[10] Green, T., “Research Issues of Geometry-Based Visual Languages and Some Solutions,” Ph. D. Dissertation, Arizona State University, Tempe, AZ (1999).
[11] Li, S., and P. Economopoulos, Professional Visual C++ 5 ActiveX/COM Control Programming, Wrox Press, Chicago, IL (1997).
[12] MacBride, A., and J. Susser. Byte Guide to OpenDoc, McGraw-Hill, New York, NY (1996).
[13] Microsoft. “Microsoft Office”, Computer Software, Redmond, WA.
[14] Morrison, M. Presenting Java Beans, Sams, Indianapolis, IN (1997).
[15] Reenskaug, T., and A. L. Skaar, “An Environment for Literate Smalltalk Programming,” Proc. ACM OOPSLA, 337-345 (October, 1989).
[16] Sun Microsystems, “Enterprise JavaBeans Technology,” Web Page, http://java.sun.com/products/ejb/
[17] Sun Microsystems, “Java AWT: Delegation Event Model,” Web Page, http://java.sun.com/products/jdk/1.1/docs/guide/ awt/designspec/events.html
[18] Sun Microsystems, “Java Beans, Part 1,” Web Page, http://developer.java.sun.com/developer/onlineTraining/ Beans/Beans1/simple-definition.html
[19] Sun Microsystems, “Java Studio,” Web Page, http://developer.java.sun.com/developer/Books/ Graphics2/index.html
[20] Sun Microsystems, “Java Technology and XML,” Web Page, http://java.sun.com/xml/index.html
[21] Sun Microsystems, “Keynote Presentation,” Web Page, http://java.sun.com/javaone/javaone96/McNealy.html
[22] Symantec, “Visual Café,” Computer Software, Cupertino, CA.
[23] Vizard, M., “Pull over, Sun; Big Blue’s gonna drive,” InfoWorld, 19(8), 3-4 (Feb, 1997).
[24] W3C, “Extensible Markup Language (XML) 1.0,” Web Page, http://www.w3.org/TR/1998/REC-xml-19980210
Extending Java Beans to support a Compound Document Model: Project Verdantium
Thornton Green
Arizona State University
ABSTRACT
Client-side visual Java Beans are poorly suited to the implementation of document-level software components such as text editors. This reduces the applicability of visually displayed Beans, limiting the client-side API primarily to a means for interchanging widgets between different integrated development environments (IDEs). By using an alternate API (Verdantium) for the embedding of beans in a visual context, clients-side code can implement a full compound document display model while leaving server-side APIs (Enterprise Java Beans) and the fundamental bean property model unchanged. Fully functional applications (i.e., word processors, illustration programs, equation editors, etc.) can be implemented as individual software components that can either run independently or be embedded in other applications using the same API. [Java Beans hasn't changed much since this was written; all of this is still true today]
Keywords
Component software, compound-documents, embedding, Java Beans.
1. INTRODUCTION
When Sun introduced the original container application for visually embedded Java Beans [5, 14, 16 18], the Bean Box, it included as sample components a couple of buttons, a molecule viewer, and some other components with a similar level of sophistication. Since then, little has changed. The APIs introduced by the Bean Box have been used as a way to build applications from simpler widgets in a development environment, but have not led to the widespread sharing of visual components between Java applications outside of the software development world. The term “widget” refers to a subclass of java.awt.Component (or its equivalent in another framework). This paper sometimes uses “widget” instead of “component” so that the term “component” can be used in the context of component software.
To understand the problem, one must first answer the question, “what is a Java Bean?” There are three different senses in which the term “Java Beans” tends to be used:
* As a programming standard for specifying “get” methods, “set” methods, property change events, etc [18]. The resulting components can be visually manipulated regardless of whether the have GUIs. For instance, a ComboBoxModel can be manipulated in Symantec Visual Café [22].
* As a server-side API for interacting with transaction environments and legacy code (Enterprise Java Beans) [16].
* As an API (on the client side) for subclasses of java.awt.Component to be read by the Bean Box (or similar program) from a jar file.
It is the latter of the three that creates problems for document embedding. Container applications that emulate the functionality of the BeanBox are difficult to write. Further, pure Java implementations of bean containers have inherent display problems. Many visual beans are “heavyweight” widgets, making it difficult for the pure Java container app. to superimpose a resize widget over the top of the bean.
Support for native or legacy file formats is lacking in the visual beans’ persistence standards. A class written for the Bean Box can serialize itself by implementing one of two interfaces, Serializable or Externalizable. Neither of which can support foreign file formats, unless they are object-based. This means that for example a text editor bean would need a second entirely separate persistence mechanism in order to load or save plain text files saved on the local disk. There is also no built-in mechanism for two beans to support the same persistence format. For instance, a PDF distiller bean can not serialize itself in such a way that the serialized format will be read by the free PDF reader bean when opened. Instead, the identity of the object’s class (in this case the PDF distiller bean) is “hard-coded” into the persistent data. When the file is loaded from persistent storage, the hard-coded class is used to read the object data. [Sun effectively deprecated Externalizable for XML object persistence, and uses a new system for XML. Nevertheless, the above is still true for non-XML formats.]
The way that beans are embedded into a container also presents a number of less fundamental problems that nevertheless present a series of practical difficulties. One of them is the use of subclassing of AWT components (i.e. widgets) to create beans. One of the original articles on the JDK 1.1 event model, [17], states “subclassing should be reserved for circumstances where [AWT] components are being extended in some functional or visual way.” Java Beans do not adhere to this principle. To make a bean that can be displayed in the Bean Box, the developer must subclass a widget regardless of whether she intends to extend the base widget in a functional or visual way. To quote this same page again, subclassing of AWT components “does not lend itself well to maintaining a clean separation between the application model and the GUI because application code must be integrated directly into the subclassed components at some level.” To be fair, the latter quote is referring more to using subclassing to handle events. However, it would also seem to apply to subclassing widgets in order to use them as visual beans. Any methods that talk to an interface implemented by the bean or to the bean’s “get/set” methods must necessarily go through the subclass of the widget, and can not be routed directly to the application code.
Because the APIs for visually displayed beans were created with the assumption that heavyweight widgets could be used, there is no unified API support for beans that are visually transparent. This makes it difficult for a text label bean to overlay (with a transparent background) the display content of a graphics bean with predictable results. Unfortunately, even the most basic presentation software requires this capability from its components. For instance, imagine how ugly a Microsoft Powerpoint presentation with a gradient-filled background would look if all the text labels had individual opaque rectangular backgrounds of a single color. As a practical matter, transparency support is necessary for getting useful results from visual components in a variety of situations.
Multi-page printing also presents a problem from a practical perspective. A Java Bean has one method, print(), with which to print itself into a graphics context. Unlike the APIs generally available to applications, the print() method does not support multi-page printing because it is a widget-level operation as opposed to a document-level operation. This gives the writer of the bean two choices: restrict the bean to something that only prints single pages, or implement a custom set of printing routines entirely separate from the Beans APIs.
The ability to read previous versions of the serialized state of a bean can be difficult to accomplish. The Serializable and Externalizable interfaces attach versioning information to the persistent state of a class based upon the bytecode information of the classes being serialized. If the bytecode of the class changes even slightly, older serialized files are no longer compatible. This can be remedied to an extent by defining the serialVersionUID field of each class. This will make the class able to read serialized information made by any other version of the class using the same serialVersionUID. However, this does not in itself solve the versioning problem. The class must still read a set of objects from a linear stream, attempt to ascertain which version of the software these objects refer to, and employ some type of filter to derive meaningful data from the object stream. Filtering data from a linear stream of objects can be difficult because in general there are no tags indicating what instance member name each object of the stream belongs to. As a result, it may be very difficult to derive the proper meaning from the object stream when two previous versions of the class had similar but not identical formats, and several instance members of the same class. [XML persistence using Serializable no longer seems to be using serialVersionUID.]
2. THE SOLUTION
Verdantium, a prototype API based on a set of software components the author developed to support his Ph. D. dissertation [10], extends client-side beans by implementing a compound-document model for visual components. The idea behind this model is to be able to construct complex documents by having a series of software components (beans) working together to represent the document’s various parts. For instance, a word processor and its equation editor can be separate beans that cooperate to allow the user to insert equations into a paper that she is editing. Instead of having very large monolithic applications as illustrated in Figure 1, a series of smaller beans cooperate to replicate the functionality typically seen in large applications. The construction of documents using components is more flexible because components for editing different parts of a document can be added and/or interchanged.
Figure 1 An example of modern software with all of its toolbars turned on. Taken from a screenshot of a 800 x 600 display. Note the amount of functionality that has been packaged in a single monolithic application.
Verdantium’s document model is implemented using the Model-View-Controller (MVC) philosophy. That is to say, the user interface for a certain kind of document is kept separate from its application logic [7]. Beans that are displayed in the Bean Box are subclasses of a view class, with no inherent support given to the underlying model. The VerdantiumComponent by contrast is a Java interface implemented by the model class, with the GUI stored in a separate object (though one may optionally integrate the two). The major design principles supporting the use of an interface are flexibility and pluggability as noted in [4]. Components based on interfaces are more flexible because they can extend any chosen base class, and they are pluggable in the sense that one implementation of an interface can be replaced by another that uses the same methods. One important aspect of the flexibility of using an interface is that the VerdantiumComponent does not need to subclass a widget. Instead, the user interface of the VerdantiumComponent is the Swing JComponent returned by the VerdantiumComponent’s getGUI() method.
package verdantium;
import javax.swing.*;
import java.awt.*;
import java.awt.datatransfer.*;
public interface VerdantiumComponent extends
EtherEventHandler
{
public JComponent getGUI();
public void handleDestroy();
public DataFlavor[]
getPersistentOutputDataFlavorsSupported( );
public void loadPersistentData( DataFlavor flavor ,
Transferable trans );
public Transferable savePersistentData(
DataFlavor flavor );
}
Figure 2 The definition of a VerdantiumComponent.
The defintion of a VerdantiumComponent is as given in Figure 2, where EtherEventHandler is a Verdantium-defined interface for handling scriptable events. The simplest Verdantium components do not need to handle any such events, and can simply provide a stub implementation of EtherEventHandler’s only method. In addition, a VerdantiumComponent capable of being used in a compound document must have a null constructor, and implement one required method not shown in the listing above. The method’s signature is as follows:
public static DataFlavor[]
getPersistentInputDataFlavorsSupported( )
This method is called at runtime using the Java Reflection API. By studying the interface definition above, one can see that every VerdantiumComponent must do three basic things. It must present a Swing GUI, it must be able to handle its own destruction, and it must be able to support a persistence architecture based on AWT’s Transferable and DataFlavor concepts. Different components implement the same interface, but provide different behaviors. In other words, the interface provides the basis for implementing a Strategy pattern with respect to multi-flavor persistence and GUI presentation [9].
The mandatory use of Swing widgets to implement Verdantium GUIs greatly simplifies the implementation of the overall framework. Heavyweight widgets make certain kinds of controls difficult to implement because the heavyweight widgets tend to display in front of any widget that does not have a peer [This has generally been true since JDK 1.1, but Sun announced during a session at JavaOne 2007 that they wanted to change this. For essentially all current JDK implementations this is still they way Java Z-Orders heavyweight instances of jaav.awt.Component]. Because Swing widgets are entirely lightweight, there are fewer problems to contend with when attempting to design controls that resize or translate the widgets. For example, Swing already provides JDesktopPane and JInternalFrame classes that implement Multiple-Document Interface (MDI) resize controls on other Swing widgets in a robust manner.
2.1 Persistence Support
To support persistent storage, a VerdantiumComponent reads and writes Transferable objects in multiple data flavors. The use of the Transferable object in the loading and storing of persistent states can be thought of as similar to the Memento pattern in [9]. The Transferable object is the Memento, the VerdantiumComponent is the originator, and the persistence system is the Caretaker. The main differences are that the VerdantiumComponent does not have to deal with a constraint solver in the same sense as the systems that served as the motivation for the Memento pattern, and that the VerdantiumComponent contains support for through data flavors for creating Transferable data in multiple formats.
The data flavors that a component can support fall into two general types. The first type is object data intended to be read from or written to a Java object stream. This allows the component to use the standard Java Beans persistence mechanism with Serializable objects. However, there is an important semantic difference between Verdantium’s object serialization and that in client-side beans. Client-side beans tend to serialize data from the widgets they inherit from, including the full view hierarchy. This has two problems. First, Swing widgets tend to store a very large amount of data to persistent storage. Much of this information is of little real use to the overall application. Second, Swing’s persistence format is still under revision as of Java 2. Verdantium components avoid these problems because they serialize the model, not the view. For instance a text editor component serializes the text of the document, not the details of the view hierarchy. There is a drawback in that the Verdantium component has to do more work to load a file than its bean counterpart. Sometimes a component written in Verdantium has to take a representation of a document and map it to an appropriate set of widgets and layout managers, or vice versa . However, the author feels that the benefits outweigh the drawbacks. [In recent versions of Verdantium the format for this has shifted from binary object streams (i.e. class ObjectOutputStream) to XML object streams. Newer versions of Verdantium also contain logic that map most implementations of Externalizable to XML. The author feels that Externalizable is much simpler, more elegant and more object-oriented than Sun's XML callback mechanism, and hence it makes sense to use the XML callback mechanism to bridge Externalizable into the XML format.]
The second general type of data flavor that Verdantium supports is raw data from a file stream. For instance, a text editor can read a standard plain text document as a set of bytes that have been loaded from an input stream. The Verdantium system has the responsibility of mapping the input file to an appropriate MIME type, and then sending this MIME type to the Verdantium component in the form of a DataFlavor object. The surrounding Verdantium system can determine if a component can read a particular file type by calling the getPersistentInputDataFlavorsSupported( ) method and then ascertaining whether the MIME type of the file is a match for one of the MIME types returned.
One drawback of this approach is that loading of persistent data fails if the Verdantium system maps a file to the wrong MIME type. This is similar to what happens in Microsoft Windows if a file extension is mapped to the wrong application. Some care must be taken to make sure that the mappings are complete and correct. Also, the particular mapping scheme that should be used seems to be highly platform-dependent. For instance Windows and Unix distinguish file types by using file extensions, while the Mac OS uses a special four-letter code stored separately from the file name [This has changed now that Mac OS X runs as a Unix variant]. How to unify the mapping schemes of all platforms under a single bytecode implementation is unclear at this time. The current version of the system runs on the Windows platform.
If a particular component is missing, Verdantium can query all other registered components and determine which component(s) can respond to an input file of a particular data flavor. To provide faster indexing, it also uses a series of hash tables to map data flavors to components, and to map file extensions to MIME types. This querying system provides an ability to interchange visual components that is not found in client-side Java Beans. One component can replace another if there is an appropriate mapping of MIME types. This gives developers greater flexibility in deploying components. Consider how Adobe Acrobat has been successful because Acrobat Reader, a free product, is able to read files of the same MIME type as the sold-for-profit Acrobat and Acrobat Distiller. Verdantium can replicate this kind of relationship more readily than client-side Java Beans.
2.2 Verdantium’s User Interface for Embedding
In order to provide appropriate support for embedded documents and take full advantage of JFC/Swing functionality, Verdantium uses a very different user interface than that exemplified by the Bean Box. One of basic problems in any compound document system is that of how the user interface distinguishes between the operations that can be performed on embedded documents. These operations fall into three basic types:
* Resizing the embedded document in the container.
* Translating the embedded document to different positions in the container.
* Editing the embedded document’s content (e.g. drawing onto an embedded paint program using the mouse).
Almost all embedding systems perform the resizing and translating of embedded documents by placing a border around the document that can be dragged with the mouse. Borders have some advantages. Large borders are easy for the user to find and drag with the mouse. They can also have distinct on-screen controls for translating as opposed to resizing. However, borders also have serious drawbacks. The display of borders moves the container document away from a WYSIWYG appearance. Borders also tend to obscure part of the document’s content. This can frustrate people attempting create complex documents because the display of borders while resizing can interfere with the user’s ability to determine whether the embedded component is the “right size” to fit neatly into its surrounding content.
Apple’s OpenDoc [1, 2, 8, 12] system uses two approaches to address this design problem: only place a border around the currently selected component, and use a really thin border. OpenDoc attempted to make resizing versus editing an embedded document as modeless as possible. That is to say, one doesn’t have to select a particular mode from a palette or a pull-down menu in order to switch from resizing to editing or vice versa. However, Apple the lack of modes also meant that there was no way to completely turn the border off. So to compensate for the fact that the selected component will always have a border (with the drawbacks that entails), OpenDoc displays a border that is about four pixels in width for translating the component. The drawbacks of this approach are that the border is very difficult for naïve users to select with the mouse, and is so small that even intermediate users who are not already familiar with OpenDoc would likely not recognize the border as a translation control.
Several container applications such as the BeanBox, Microsoft Office [13], and Symantec Visual Cafe [22] keep the concept that only the selected component has a border displayed for translating and resizing, but use a larger border with individual controls for different kinds of resize operations. The larger borders fix the selection and recognition problems, but make it more difficult to see a document in the context of the surrounding space. Also, the fact that one has to select an embedded component before resizing it creates inherent problems. Suppose the embedded component is a button. Does clicking on the button mean that a button-press event should be sent, or does it mean that the user wants to resize it? So many common components rely on single-click operations that using mouse-click selections to control the display of borders is not entirely practical outside of IDEs, which have separate “Design” and “Execute” modes that determine whether the embedded components respond to the mouse.
Verdantium takes a very different approach to the problem of how to distinguish resizing and translating from the editing of content. The Verdantium approach is based on the MDI window concept, which many users are already familiar with from their use of popular office applications. Translating a document equates to dragging the title bar of the MDI window, and resizing the document is performed by dragging the MDI’s resize control. The MDI control in the typical form found in other software is large enough that users can easily drag it and is familiar enough that users understand what to use it for, but it displays too large a border to work well in a variety of situations. To fix this problem, Verdantium requires that users accept a somewhat modal interface with the associated learning curve. The property editor palettes for the Verdantium container applications provide push-button controls for determining whether or not the MDI frames are displayed around the embedded components. The frames display differently depending on the mode of the pushbutton control (see Figures 3, 4, and 5). At the risk of sounding ridiculous, the author decided to use very simple names for each of the modes (such as “Move Mode”) to avoid names that throw too many long words at the naïve user (such as “Translate Mode”).
Figure 3 Simple components displayed in “Move Mode.”
Figure 4 Simple components displayed in “Resize Mode.”
Figure 5 Simple components displayed in “Edit Mode.”
Verdantium’s container app. MDI frames have one more important difference versus typical MDI implementations: Verdantium frames have transparent backgrounds (see Figure 6). This allows for Verdantium components to be used as semi-transparent overlays in a container application (thanks to Swing’s transparency support). There are a number of compound document scenarios where this is an extremely important capability. For example, the transparency support provides the means to lay text over graphics (see Figure 7). One drawback of this transparency implementation is that the Verdantium code tends to delve deeply into Swing’s Pluggable Look And Feel (PLAF) code in order to produce a subclass of JInternalFrame with the proper border and transparency characteristics. At least for the time being, this results in the container frame being hard-wired for a particular look-and-feel. The Java Look-And-Feel (JLF) is being used for the current implementation [this has since been extended to include Windows and Mac LAFs].
Figure 6 MDI container app. frames in Verdantium have transparent backgrounds, and take advantage of Swing’s transparency support. This allows the document creator to overlay non-rectangular shapes. A component can avoid the use of transparency by drawing an opaque background.
Figure 7 An example of why support for transparency is useful. In this illustration, a graphics component is displaying a curve, and an embedded text component that is rendering text over the top of the graphics. Note how the text is inside the curve, but the resize rectangle of the text component extends outside at the top corners.
2.3 Document-Level Printing Support
Unlike Java Beans, which only provides widget-level printing, Verdantium provides a document-level printing interface called BookPrintable. BookPrintable gives the component total control over the printing process from the time the user selects the “Print” command on the component to the time that the component decides the print operation has concluded. Verdantium also keeps the widget-level printing functionality from AWT / Java Beans. This means that there can be as many as two separate execution paths by which a Verdantium component may be printed (a document path and a widget path). The reason for this is that embedded components need to have a different printing protocol from the component that gets the original request. That is to say, there is a “master” component and there are “slave” components in the printing process, and the slaves (the ones embedded somewhere in the master’s document) do not get all of the privileges of the master. The master gets to select how many pages to print, and what will show up in each page at a document level. The slaves’ responsibility is to respond to calls to their GUIs’ print() method in a reasonable way. In most cases, the default implementations of the print() method supplied by AWT already work well enough to support the slave side of the relationship. The use of multiple paths of execution for printing allows a Verdantium component to properly support printing as either a stand-alone application or an embedded component.
2.4 Versioning
Support for persistent versioning is very important for applications software. Almost all applications have legacy file formats from previous versions of the software, and being able to interrogate these legacy formats in a useful manner helps to convince customers to spend money on regular upgrades. Versioning of serialized objects is also a tremendously difficult problem. Verdantium provides the ability for an Externalizable object to save itself in a more versionable way using an object-oriented version of a property list. The class’ implementation of the writeObject() method of the Externalizable interface creates this property list object, writes a series of objects to the property list with different property names, and then sends the property list down the stream to be serialized. The advantage of the property list is flexibility in dealing with versioning issues. For instance, an object reading persistent information from a property list can query the list to see if certain property names have objects associated with them. Also, different versions of a class can write data to different property names regardless of how or whether the schema of the class changed. The property list can then be interrogated on the read side to determine which set of property names is contained in the list. Another key advantage of the property list is that objects do not have to be read in the same order in which they are written. For instance the writeObject() may write the property for the number of items in a list after the list items because the list was read using an iterator. However, the readObject() method for the same class read the number of items first, and then loop through the property name of each list item using a simple for-next statement. The ability to arbitrarily order the reading of items from the property list greatly aides the ability to perform non-trivial versioning because the schema for the latest version of the class may not be well-suited to reading data in the order saved using previous versions of the class.
It may be useful in a future version of Verdantium to modify the existing property list system to serialize in terms of XML [20, 24]. XML would provide an ASCII representation of the object property files that could be analyzed using a standard text editor. This is a topic for future research. [This has been implemented in more recent versions. Serializing property lists to XML provides the best of both worlds. The file format is standard XML, but the object read/write system has the flexibility of object properties.]
2.5 Creating Actual Components
All of Verdantium’s capabilities would be useless if they made Verdantium components and Verdantium container applications impossible to write. In contrast to the complexity required to replicate the Bean Box, a great deal of work has been put into streamlining the number of lines of code required to construct simple Verdantium components. The Verdantium HelloWorld component currently requires 140 lines of code, including comments (not counting the optional class providing online help). The DemoContainerApp, an example class that demonstrates how to write a simple container application, currently requires 440 lines of code with comments (not counting code for an optional class devoted solely to providing online help).
3. Verdantium as a Document Model
Verdantium was created with the idea that a client-side component should be able to support all the functionality that a typical GUI application does so that the components can have wider applicability. The VerdantiumComponent revises and extends the Beans component model to support these features. Perhaps the most important of these extensions is the expanded support for persistence. Components in Verdantium can read and write files of any MIME type through a Transferable interface, or save and load Serialized objects to persistent storage. Assuming that the Verdantium system can map each file to an appropriate MIME flavor and load the raw data stream into a Transferable object, the component can support any number of file types simultaneously. Multiple components can share the same file type, allowing more flexibility in how they can be distributed. Finally, Verdantium makes it easier for Externalizable objects to be compatible with future versions of the software using alternate persistence formats.
Verdantium supports multi-page printing at the component level, allowing applications such as word processors and illustration programs to be written as components. The AWT widgets’ print() method is also supported for imaging embedded components to a particular rectangular region of the printed page. Some might argue that giving the component total control over multi-page printing makes it incompatible with use in a Java applet. However, multi-page printing can not be allowed in any form from an applet because an errant applet can request an arbitrarily large number of pages. Hence, the applet’s security manager simply would not allow a print request to be fully processed. Moreover, the browser can still perform widget-level printing of the applet through the standard interface. [This point is moot now that newer versions of IE have made it very difficult to write an HTML block that executes the Java Plug-In across all browsers (e.g. removing support for Netscape plugins). Applets are probably dead, and Verdantium is now really a framework for Java applications, and components pulled in from the network through the Verdantium Discovery system. Verdantium Discovery is probably a lot more reliable than using Applets anyway.]
Verdantium components can be used to build compound documents. Complete container applications can be written as Verdantium components in significantly less than 1000 lines of code, and structured using a robust MVC architecture. Because Verdantium code is based on Swing and the container functionality is based on JDesktopPane, the resulting GUIs are both stable and easy to use. Hopefully this will lead to a larger number of container implementations to be included with general-purpose applications such as illustration programs. Embedded components can fully utilize Swing’s support for transparency, allowing embedded components to act as transparent overlays.
One might argue that Verdantium is not compatible with many IDEs because of the techniques they use for building GUIs visually. The visual builders of many IDEs express GUI code in terms of the subclassing of java.awt.Container (or some subclass thereof), which is precisely what Verdantium was designed to avoid. In this case, there are two approaches that one might use. First, allow the model class and the view class to merge. That is to say, have the generated view class implement VerdantiumComponent. This isn’t a perfect solution, but it can work. The second is to express the entire GUI in terms of UI panes, and have each VerdantiumComponent create an instance of the appropriate IDE-generated UI pane class as a member and then return it using the getGUI() method. The disadvantage of this approach is that it may produce a series of independent pane classes where none may be necessary.
4. RELATED WORK
In many ways the environment that is architecturally the most similar to Verdantium is Apple’s now-defunct OpenDoc [1, 2, 8, 12] project. OpenDoc was a cross-platform compound-document model implemented using IBM’s System Object Model (SOM). OpenDoc components were typically written in a language such as C or C++ with a binding that allowed them to be compatible with SOM’s more sophisticated object model. The need to communicate with a separate object model through an API created extra work for the programmer and made components more difficult to write. Also, typical OpenDoc components on the Macintosh platform did not use a set of layout managers to automate GUI interactions as is often done with JFC/Swing or X-Motif widgets. For instance instead of using the equivalent of a JScrollPane to manage the GUI of a document, many OpenDoc components would have code to respond to each individual scroll bar action. This further contributed to the complexity of constructing workable OpenDoc implementations.
Among OpenDoc’s notable features were its cross-component scripting architecture, its support for embedded components, and its ability to have a component read and write files to arbitrary formats while still supporting embedding. One problem with OpenDoc was a lack of memory-protection to keep errant objects from overwriting each other. In particular, on the Mac platform there was no memory protection at all. On other platforms, components were protected from each other, but the objects that comprise a component could still compromise each other in that component’s memory space. Contrast this with the Java VM, where objects are not allowed to clobber each others’ memory. OpenDoc’s lack of memory protection meant that a single ill-behaved component could crash other components in a document, seriously affecting the robustness of the architecture. OpenDoc is no longer supported by its original vendors, and very little development of new OpenDoc components has been done in the past two years.
Java Beans [5, 14 16, 18], the standard component architecture for Java, is more robust than OpenDoc in the sense that the Java VM prevents ill-behaved objects from clobbering each other. Moreover, Java Beans are easier to write in many ways because the Beans object model is the same as that for the Java language. The use of Java layout managers automates many of the more complex tasks related to the GUI, allowing the developer to focus on those events that actually affect the domain logic of the component. The problems with client-side beans were discussed earlier in the paper. For the sake of brevity, they are not repeated here.
Object Linking and Embedding (OLE) is Microsoft’s environment for creating compound documents in the form of custom controls with a WYSIWYG appearance [11]. OLE uses Microsoft’s COM object model to provide an interface mechanism for components to communicate. Like OpenDoc’s SOM model, COM components are written in a language like C or C++ with wrappers that allow them to work in the COM model. OLE components also require a host application to support their display. Microsoft Office applications use OLE as a means to interoperate. ActiveX, a close cousin of OLE, provides an architecture for controls to be displayed on the web.
Aldus developed the Vamp environment as a compound-document implementation designed to streamline the development and maintenance of software components within the company, and to aid in the porting of code between the Macintosh and Windows platforms [6]. The architecture of Vamp was based on Model-View-Controller with the use of event-driven state machines to alter component states. Vamp allowed large programming teams at Aldus to be divided into smaller groups working on individual components. Reenskaug and Skaar [15] developed a documentation environment with a number of compound-document capabilities, and with the additional ability to collapse part of a document. Embedded components included class and method definitions. Netscape worked on a compound document extension to Java Beans two years ago [23]. However, little information has been released about this project.
Faustini’s Visual Java, an early ancestor of the Bean Box, provided a purely visual environment for building GUIs in a container application as mentioned in [21]. Not only were the GUIs visually built, but the algorithms tied to the GUI actions were also built from visual components. Visual Java used a data model based on the programming language Lucid expressed using an operator net concept. Each operator in the net was capable of running on independent threads of execution and could potentially operate in either a deterministic or nondeterministic fashion. The name “Visual Java” is now used for a different product. The closest environment to Faustini’s Visual Java today is Java Studio [19].
Improved persistence models for Java Beans have recently become a topic of much interest. One persistence standard seeing increasing use is XML [20, 24]. XML is an HTML-based language for representing object-oriented data [This sentence was one of the major reasons why the paper got rejected. Should I have written "HTML-like" instead of "HTML-based"? Should I have written "SGML-based" instead of "HTML-based"? Both HTML and XML owe their lineage to SGML. SGML is a meta-language that doesn't describe a particular format (i.e. how to define tags). HTML defines a format for part of SGML. XML also defines a format for part of SGML, and defines the tag format (e.g. use of angle brackets for tags) the same as HTML. As a result, XML loads directly into many browsers designed for HTML, but the browsers simply don't recognize the content of the tags. So XML was IMHO based on many tag format concepts from HTML, but the paper got rejected anyway.]. Objects are represented in XML by a set of tags that describe the states of each of the objects’ members. The XML format also provides a means to support versioning. A program can accomplish this by parsing the XML data to interrogate its format, and then converting the old format to match that required by the current software. One of the advantages of XML is that it is not dependent on a particular object model. XML data can be read and written by systems outside the Java architecture such as relational databases. Because XML is HTML-based, XML parsers can not read or write formats such as non-HTML plain text files or images. [As noted before, Verdantium now persists objects in XML].
XML can be used in a variety of applications. An example of XML’s flexibility is the Simple Object Access Protocol (SOAP) which uses XML as the basis of a wire format for remote method invocation using HTTP [3]. The Java implementation of SOAP has some architectural similarities to Verdantium in the sense that they both use Java interfaces as opposed to base classes to represent the fundamental object types of the system. The element types in SOAP are implemented using an interface hierarchy to provide the methods supported by each type of SOAP data. Instead of the properties list metaphor used by Verdantium, SOAP represents data as a linked collection of structured types: arrays, simple types, compound records, and object references. [It could be said that XML describes "nouns and verbs" but it doesn't describe any kind of "vocabulary". As a result, Verdantium has classes that scan the format of the XML file, and then determine which component should load it. In a sense, it answers the question, "which component speaks in this vocabulary?"]
5. ACKNOWLEDGMENTS
The author would like to thank all the people who made helpful suggestions about the architecutre: Dr. Edward Ashcroft, Dr. Timothy Lindquist, Dr. David O. Hestenes, Dr. David Halliday, Al Butkus, Pat Reany, and Dwain Desbien. I would also like to thank Dr. Tony Faustini, without whom I may never have discovered the Java language.
6. REFERENCES
[1] Apple Computer. Inside Macintosh OpenDoc Cookbook, Addison-Wesley, Menlo Park, CA (1996).
[2] Apple Computer. Inside Macintosh OpenDoc Programmer’s Guide, Addison-Wesley, Menlo Park, CA (1996).
[3] Chappell, D., “Simple Object Access Protocol (SOAP) and Firewalls,” Web Page, http://msdn.microsoft.com/xml/ general/soap_white_paper.asp
[4] Coad, P., and P. Mayfield, Java Design, Printice Hall, Upper Saddle River, NJ (1999).
[5] Feghhi, J. Web Developer's Guide to Java Beans, Coriolis Group Books, New York, NY (1997).
[6] Ferrel, P. J., and R. F. Meyer, “Vamp: The Aldus Application Framework,” Proc. ACM OOPSLA, 185-189 (October, 1989).
[7] Fowler, M., Refactoring, Addison-Wesley, Menlo Park, CA (1999).
[8] Fuller, J., and A. Meadow. Essential OpenDoc, Addison-Wesley, Menlo Park, CA (1996).
[9] Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns, Addison-Wesley, Menlo Park, CA (1995).
[10] Green, T., “Research Issues of Geometry-Based Visual Languages and Some Solutions,” Ph. D. Dissertation, Arizona State University, Tempe, AZ (1999).
[11] Li, S., and P. Economopoulos, Professional Visual C++ 5 ActiveX/COM Control Programming, Wrox Press, Chicago, IL (1997).
[12] MacBride, A., and J. Susser. Byte Guide to OpenDoc, McGraw-Hill, New York, NY (1996).
[13] Microsoft. “Microsoft Office”, Computer Software, Redmond, WA.
[14] Morrison, M. Presenting Java Beans, Sams, Indianapolis, IN (1997).
[15] Reenskaug, T., and A. L. Skaar, “An Environment for Literate Smalltalk Programming,” Proc. ACM OOPSLA, 337-345 (October, 1989).
[16] Sun Microsystems, “Enterprise JavaBeans Technology,” Web Page, http://java.sun.com/products/ejb/
[17] Sun Microsystems, “Java AWT: Delegation Event Model,” Web Page, http://java.sun.com/products/jdk/1.1/docs/guide/ awt/designspec/events.html
[18] Sun Microsystems, “Java Beans, Part 1,” Web Page, http://developer.java.sun.com/developer/onlineTraining/ Beans/Beans1/simple-definition.html
[19] Sun Microsystems, “Java Studio,” Web Page, http://developer.java.sun.com/developer/Books/ Graphics2/index.html
[20] Sun Microsystems, “Java Technology and XML,” Web Page, http://java.sun.com/xml/index.html
[21] Sun Microsystems, “Keynote Presentation,” Web Page, http://java.sun.com/javaone/javaone96/McNealy.html
[22] Symantec, “Visual Café,” Computer Software, Cupertino, CA.
[23] Vizard, M., “Pull over, Sun; Big Blue’s gonna drive,” InfoWorld, 19(8), 3-4 (Feb, 1997).
[24] W3C, “Extensible Markup Language (XML) 1.0,” Web Page, http://www.w3.org/TR/1998/REC-xml-19980210
Thursday, September 6, 2007
New Verdantium Version -- 0906
I did a lot of work over labor day, particularly on the JUndo Runtime. Here is what's in the latest version:
JUndo Runtime-- Fixed a series of issues in the runtime, particularly memory reclamation. Much of the original finalizzation code has been fixed, and turned back on. This is to say, the code that actually reclaims milieux after a garbage collection run has been turned on again. The JUndo Runtime actually gets faster after it has garbage-collected milieux, so this should provide large performance improvements for some operations. In addition, a number of C++-isms have been removed from the code.
I think this is a huge change in the grand scheme of things. It makes the undo system much more efficient, particularly for very large programs. This was one of the last serious bugs I have observed in the runtime, and fixing it brings the runtime much closer to moving to a pre-alpha or alpha state. It also gives people who read code an idea of how the runtime is supposed to manage memory when fully implemented. In most programs, the vast majority of milieux are garbage-collected, and hance only the remaining milieux should contribute to the performance of milieux lookups by the runtime. This goes a long way toward demonstrating how JUndo classes can be efficient.
Verdantium-- A series of new features has been added to the DrawApp drawing application such as the ability to erase individual rendering primitives. I focused on DrawApp operations that are relatively easy to do, but relatively difficult for non-temporal systems to undo. I think the new DrawApp code makes a very strong case for temporal undo, particularly with the new refinements to the JUndo Runtime described above.
Poseidon Sourceforge Package of Verdantium-- Poseidon shows how to create a small, useful component that can be embedded in other components (or run standalone), provide macro-scripting, support multi-level undo, be printable, display page setup and print preview windows, have a reasonable user interface (although without pretty icons), load/save files in a fairly compact XML format, provide illustrated online help, and fit within a .jar footprint of a little less than 100K. This will provide a template for third parties to add their own custom components to the Verdantium system. Different components can be compiled seperately from each other and then dynamically linked into the Verdantium system using Discovery. In terms of content, this component is a simple ripple-tank simulator for educational use in entry-level (e.g. high school) physics classes. It allows one to specify simple wave positions, frequencies, relative amplitudes, etc. and then see how the waves interfere. The underlying algorithm provides a very quick-and-dirty approximation of wave effects, and isn't guaranteed to be accurate in all circumstances (it chooses speed over accuracy). This release resolves symbols that changed due to the recent refactoring of Meta.
JUndo Runtime-- Fixed a series of issues in the runtime, particularly memory reclamation. Much of the original finalizzation code has been fixed, and turned back on. This is to say, the code that actually reclaims milieux after a garbage collection run has been turned on again. The JUndo Runtime actually gets faster after it has garbage-collected milieux, so this should provide large performance improvements for some operations. In addition, a number of C++-isms have been removed from the code.
I think this is a huge change in the grand scheme of things. It makes the undo system much more efficient, particularly for very large programs. This was one of the last serious bugs I have observed in the runtime, and fixing it brings the runtime much closer to moving to a pre-alpha or alpha state. It also gives people who read code an idea of how the runtime is supposed to manage memory when fully implemented. In most programs, the vast majority of milieux are garbage-collected, and hance only the remaining milieux should contribute to the performance of milieux lookups by the runtime. This goes a long way toward demonstrating how JUndo classes can be efficient.
Verdantium-- A series of new features has been added to the DrawApp drawing application such as the ability to erase individual rendering primitives. I focused on DrawApp operations that are relatively easy to do, but relatively difficult for non-temporal systems to undo. I think the new DrawApp code makes a very strong case for temporal undo, particularly with the new refinements to the JUndo Runtime described above.
Poseidon Sourceforge Package of Verdantium-- Poseidon shows how to create a small, useful component that can be embedded in other components (or run standalone), provide macro-scripting, support multi-level undo, be printable, display page setup and print preview windows, have a reasonable user interface (although without pretty icons), load/save files in a fairly compact XML format, provide illustrated online help, and fit within a .jar footprint of a little less than 100K. This will provide a template for third parties to add their own custom components to the Verdantium system. Different components can be compiled seperately from each other and then dynamically linked into the Verdantium system using Discovery. In terms of content, this component is a simple ripple-tank simulator for educational use in entry-level (e.g. high school) physics classes. It allows one to specify simple wave positions, frequencies, relative amplitudes, etc. and then see how the waves interfere. The underlying algorithm provides a very quick-and-dirty approximation of wave effects, and isn't guaranteed to be accurate in all circumstances (it chooses speed over accuracy). This release resolves symbols that changed due to the recent refactoring of Meta.
Subscribe to:
Posts (Atom)