Thoughts about JavaFX

JavaFX has the potential to become something interesting. While there are many articles written about JavaFX, I have yet to see a non trivial JavaFX application. When browsing Dzone articles, it almost looks like JavaFX is popular, while it's not.

There's no amazing UI control and I am not sure that I could code an entire JavaFX application without writing few java classes. I am not fond of applets and I haven't written any for years. JavaFX doesn't solve the "applet problem".

I don't know about any cellular phone which is officially supporting JavaFX. I am also not aware of any software vendor distributing desktop applications written with that technology.

In my opinion, JavaFX is not ready for production use. What motivated the release of JavaFX? Maybe they've been advertising it for too long and they had to release something. I'll give JavaFX probably one more year before attempting to use it.

serialVersionUID in Netbeans

Most of the time, I use Netbeans when I have the choice. What I don't like about Eclipse and is getting me worried time to time is when the IDE freezes for a long time when you're not really doing anything.

Last week, I needed to build a simple Java project (Maven based build), about 50 000 lines of code(from sloccount). The project contains one core project and few sub projects. Eclipse took about 30 minutes to import the project and set up the classpath. That performance was achieved under a Quad Core, 2 GB of RAM, which is amazing. I had only Eclipse, Firefox and a terminal opened. I tried with both q4e and m2eclipse plugins, same results, I could hear my CPU making lots of noise. I had time to start cooking, boil water for coffee and do some other things, before the IDE was ready to use.

One of many missing features in Netbeans is the ability to generate the serial version ID for a serializable class. With Eclipse, you get the warning all the time, and you can choose between:

• ignoring it
• adding the annotation @SuppressWarning("serial")
• generating the serial version id.

Available plugins for Netbeans
There are two plugins available for Netbeans, that I am aware of : UUIDGenerator and serialVersionUID generator. I only have success with UUIDGenerator (most of the time, I am running the latest development build under Linux and Windows and lately Mac OS Leopard).

Enabling Serialization warnings
Under Tools->Options->Editor->Hints->Standard Javac warnings, select Serialization. That way, you'll see a marker notifying you that you're missing the declaration of a serialVersionUID field.




Generate the serial version ID
You can generate the serialVersionUID using the shortcut Control-ALT-Z. You can copy the generated contents to the clipboard and paste it inside your class.

Merry Christmas

XPontus and VFSJFileChooser were released this evening. I wanted to release before Christmas! Still the same stress and anxiety before and after publishing a new version. Now, I need to start advertising in forums, etc.

The last few days, well more nights than days, have been mostly about testing XPontus installers, fixing bugs, reviewing as much code as I could.

Merry Christmas everybody and happy new year!

Handling database changes without complete migration

The ORM market
ORM tools are great. Products like Hibernate, JDO, JPA, IBATIS, Torque, and others made life easier for developing database enabled applications.
Using JDBC when your application is database intensive with lots of table can be lots of work especially if lots of your existing code base doesn't provide some DAO classes.
Usually in ORM tools, you map a set of fields to some columns, using XML or annotations, and you're done.

Most J2EE and core Java developers have faced database changes and migration issues at least once. The problem is pretty crucial when your database model is shared by other applications which can't be upgraded(for many reasons).

The concern

• How to handle database changes which keep happening?
• Should/Could you stop providing backward compatibility?
• Is upgrading the database model your only solution?
  

The application history

• You have an existing application with a model which has been designed carefully and everything is going well.
• You have a server side application with a database model and client applications with the same database model as the "main server".
  
• A month or a year later, you need to make lots of changes in couple of tables, replace some primary keys, introduce some non null foreign keys, etc.
• You were using raw JDBC mostly and plain SQL. Now, you would like to use that brand new bleeding edge technology(Hibernate, JPA, Ibatis, name it).
  
• Here and there, you might have been using a very old ORM tool which was convenient at the time and is still getting the job done.
  

Constraints

