Dieter Krachtus' Weblog *** pro bono lateral thinking

Previously predicted and discussed in one or two recent postings, SAMP is finally here. From what I hear it contains:

Apache 2.2.8 MySQL 5.1 PHP 5.2.5 Ruby 1.8.6 Perl 5.8.8 Tomcat 6.0.16 Squid Proxy 2.16.x

no word about Java. Don't worry, it comes "on silken paws"

As much as possible, Metawidget does this without introducing new technologies. It inspects, at runtime, an application's existing back-end architecture (such as JavaBeans, annotations, XML configuration files) and creates components native to its existing front-end framework (such as Swing, Java Server Faces, Struts or Android).

Recently I had some discussions with the father of MetaWidgets (Richard Kennard). One questions I raised was later answered in his blog which you should read first to understand what follows. Before I pushed the send button in my mail client I decided to post my reply here:

 1. Separation of Concerns:

I still think the solution I gave is better in most cases and I give my reasons:

 2. Duplication of Declaration

One complain against the suggested metawidget.setFields("firstname","lastname","dateOfBirth"); is that it introduces duplication by using hardcoded strings named after the Bean's fields...but so is the MetaWidget AddressBook example by effectively restating that the domain has a firstname field by using the getValue(...) method:

mContactSearch.setFirstnames( (String) metawidgetSearch.getValue( "firstnames" ) );
mContactSearch.setSurname( (String) metawidgetSearch.getValue( "surname" ) );
String type = (String) metawidgetSearch.getValue( "type" );

To resolve this dilemma I suggested to define String-constants in your beans for some of its fields, and refer to them throughout your code: in bean annotations, the infamous metawidget methods setField(...) and getValue(...), etc.:

public class BusinessBean
public static final String FIELD_FIRSTNAME = "firstname"; // String constant
private String firstname;
@NamedField(name=BusinessBean.FIELD_FIRSTNAME)  // used to *name* the field/getter
@UiComesAfter(BusinessBean.FIELD_TITLE)
public String getFirstname() {return firstname;}

this way the original name of the field/getter is fully ignored and the new name is used whenever one calls a metawidget-method from the view:

instead of metawidgetSearch.getValue("firstname"), one writes:
metawidgetSearch.getValue(BusinessBean.FIELD_FIRSTNAME)
and instead of metawidget.setFields("firstname","lastname","dateOfBirth"), one writes:
metawidget.setFields(BusinessBean.FIELD_FIRSTNAME, BusinessBean.FIELD_LASTNAME, BusinessBean.FIELD_DATEOFBIRTH)

The String constants are used everywhere - in the Domains' annotations, metawidget method calls and possibly resource bundles. In my opinion this improves separation of concerns and clarity, reduces duplication of declaration and error-prone design. Even refactoring of your bean or GUI is now much more easily done now. I acknowledge that some people do not want to change their Beans by adding String constants (since I questioned the additions of @UiComesAfter, @UIHide myself). Still, I see the String-constants and the @NamedField annotation and the setFields(...) method only as an advantageous option for cases with specific concerns such as flexibility. I agree, the default behaviour of MetaWidget should be as it is now. You just take your Beans, modify it with @UiComesAfter, @UIHide and duplicate field names in error-prone getValue(...) method calls as long as one has the option to do otherwise.

3. Not just Java

With the exception of HibernateInspector which is usually already there I am no fan of writing additional XML as a way to define component sequence. It seems I have at least one supporter: (Richard's Interview at Javalobby.com):

"I remember the first releases of JPA were coming out. I thought being able to annotate your domain objects instead of writing XML mapping files was awesome - it had this real spirit of 'Don't Repeat Yourself'. We'd gone from having to manage duplicate field declarations in 3 places (your database schema, SQL statements, domain objects) to just 2 places (your domain objects and an XML mapping file) to just 1 place (an annotated domain object). I thought that was great."

Sometimes your own words fall back on you like blood-hounds on their master ;)

I never got so many emails in response to a post within hours. JLAMP and the idea to convince ISPs to adopt Java through bundling with MySQL seems to attract much popularity.

