Sun Promotes JavaFX's Declarative Semantics

About a year ago at the last Pikes Peak Java Developer Group (PPJDG) meeting, several people responded as if I was crazy when I spoke about the advantages of declarative languages in relation to JUndo (JUndo has been a declarative language from the beginning). Now more people seem to be getting on the declarative language bandwagon, including Sun Microsystems. John O'Connor has an article on Sun's web site about the declarative nature of the new JavaFX scripting language:


http://java.sun.com/developer/technicalArticles/scripting/javafx/lc/part2/


The similarities and differences between JUndo and JavaFX are interesting. JavaFX provides a declarative user interface to a web application, which presumably has either a server-side file store or a server-side RDBMS as its data model. So one could think of it as a declarative user interface for a mostly imperative data model. JUndo provides a declarative data model that is then wrapped with a imperative Swing interface as part of a Verdantium component. That is to say, the two technologies are opposites in this sense.

JavaFX is a potentially important language, and one that will probably influence other declarative languages in the future. Will GUI code becomes declarative in the future? Perhaps. Only time will tell.

Started Adding Binary Tree Code to Umeta package of JUndo Runtime

I've found threaded binary trees to be a useful data structure on several occasions. That is one of the reasons why they exist in the Meta project. However, I have realized that there is a need for a binary tree that is undoable. That is to say, modifications to the tree can be reversed upon user request. To facilitate this, I have started adding undoable binary tree classes to the Umeta package of the JUndo Runtime Sourceforge project. The code is still in an incomplete state, and it will take some time to get the (non-undoable) Java fully converted to (undoable) JUndo. Once the tree classes are complete, I plan to use them in some Verdantium demo code.

One thing to notice is that the erasure patterns in methods pruneLeft() and eraseAll() differ from those in LowLevelBinTree in the Meta project. In the Java Meta code, pointers had to be assigned so that the identity of the next node would be picked up before the node was disconnected (disconnection deletes this information from the node by setting the node references to null). This creates some code that is tricky and hard to follow. It uses the temporary pointers in some rather complex ways. In addition, the technique for using the temporary pointers varies depending on the data structure. For instance, lists and trees require different temporary pointer techniques.

The new JUndo code for LowLevelBinTree uses a completely different paradigm in pruneLeft() and eraseAll(). The JUndo code traverses the structure in one time stream and disconnects the nodes in a different time stream. In the traversal time stream, the nodes aren't disconnected and hence there is no reason to build temporary traversal pointers such as delTemp. However, the nodes still get disconnected in the other time stream. The disconnection time stream's final milieu is the one that gets returned by the erasure method. This pattern for using multiple time streams makes deletions simpler and more consistent across data structures.

Added SimpleForm component to Verdantium Downloads

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.

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.

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

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.

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.