• You need to be able to support simultaneously clients(applications) running older and newer versions of the database schema.
• You cannot force the customer to upgrade for many reasons(hardware dependencies, partner application compatibility, the customer doesn't want to, etc.)
• You need to keep adding new features which might involve altering again the existing schema
• Your table contents are now messed up, invalid or irrelevant values here and there because the database column has a "NOT NULL" property.
  

Possible solutions

• One might be tempted to maintain different versions of the same database, but let's say I have 100 versions since 1994.
• Ok, let's use JCR to provide another abstraction level, maybe checking a node property before deciding which class to map, overkill in most cases?
  
• "Dear customer, please, upgrade and buy the new pack to be able to use that version which also provide bug fixes and new features"
  
• Hum... last resort "Dear customer, you should upgrade because that X, Y, W feature fixes lots of serious security holes which will affect your network"
• Ok, from now on, every table will be like a key-pair, probably not very wise most of the time, especially if it will involve rewriting most parts of a huge application.
  

The problem is here, a fix must be delivered!
What I would probably do is :

• Stick with raw SQL and migrate ORM mappings to JDBC, as needed(if the ORM tools cannot ommit fields), to ignore some properties depending on the client database version. I can insert some dummy values when I have no choice when dealing with "old software clients".
  
• Use native SQL queries and JDBC only
• Use named SQL queries with binding and anything tool that supports it Hibernate, Ibatis, a resultset handler from JdbcTemplate or DbUtils, etc. Some dummy data will need to be inserted when not available(new non null columns).
  
• If the problem gets out of hand, way too many changes, I'll probably want to use a non relational database and handle relationships myself(An object or XML database might do, but might not scale)
  
• Another solution, would be JCR. I messed with JackRabbit once, and the pain was brought. Performance, concurrency and the API probably improved since then.
  

I would definintely try to avoid running multiple database versions at the same time. You can easily go from 1, 2 versions and then reach 100.

What would you developers do in such a situation?

JDK7 changes

I had a surprise this morning while playing with System.getProperties. I am using JDK7 and displaying the system properties in a Swing JTable.
When I don't specify the number of columns I get a null pointer exception. It happens when populating the array contents, not at initialization.
This will throw a NPE:

data = new Object[NB_ROWS][];

This will not

 data = new Object[NB_ROWS][NB_COLUMNS];

Code excerpt

public JavaEnvironmentModel()
        {
            Properties envProperties = System.getProperties();
            NB_ROWS = envProperties.size();
            data = new Object[NB_ROWS][NB_COLUMNS];
 
            // for google blogger parser, no generics(Entry)
            Iterator it = envProperties.entrySet().iterator();

            for (int i = 0; it.hasNext(); i++)
            {
                Entry entry = (Entry)it.next();
                data[i][PROPERTY_COLUMN] = entry.getKey();
                data[i][VALUE_COLUMN] = entry.getValue();
            }
        }

Drinking a huge cup of Java

I am working again on XPontus XML Editor. I believe that I'm ready to go for another round.

I am happy to see that there are so many people using the software. Since the intial XPontus release, there are about 10 000 official downloads from Sourceforge and probably 12 000 from other sites grabbing the files directly by HTTP. I didn't expect such a thing at all and it gives me energy to work again on the application.

Here are the main things that I learned since the XPontus inception:

• Provide a project roadmap even if it's ambiguous or you won't do anything listed :-)
  
• Don't use build tools such as Maven if you expect lots of people to contribute to a project, use a simpler but powerful tool such as Ant.
  
• If the component is has a public API, finish writing all the documentation before releasing: 20 bugs+good documentation is better than 5 bugs + no documentation, there will be bugs anyway.
• Advertise a project enough but not too much, people will expect the application to be at the best commercial level even if there are only 2 or 3 people working on the project.
  
• Don't assume you know what you're writing because you do code similar things often, read books or articles about the subject whenever you can.
  
• Don't try to make a big application without taking time to do it well, or as well as possible
  
• Try to think more like a user or a client of an API, rather than a programmer. The application is for users at the moment you distribute it.
  
• Make it look good and then make it work : you love what you see and then you love what's inside.
  
• Don't necessarily provide many features, few working features are better than a zillion of unstable features.

My goals are simple for the next release:

• The application will probably be lighter and faster (java reflection abuses, bad programming, race conditions, etc.)
  
• Partial rewrite and more use of design patterns(without trying to recognize them everywhere though! ).
• Fix the current bugs, usability/stability issues. No new features except maybe XPath2, XQuery. VFSJFileChooser will be introduced in the release as an optional plugin.
  
• New, simple but powerful API : If you explain the components relationships and the logic of the application, it should almost sounds like common sense, not magic or absurd.
  
• One should be able to reassemble, disassemble or extend XPontus without much effort. It looks difficult though, how can someone integrate very easily an application that uses a plugin system?? Last time I integrated parts of JEdit into an application I won't say it was too tough but it wasn't that simple even if I believe that JEdit modules are well written most of the time.
  

VFSJFileChooser 0.0.3 released

VFSJFileChooser was released today after some additional tests. Nothing much to say, I guess I'll wait for comments.

About VFSJFileChooser 0.0.3