I am truly convinced of the robustness and performance of Java and the idea of an open source service mix you can choose from. Not LAMP but something more flexible like J-L/S-A/G/T-M/D-P

J...Java
L/S...Linux/Solaris
A/G...Apache/Glassfish/Tomcat/etc.
M/D...MySQL/Derby/etc.
P...PHP, JPHP/JRuby/Jython/etc...

The nice thing here is that one could get a 100% Java based solution for all parts of LAMP at some point and directly use JRuby and JPHP with the well known performance and robustness of Java. From Sun I would expect to throw technologies like ZFS into the mix and provide simple preview DVDs for ISPs with a JLAMP solution mix that offers a better TCO then any other stack. Moreover, discussion with Linux distributors to promote JLAMP seems a good idea since it may become a win-win situation for everybody (ISPs, their customers, Linux as a platform, etc.) given that the MS SQL Server is slowly eating up more and more of the low-price segment.

PHP and even better JRuby support in Netbeans (or Eclipse for that matter) would be the icing on the cake

 

People seem to wonder what is going to happen with JavaDB/Derby after Sun bought MySQL and if the latter will be bundled with the JDK at some point in the future.

Lateral thinking leads you perhaps to the opposite question: Will Sun at some point add J to LAMP and win some major ground in the shared hosting space? This is an area of business where cost (i.e. how many customers can use one server) is king and robustness and performance come in second place. In lateral thinking one often benefits from asking stupid questions: so let's just assume for one second that Sun bundles Java/Glassfish with MySQL - what other steps are necessary to convince ISPs to really use it?

The question is would it really annoy a lot of people if Sun bundles Java/Glassfish with MySQL? Sure, as long as Sun also offers a standalone MySQL version.

Now about getting ISPs and customers switch from LAMP to JLAMP:
Once ISP realize that they can create the same number of virtual servers on a single real CPU - independent if their customers use mainly PHP or mainly Java - they should gradually switch.
Once ISPs start offering J-LAMP at the same price as LAMP, customers should switch as well and those ISPs still using LAMP over JLAMP are eventually forced to come to their senses.

I hope you enjoyed this somewhat pure fictional thought experiment

Usually Applets follow the init/start/stop/destroy life-cycle. For enterprise Applets this is a good thing since you can keep them alive even after a call to destroy() or use Singletons for communication between Applets.

Still, if Applets ever want to play a role for small add-like flash-type browser applications we need to get a fool-proof mechanism that frees the average developer from the risky task of removing the Applet from the VM's memory. Imagine a future where you load ~40 Applets each day while browsing the internet. Imagine further that most of this Applets don't clean up memory properly after a call to destroy(). What do you think, might this influence your browsing experience negatively or other Applets started in the same VM?

I suggest that for 90% of the Applets it would make sense to completely GC the Applet after a destroy() and rebuild it from scratch after a call to init(). With completely I mean everything -- even Singletons. Obviously special classloaders could do the job and technology like OSGi bundles clearly show that you can easily unload and reload newer bundle versions during runtime.

In conclusion this doesn't mean that we should necessarily change the default behavior of Applets where the developer has to care for GC to a great extend. Still, we need to have the option to automatically and fully remove an Applet from memory either with a simple method-call in destroy() or by extending a special subclass of JApplet like JVApplet (v...for volatile) which uses special classloaders automagically.

I invited Chris Deckers today and after a couple of hours using the most advanced debugging techniques we finally squashed one of the most obscure bugs in SWTSwing on my MacBook. This finally means we can recommend you to try out "Eclipse on Swing" on OSX!

Get the OSX-ready version of the EOS plug-in from the project website.

The two screenshots above are proof that the bug in the StyledText component is history!

Three days ago my copy of "Filthy Rich Clients" by Chet Haase and Romain Guy finally arrived

On a personal note, if people want me to directly give them a brilliant book review (without even so much as reading a single word) they should fulfill the following simple checklist:

Where is my gift basket Chet?! Given insufficient bribes I actually had to read it and base my review - which is somehow said to say - solely on facts.