I guess I'm ready for the third release of VFSJFileChooser thanks to Stephan Schuster. He helped a lot for that release(bug reports, patches, suggestions). I'll probably release tomorrow after few tests.

Here is the changelog:

• One noticeable feature is speed :-). VFSJFileChooser was too slow I.M.H.O.
• Navigation icons are "always" visible now. They didn't show when the java look and feel set, didn't derive from MetalLookAndFeel. I borrowed some icons from Tango and famfamfam which are now the default icons used.
  
• Bug fixes for directory selection among other things
  
• The VFSUtils class supports the methods setFileSystemManager and setFileSystemOptions. You can set those values at anytime. when the VFSJFileChooser class is instanciated, it checks if VFSUtils has a filesystemmanager set, if not it creates one. Files are always resolved with the FileSystemOptions object in VFSUtils.
  
• Upgrade to webdavclient4j (http://webdavclient4j.sf.net) as Jakarta Slide is dead.
  
• Cleaner but incompatible API (Enums instead of int fields) : I started to refractor code here and there. I am making full use of JDK5 as VFSJFileChooser is not compatible with jdk14 and older releases. Enums are introduced for few classes which breaks the API. The method setFileselectionMode of VFSJFileChooser now accepts an Enum as parameter. The methods "showOpenDialog" and "showSaveDialog" return an Enum too.
  
• Sorting support : The details table has now sorting support again in the jdk5 branch. The jdk5 branch is the most up to date(patches, general improvements, etc.). The jdk5 will become the default branch. I now develop on jdk5 to ensure code compatibility.
  

The Windows look is still not supported. I'll look at it and see what can be done. For now, I only have my old laptop running Linux so I can't really work on it. Any help in that regard would be appreciated.

About XPontus and VFSJFileChooser

Lately, I keep receiving questions about VFSJFileChooser and XPontus. Even if I didn't answer, I did read all the emails. I thank you all for your interest and your comments.

I have started to relocate to Toronto and I am still looking for a new job which is my primary focus right now. I am still looking at XPontus and VFSJFileChooser APIs time to time(the good, the bad and the ugly).

I intend to work again on those projects as soon as I'll become professionaly stable again.

Thank you for understanding that.

Upcoming VFSJFileChooser release

I've been trying to make VFSJFileChooser compatible with jdk 1.5 lately. Know bugs have been fixed. There's no sorting for now in the details view, but the rest is working well.

SwingUtilities.getWindowAncestor seems buggy in jdk5 SwingUtilities.getWindowAncestor(Component ComponentThatCouldBeAFrame) seems have issues. Trying to open the file dialog was throwing null pointer exceptions in jdk5. I needed to make another check to see if the component is a frame before creating and displaying the file chooser dialog with jdk5.

        Window window = SwingUtilities.getWindowAncestor(parent);

        if (window == null)
        {
            if (parent instanceof Window)
            {
                window = (Window) parent;
            }
            else
            {
                window = new Frame();
            }
             dialog = new JDialog((Frame) window, title, true);
        }

        else if (window instanceof Frame)
        {
            dialog = new JDialog((Frame) window, title, true);
        }
        else
        {
            dialog = new JDialog((Dialog) window, title, true);
        }

I would like to avoid maintaining 2 branches if possible. There are lots of things that are easily done with jdk6 whereas in jdk5 additional classes are necessary.

OSGI bundles packaging and deployment

I created my first non trivial swing application based on OSGI. I deployed it on Apache Felix and Knopflerfish for testing purposes.

The swing application has about 130 classes, not huge classes. I tried to make a good design using couple of interfaces with some abstractions(docking framework abstraction, file system abstraction, gui components abstraction, plugin manager abstraction, etc.). After few days, I was satisfied with the design and started coding few concrete classes. I made sure that most of the code could be reused quickly in a non-OSGI environment.

In 4 days, I finished programming the core of the application. The only thing left was the gui main window. I wanted to use a docking framework(LGPL, BSD or Apache License).

Using docking frameworks such as MyDoggy or Flexdock in an OSGI environment looks complicated. Most of those libs make some static calls while trying to resolve images or configuration files. Sometimes some properties or other resources are stored in the META-INF folder of the jar files.

MyDoggy
I was surprised to see that, as the library wasn't finding its default configuration file(from the classloader), it was looking for it in my home folder. There's no way to set the default properties using a static method without messing with the source code of MyDoggy (or maybe I didn't see a way).
With Apache Felix I couldn't import sun.awt package used in MyDoggy but I was able to do it with knopflerfish.

Flexdock
With Flexdock, I had an infinite loop, an exception which was thrown all the time, preventing the program to run. It was complaining about not being able to create an instance of the persistencemanager or something like that. Must have been some class loading issues using reflection calls.

I decided to use few JSplitPane at last and I could see the main window of the application, after few hours spent looking into those docking frameworks source code.

To test quickly I was using Apache Felix(embedded) in the application. I had my activators written but no OSGI manifests yet. Later I saw the bundles issues. I didn't want to embed some dependencies directly in my bundles. So I started browsing the web for "osgi bundles" and chatting on IRC. Some guys told me to look at Eclipse Orbit.

Eclipse Orbit is a community effort to create OSGI bundles for common third party librairies. It's a lot of work. I packaged few libraries and it took a bit to import and export the right packages.

The last thing left before going on with that swing application, is to add some listeners so that when a bundle is removed/updated, the GUI and some non visual parts are notified to update themselves.

What makes an API great?

After few years of Java programming, I improved slower than I expected but still... When designing complex software which needs to be reused, I still find it difficult to make quick and "good" choices without adding too much complexity.

In the last branch of XPontus XML Editor(major refractoring), I had a dilemma:

• Release soon : couple of patches and dirty classes which do the job
  
• Wait 4 or 5 months to be ready : clean up the code, perform thorough testing, remove unused classes, add or redesign interfaces, etc.

I choose to release early and fix what I could see or had time to fix. One month after the release, I was like "why did I do it that way? what is that useless piece of code doing over here, etc."

IMHO, an API is great when it's

• simple
• useful
• flexible(without adding too much complexity when it's unnecessary).

I tend to prefer APIs which expose few interfaces, abstract classes and some concrete classes. Complex applications APIs without/with few interfaces, are somehow difficult to maintain, refractor, make evolve.

Playing with Apache Felix

I'm trying to learn more about OSGI and become proefficient with it quickly. Neil Bartlett is writing a book about OSGI. It's available for free but it's not completed yet.

I looked at IPOJO from Apache Felix and managed to create a simple application with it. I think I'll start with plain OSGI programming first. Once I get it right, it will be easier to know what IPOJO or other tools can do for me and when it's better not to use them.

For example to build a simple GUI with plugins support using OSGI, the only thing I need to do if I understand, is :

• Create few services, one can think about them as extension points
• Create BundleActivators for each plugin
• Register couple of services and use some ServiceTrackers
• Layout and display your GUI application when all the bundles are activated
• Launch background services if their startup needed to be delayed
  

I downloaded the SIP communicator's code. It's an audio/video Internet phone and instant messenger using Apache Felix. The graphical interface is nice and the code is "clean enough", quite good IMHO. I found a little bit strange/unconventional the way they package bundles. It seems that they build bundles from some packages/classes using an Ant build script, in a single project. I believe in an IDE it would look like a project with multiple source folders and a jar target for each source folder.

In XPontus XML Editor I have about 18 plugins which could become bundles. I started cleaning up some code. One shall never hurry too much to release, patch code here and there, leave too many unused packages, because the pain comes soon enough when you need to do some refractorings... .

In XPontus, I have 1 master project and about 30 sub-projects. Well it can be difficult to manage too, but I don't have to create many ant targets/tasks to build specific jars.

Project structure overview

• xpontus_core
• etc.
• indentation_plugin(dummy maven pom project)

-> xml_indentation_plugin(sub-project, maven jar project)
-> html_indentation_plugin (sub-project, maven jar project)

The annoyance with a plugin architecture is about the deployment, but mostly the packaging. Most of the time the plugin framework or OSGI framework you'll find has a console or a main class from where you can launch the bundles/plugins. Usually in a big application, you want total control and a customized behaviour which means a custom launcher to embed the plugin framework or the OSGI framework.

Let's say I have a bundle called bundle0. I created it in Eclipse, I have few jars as dependencies, etc. How do you auto-package all that with minimal effort(zip file with the bundle0.jar, a lib directory holding the dependencies)?

In XPontus XML Editor the plugins have an "Eclipse like" folder structure
- com.mycompany.plugin
* plugin.xml
* lib(folder containing the jars)

Every time I want to deploy a plugin:

• I create a plugin folder with a unique id
• I add the plugin descriptor
• Create a lib folder with all the jars needed by the plugin
• I zip the folder and it could be ready to be deployed.

VFSJFileChooser is out

I uploaded the new release of VFSJFileChooser this evening. It will be available on all Sourceforge mirrors probably tomorrow.

Preparing the new VFSJFileChooser release

VFSJFileChooser will be out soon.

Here is the changelog :

• Sort file by names : Some patches were submitted to sort file by names.
• The "home" button will not bring you back anymore to your local home folder if you're browsing a remote directory.
• A details view is being added as a complement to the existing list view

There are still some issues when you choose the native look and feel with : UImanager.setlookandfeel

A closer look at OSGI

I was reading about OSGI and I found out that it's not as complicated as it looks like. As I am not an Eclipse fan, I tried Knopflerfish and Apache Felix. I might use OSGI in my next projects if they're big enough.

After half an hour, I was able to get a simple bundle running with Apache Felix. I wrote a simple program embedding Apache Felix and created another project which provided a bundle.

My main interest in OSGI is dependencies management handling :

• Service A is started
  
• Service B depends on Service A
• if service A is not available -> do not start service B
• if service A is available -> start the service B and register it

Java Enterprise Edition

Most of small companies don't use Java Enterprise Edition, even if few thousands guys need to access an application at the same time, even if the application needs to support transactions, to be scalable, etc. They already have deployed "medium to big" successful applications using Tomcat and J2SE, so why bother?

It's difficult to find very young people(less than 30) which have a J2EE knowledge. You don't learn J2EE in a technical school, you don't learn it at University and you probably won't learn it by working in a small company. IMHO, the general opinion about J2EE is that "It's interesting, looks complicated too... and I probably don't need it, (solo talking it's probably worth not my time and my salary learning it.)". When in a small company a guy has a good J2EE working knowledge, there is probably a big chance, that he's the only one who will create and deploy enterprise applications and hopefully transfer all his knowledge to others someday.

I looked only once at Java Enterprise Edition few years ago. Going by the book, and doing few examples, I was able to get started using notepad and standard Java tools. The experience was painful with Corba, RMI, etc. Few days ago, I had a look at JavaEE 5. It looks nice and quite simple. However it seems that most businesses are still using EJB 2.1 and not 3.0.

XPontus - Schema completion

Schema completion support has been improved... It was kind of not working in XPontus.

A schema location declaration contains most of the time one or multiple uri references(namespaces and schema locations) with some whitespaces, carriage returns, ...

Now XPontus is able to resolve each schema url locations when they end with .xsd.

Latest screenshot

Working on XPontus 1.0.0.2

XPontus 1.0.0.2 is coming up. I've fixed few issues this week-end.

General interface problems
Sometimes the file chooser dialog can take a while to load(I only noticed that problem under Windows). That issue has been adressed lots of time to Sun. I don't think it's gonna be fixed definitely any time soon. It seems that the file chooser freezes when you have some zip files on your desktop and it can take up to 10 seconds to show on a Quad Core... Can you tell a user who reports the bug "Damn, you've got lots of zip files on your desktop, clean it up!". That would be funny...

I am not sure that I'll replace the file chooser by VFSJFileChooser. If I don't do it well, it will bloat the program(5 to 6 additional libraries). Letting the user chooser between the default file chooser(better OS integration) and VFSJFileChooser(remote files able) would involve rewriting partially many classes.


Windows vista GUI issues
The tab names are now visible under Windows Vista. The gray rectangle is still visible in the menubar. I could create a special layout for the menubar or make it a java.awt.GridLayout(ugly but no gray rectangle) to solve the issue. The menubar problem is a swing related issue, not XPontus' fault.


The code completion is more usable

Here is the new use case :

Let's say you trigger an element completion by typing "<" in a xsl stylesheet document

• Suppose you were getting typing xsl:apply-te.
• That would select xsl:apply-templates in the list
• Then you change your mind and select xsl:apply-import and press enter
• The text inserted in the document is xsl:apply-te and it will now be converted to xsl:apply-import instead of xsl:apply-teport

XPath improvements

• The xpath plugin couldn't display a boolean value or a number value. For example count(//node) would throw an exception and now it returns the number of node found as text.
• XPath 2.0 support has been added

Architecture

I didn't fix the architecture problems. I will address that matter when the version 1.0.0 of XPontus will be considered as stable. Rewrite things here and there, without breaking too much code.

What's next

I will think about the plugins manager next week and give myself sometimes to do it well. I don't it to be complicated, I just want it to work as well as possible for the next release.

Random talk[SPECIAL]

Nowadays, I tend to think a lot about that Albert Einstein quote
You have to learn the rules of the game. And then you have to play better than anyone else.

It seems to very true in most circumstances...(work, girls, normal life stuff...) Programmer with real skills or programmer which seems to have great skills...?

It's all about that they think you are and what they think you know... That's what a guy told me during my first year at university. The guy didn't know anything but he truely believed that he deserved a great income....