Filthy Rich Clients (FRC) which is also an acronym for FRanCe (cheeky Romain) consists of 4 big parts comprising 19 Chapters. Part I and II deal with graphics fundamentals and advanced rendering. Every Swing/Java2D expert should already knows this by heart since it is one of the reasons why Swing is so very flexible and fun. Although all this information is in some way already available elsewhere and you can always dig into the code and experiment to find out every last detail, FRC presents it in a complete and concise way I never read before. In comparison to other books dealing with this area of expertise one often notices when reading FRC that it benefits from the fact that Chet actually was involved in creating the parts of Java he is talking about. So even if you are a Swing know-it-all keep Part I+II under your pillow as a reference book.

Part III is my favorite dealing with animations in general before leading to a crescendo in chapter 14+15 by introducing the great Timing Framework (TF). The TF version 1.0 is pretty mature and powerful by now. At the very beginning when Chet designed TF I often missed such a complete description of the concepts and his thoughts behind it as we now have with these four chapters. The TF and the FRC book is not about adding more bling and cool effects to your applications but to actually improve the experience people have with it. Make it both simpler, fun and more efficient.

A while back I wrote a little TF showcase for JavaOne -- a Sudoku game.

Left aside that Sudoku is a total bore, this version of it uses animations in a subtle way so you hardly recognize them. The animations simply disappear because this way of user interaction feels very natural and just right.

No, sorry...made that up, no movie! You can't just lean back and not read the book by saying "Thanks but I wait for the movie!". Go and buy it.

In the last years the popularity of Swing applications seems to be on the rise. There are many reasons - like freedom of the Java platform, ease of long-term maintainability or platform-independence. Another aspect is versatileness. This measure can be put to the test by checking how well "connected" one technology is to others. The technology with the most "edges" to other technologies would end up in the center of a graph-representation after applying an energy-based layout algorithm.

There are already many "edges" between Swing and the world of SWT shown by technologies (I am admittedly affiliated to ) like Eclipse on Swing, SWTSwing (read more), the SWT_AWT_brigde, SwingWT, etc.

Being surrounded by many competing and compatible technologies can be seen as a threat because people are not locked in and can leave you anytime. But it also means that people can later come to you by using a different technology in the first place that is connected to you. People may choose you for not being locked in and knowing that many different compatible technologies and opportunities are only a step away. This is vital not knowing what the future may necessitate. Whatever the case - being connected to many other technologies generates a lot of "flux" for your technology. Even better, finding yourself in the middle of many technologies means that most of the "traffic" goes through you with a great chance that some of it sticks. Being connected to many, being in the middle of a versatile of technologies and possibilities becomes ever more important when competing in new areas like mobile devices, RIA, or Web2.0.

Almost weekly I read about a new or already mature technology that fills another gap in this cloud of connected technologies. One nice example I already follow for a long time is WebCream (commercial and GPL licensed). It automatically transforms Java Swing and AWT applications into fully-functional HTML and AJAX websites. It then emulates user actions as GUI events for the Swing application to ensure that the business logic executes correctly. WebCream is unique in that it requires no modifications to existing applications, and does not require programmers to learn any APIs other then AWT/Swing.

Finally, the importance of being well connected to others, even to competitors, hopefully becomes clearer. Strong ties to Swing has many advantages for SWT in store as every application based on it can now be converted to Swing and then run as HTML/Ajax.

Here an example:

Java Application

Obviously it won't work for all applications which isn't a bug in WebCream but rather a limitation of HTML/Ajax. Still, most of the SwingSet Demo and all standard Swing widgets run out of the box. There are many other Java frameworks with a Swing-like API producing similar interactive Ajax code but non to my knowledge can allow you to deploy the same code base as Desktop- or  WebStart-Application, Applet or Ajax/Html. Obviously one only would use WebCream in very special cases where this flexibility is more important then anything else. Still - these cases exist and it is good to see that Swing keeps this door open, for itself and everybody connected to it.
 

Yes it does! When writing the code for the newest version of the "Eclipse on Swing" (EOS) plug-in I also planned to support OS/2 -- meaning download Eclipse 3.2.2, install EOS and you are all set. This was supposed to work in theory but not having OS/2 available I never confirmed it in practice.

Luckily with the help of Jürgen Ulbts who is running eComStation 2.0 RC1, we now know more -- EOS works out of the box on OS/2. Here are a few of the screenshots he sent me showing "Eclipse on Swing" with the Lipstik- and the Jgoodies Plastic Look and Feel.

Lipstik Look and Feel 

I just released a new major version of the EOS plug-in (Eclipse on Swing) -- download it from the EOS website. Feel free spreading the word and integrate the Get-EOS-teaser to your blog:

<a href="http://eos.sourceforge.net" target="_blank">

<img style="margin: 8px;" alt="GetEOS Download Button" title="GetEOS"

    src="http://jroller.com/resources/d/dk/get_eos3.png"></a>

EOS requires Eclipse3.2, Java1.4+ and theoretically should run on all platforms supporting Swing:

*** these platforms are to our knowledge (which is admittedly limited) not supported by native SWT (ever or yet).

Proof that it now also runs under OSX (don't test it on OSX yet, you might be disappointed, there is some major Swing-unrelated OSX-specific bug which will soon be gone):

On Windows/Linux it already works very good with only one deadly bug left - right click on Project and open it. It doesn't crash Eclipse but most things stop working. There are many more bugs but they are simply less deadly.

Obviously I cannot test EOS for all of these platforms. Feel free to send me some feedback or comment on this thread in JavaLobby.

Performance tuning is an important aspect when it comes to conquering new fields for Java. One of the new advances of the coming Consumer JRE will be a much better behavior when it comes to Applets - namely they won't freeze the browser anymore. Now this is only one side of the medal - the other one is Applet startup time. When we assume the Browser-JRE is already loaded, the startup time of the Applet is determined by how fast the many class-files and resources can be loaded from the server. Apart from the most trivial Applets, in the realm of RIA applications this takes a lot of time.

Some time ago I talked about a mechanism I called AOT-CL (Ahead Of Time Class Loading). Since it was ongoing work I didn't go in the specifics what I had in mind with it but simply called it a means to tune Java performance by loading classes ahead of time. Today I got a an email showing that most people perhaps didn't get my hints in what areas AOT-CL should be really used.

One of the astonishing things with Java (especially in the early days) was that you could simply discover and load classes from everywhere and run them. URLClassLoader + Server - bang! Now this is used but not in the most clever way. Most of the time you basically download all classes + resources ever necessary for your program and then execute it. The alternative would be  to download those files  the moment you need them --  which considering the network latency as a weak spot may result in a horrible user experience.

With Applets we want a Flash-like experience. An Instant-On experience. So far with Applets one gets the Browser-Freeze experience. What you want is that as little as possible is downloaded from the server -- so your Applet can start up instantly. Having a non-trivial application this is kind of a problem. Let's say your Applet allows the user to create some elaborate drawing and you allow him to export everything as PDF at the end -- then you need to include itext.jar. Usually I have about a dozen .jar files to download ranging between 2-10 MB in total and although they are not immediately needed at Applet startup I force the user to wait minutes while his browser is frozen till they are downloaded -- unacceptable! To solve this problem AOT-CL comes into play:

Clever describes the task of determining the best sequence of downloading classes/modules/resources, so that they are already there once they are needed. I had good experiences creating modules and determining their download sequence simply by protocoling which classes are used early and which always late by letting users interact with the application. In another much faster approach I described the classes and their relationship/distances as nodes/edges of a network and used graph clustering to package classes into very small modules and determine their loading sequence.

You should also be prepared for the case that AOT-CL fails (in my tests it never did). Failing means a class is needed but AOT-CL hasn't downloaded it yet. I've build in a progress-overlay (glasspane is one option) to indicate that I am now fetching the few needed files to continue execution.

Now there are so many more little hints and tricks I learned to improve user experience with AOT-CL but let's wrap up everything at this point. With the Consumer JRE on the horizon we complement it with:

 
Benefits of AOT-CL:

Projects that pass Sun's compatibility kit tests also can use the official Java logos for free, said Rich Sands, OpenJDK community marketing manager at Sun.

The new move significantly broadens the horizons of open-source programmers who want to participate in Sun's open-source Java project, called OpenJDK and formally launched in May.

More Info: