Juggling with DLLs, WebStart and Maven

Recently we were asked to implement a Drag & Drop mechanism between Microsoft Outlook and a Java based internet application. This necessitated our Java server having to communicate with COM objects on the client side. How do you do that?

The good thing is that our application was built using UltraLightClient, so we had java on both the server and on the client side. And after some thinking, the steps seemed pretty clear, even if a tiny bit of juggling would be required. However, the juggle almost turned into a struggle when we encountered some unexpected pitfalls.

In this blog I will give a quick sketch of our solution and point out some of the traps to be aware of.

Step 1: Talking COM using JACOB

In order to communicate with Microsoft programs from Java you need a Java COM Bridge.
We were using JACOB and it was surprisingly easy to extract Outlook mails into Java objects.

The idea:
The following method extracts the selected outlook mails to a directory and returns the list of created files:

The trap:
Using the email subject as a file name is practical, but it can contain many weird characters which may not be supported when the files are created. We found out that JACOB has problems creating files containing even characters like “:” and “,”. Furthermore, no exception is thrown, although the file fails to be created completely.

The solution:
Replace potentially dangerous characters with something neutral using regular expressions:

[[code]]czoxOTU6XCINCnB1YmxpYyBTdHJpbmcgZ2V0VmFsaWRGaWxlTmFtZShTdHJpbmcgcmF3U3RyaW5nKSB7DQogICAgUGF0dGVybiBpbnZ7WyYqJl19YWxpZENoYXJhY3RlcnMgPSBQYXR0ZXJuLmNvbXBpbGUoXCJbXkEtWmEtejAtOV8ge30rIV1cIik7DQogICAgcmV0dXJuIGludmFsaWRDe1smKiZdfWhhcmFjdGVycy5tYXRjaGVyKHJhd1N0cmluZykucmVwbGFjZUFsbChcIiBcIik7DQp9DQpcIjt7WyYqJl19[[/code]]

To be on the safe side we were using a whitelist approach. We treat everything as invalid except for characters which are listed after the “^” character.

Step 2: Shipping a DLL with Webstart

JACOB can talk to Outlook because it comes with a DLL which has to be present in the classpath. This means we either have to ensure that all our users have this library installed (yikes!) or we ship it together with the application client using Java Webstart.

The idea:
We include the DLL in the jar file and sign it with a valid certificate. Then it can be referenced from the JNLP file that launches your web application:

[[code]]czoxNjc6XCINClsuLi5dDQogICAgPCEtLSBBdHRlbnRpb246IFRoaXMgZG9lcyBub3Qgd29yayEhISAtLT4NCiAgICA8cmVzb3VyY2V7WyYqJl19cyBvcz1cIldpbmRvd3NcIj4NCiAgICAgICAgPG5hdGl2ZWxpYiBocmVmPVwibXktZGxsLmphclwiIGRvd25sb2FkPVwibGF6eVwiLz4NCiAgIHtbJiomXX0gPC9yZXNvdXJjZXM+DQpbLi4uXQ0KXCI7e1smKiZdfQ==[[/code]]

The trap:
We were using the optional parameter download=”lazy” to ensure that the library is only downloaded when it is really needed. The result was that it never got loaded at all(!) because we did not specify to which “part” the library belongs. This is another optional parameter which turns mandatory in combination with download=”lazy”.
Unfortunately this little detail is not too well documented. The only hint found was this one (in german). It took me quite some time to find this critical information.

The solution:
Since the jar containing our DLL is really small we chose to use download=”eager” (which is the default anyway) instead of defining “parts” in our JNLP.

[[code]]czoxNTE6XCINClsuLi5dDQogICAgPCEtLSBUaGlzIG9uZSBpcyBlYXNpZXIgYW5kIGl0IHdvcmtzISAtLT4NCiAgICA8cmVzb3VyY2V7WyYqJl19cyBvcz1cIldpbmRvd3NcIj4NCiAgICAgICAgPG5hdGl2ZWxpYiBocmVmPVwibXktZGxsLmphclwiLz4NCiAgICA8L3Jlc291cmNlcz4NClt7WyYqJl19Li4uXQ0KXCI7e1smKiZdfQ==[[/code]]

Step 3: Using native lib references with the webstart-maven-plugin

We already were using Maven as a build system and our client distribution is generated with the webstart-maven-plugin as follows:
- We use a separate module with packaging type “pom” for the generation of the webstart client. Of course, this module is part of the multi module build for our application.
- We provide a template for the JNLP file containing a parameter “$dependencies” which will be replaced by a list of the dependencies of the current module
- At build time the dependencies will be signed and put into a zip file together with the JNLP file.
- The zip file can be extracted to a java webstart server or, in our case, into a war file that will be deployed on a server.

The idea:
Since JACOB is available via Maven Central integration seemed pretty easy. We only have to generate the correct reference to the native library.

The trap:
Unfortunately the current version of the webstart-maven-plugin (1.0-alpha-2) does not support native libs (open issue). So we will need a workaround that wraps the jacob.dll into a jar file and generates the nativelib reference in our JNLP.

The solution:
Perform the following steps:
- Change the packaging type for the module from “pom” to “jar”.
- Configure the pom.xml to copy jacob.dll from the maven repository into the build directory of the module using the maven-dependency-plugin
- Add the nativelib reference to the velocity template using the build artifact of the current module as a reference.

[[code]]czoyNjA6XCINClsuLi5dDQogICAgPHJlc291cmNlcz4NCiAgICAgICAgPGoyc2UgdmVyc2lvbj1cIjEuNStcIiBpbml0aWFsLWhlYXAtc3tbJiomXX1pemU9XCIyNTZNXCIgbWF4LWhlYXAtc2l6ZT1cIjUxMk1cIi8+DQogICAgICAgICRkZXBlbmRlbmNpZXMNCiAgICA8L3Jlc291cmNlcz4NCntbJiomXX0gICAgPHJlc291cmNlcyBvcz1cIldpbmRvd3NcIj4NCiAgICAgICAgPG5hdGl2ZWxpYiBocmVmPVwiJHtwcm9qZWN0LmJ1aWxkLmZpbmFse1smKiZdfU5hbWV9LmphclwiLz4NCiAgICA8L3Jlc291cmNlcz4NClsuLi5dDQpcIjt7WyYqJl19[[/code]]

Summary:

After successfully having avoided the traps (okay: by stepping into them and finding a way out again) we got an application with a pretty cool feature integrated seamlessly in our build process. Nice!

While preparing the second edition of “Groovy in Action”, Canoo Fellow Dierk König once again worked systematically through the language and came across a number of new features that slipped by his attention when they were added. His talk (from Groovy & Grails eXchange 2009, London) presents those features in a workshop-like manner with demos, live coding and lots of interaction with the audience. Watch the video on Skills Matter!

.

 

Dressed in boiler suites, Joshua Bloch (Google Inc.) and Neal Gafter (Microsoft) put on quite a show in which they present a series of traps to be avoided in the Java language…

 

Joshua Bloch (Google Inc.) and Neal Gafter (Microsoft)

 

•    First problem: What does Boolean (Strings) do? Answer: Depends on the value of a particular system property – which is obviously completely horrible.
•    Second problem: Overriding addAll/add of a HashSet is dangerous. Something we should all know because (for example) addAll may be implemented in terms of add. Answer is to create a so-called forwarding set, in which the inhertance characteristics of the implementation are defined by us. A class whose self-use patterns are not explicitly defined and documented should not be inherited from. Google collections provides a suite of forwarding classes.
•    Third problem: Unpredictable behaviour caused by invoking a public (overridable) method in a constructor. Apparently Brian Goetz has made this mistake.
•    Fourth problem: Searching which depends on a comparator is broken. In the example the comparator is broken because autoboxed integers cannot be tested for equality with. In addition, Comparator must implement total ordering, which in this example is broken because of the auto-boxing.
•    Fifth problem: Initialization error caused by invoking enum constructor when a static variable has not been initialized.
•    Sixth problem: Memory leak caused by assigning a large number of values to non-static thread locals. Thread local contains a weak hashmap.  This is a complicated one to follow. One obvious moral: Don’t use non-static inner classes.
•    Seventh problem: Problem caused when two versions of a class contain different constant definitions. Contants are inlined in Java. However, null is not considered a constant in this sense.

Overall: As we’d expect, nasty little problems which are likely to occur at some point in the developer’s life. Bloch suggests using “FindBugs”, which will apparently detect all of the above problems.

First note that the speakers Ben Galbraith and Don Almaer are co-founders of ajaxian.com, which is clearly an AJAX-shop. They claim that Web technologies and Java went stagnent in the UI space. Ajax and JavaFX have the characteristics of a renaissance. They structure the talk in the form of a “discussion” or a series of arguments, where one supposedly pits the advantages of said technology against the other.

 

•    Argument #1: Java performs way faster than JavaScript; on the other hand JavaScript is getting faster all the time (V8 team at Google); plus apps like Google wave demonstrate that performance is good enough.
•    Argument #2: Responsiveness improved by worker-threads in a Java GUI. Yet using “web workers” we can overcome the limitation of JavaScript to a single thread. Demo of Pictastic proves the point. Having said that, web workers are still 10 times slower than Java; plus the API is extremely limited. In “web worker”, worker threads don’t share state, which is way safer than the totally flexible Java approach.
•    Argument #3: GC way more advanced in Java. On the other hand, incremental GC in Mozilla is improving all the time. A lousy fact of the JVN is having to determine how much memory the app requires (or how much is available) wherever the app is deployed.
•    Argument #4: Graphical capabilities of Java surpass what web apps can do. But performance of Bubblemark benchmark app shows that Google chrome achieves 100 frames per second. By comparison JavaFX achieves 24 FPS. With vector graphics Chrome is back down to 30 FPS. What the speakers don’t consider is that JavaFX is a very new and to-date under-optimised technology.
•    Argument #5: An Ajax 3D demo “metatunnel” is pretty impressive. Most browsers, apparently, are offering 3D extensions. It’s still at the experimental stage, however. JavaFX, on the other hand, has nothing to show in 3D.
•    Argument #6: Java is weak on fonts. The speakers claim that can’t use native fonts in Java (is this true? I seem to remember supplying Java with some additional fonts some years back.) Control over fonts in the Ajax world is even more limited, however.
•    Argument #7: JavaFX provides “amazing” video support. Counter argument: Flash plugin us ubiquitous and surpasses JavaFX in terms of maturity. Open Web Video offers sophisticated video functions.
•    Argument #8: Binding in JavaFX is compact and elegant. Web toolkits are very clumsy by comparison. The speakers quickly mention Mixins, Animation and Effects. All of this is way easier in JavaFX…
•    Argument #9: Legitimate critisisms are raised about JavaFX syntax. Speakers suggest that JavaScript is actually easier and closer to Java than JavaFX Script. And, of course, JavaFX totally lacks widgets like table/tree. Web toolkits even provide some very cool layout management and tools for constructing GUIs.
•    Argument #10: Tooling superior in the Java world.
•    Argument #11: Deployment. Web wins here, obviously, except for significant browser incompatibilities. Applets, Mac etc. are lousy too, however.

 

Conclusion: A pretty damning result for JavaFX, which is for the most part justified (at least today.) What the speakers fail to do, however, is talk more fairly about the significant problems faced by AJAX developers on a daily basis.

In the previous chapter we discussed how a simple presentation model framework can substantially reduce the implementation effort for complex user interfaces while at the same time delivering a clean and maintainable software design. However, the presentation model framework is still not sufficient for an efficient implementation of the presentation layer. What else do we need? We can identify the following areas:

• Attaching user interface components to model properties can be quite cumbersome . Some kind of binding infrastructure takes care of this.
• Configuring user interface components through a low-level API takes too many lines of code and does not guarantee consistency. A component factory helps to do this with less code and more consistency.
• Validation can be a tricky beast. Adding validation in the presentation layer is required for better feedback but leads to duplication of business layer validation logic.
• The design of ergonomic, consistent and visually attractive form-based user interfaces is a challenging task. Furthermore, coding such user interfaces can take way too long without a decent infrastructure.

Binding
Generally speaking, the term “binding” denotes how to keep to properties in sync. In the case of user interfaces one property is hosted by a view component and the other one is exposed by the presentation respectively domain model. As we have seen in our examples this is a two-way sychronization. Without a binding infrastructure you have at least to register an event listener at the user interface component which gets notified about value changes and sets the model property accordingly. Additionally, the user interface component needs to register as an observer to the model property and update the visualization correspondingly. A binding infrastructure can replace multiple lines of code to accomplish the above with a single line of code which is even more expressive and comprehensible. Model properties can be visualized in quite different ways. For example, an integer value could be visualized as a number literal in a text field or as a selection a radio box, check box group, or a combo box. The binding infrastructure should cope with all these variations.
If user input is not to be immediately commited to the model property the binding infrastructure can buffer these value changes. Finally, the binding infrastructure has to care for value conversions back and forth, e.g. the input field component only accepts strings but the model property is a number.
For Swing there are several binding infrastructures available: probably the most popular one is JGoodies Binding. JSR 295 is another approach, a reference implementation of which can be found here.

Component Factory
The components of common user interface toolkits such as the Swing library expose a large number of properties. Usually, a developer has to configure a component instance to her needs by setting the necessary properties one by one. This not only leads to many lines of code but consistency is also hard to achieve even within the same view. For example, the input field for a customer id should look and behave the same within and across several applications. A component factory both encapsulates the creation and configuration of generic and domain specific user interface components. Even for small projects a component factory is highly recommended.

Validation
Rich Internet Applications do not demand more validation but more frequent validation. With this type of application a user would like to get immediate feedback as he uses the application. The implementation of such fine granular feedback is much more demanding than with a classical web application which gets validated once when submitting the entire form. In order to give immediate feedback, the presentation layer has to validate immediately on user input. Nevertheless, the business layer cannot trust the presentation layer upon validation and therefore it again has to validate all data in its services. Unfortunately, this might lead to code duplication. Clever modularization can factor out the validation code which can the be shared between the presentation and business layer. However, sharing is only possible if you have the same run-time environment for the presentation and business layer. In a scenario where your business logic is implemented in Java and your presentation layer is based on JavaScript you are out of luck and forced to reimplement parts of your validation in JavaScript.
Basically, there are two types of validation, syntactical and semantical. Syntactical validation should be hosted in the presentation layer in any case, even at the cost of code duplication. You can simply not afford to call a validation service with every user keystroke. Syntactical validation can usually be expressed descriptively and hence it might be sufficient that the business layer just returns a formal description of the validation which is interpreted in the presentation layer. This helps to avoid code duplication. With semantical validation it’s a different story. It is recommended to provide this type of validation as a business service. Semantic validation probably means to access further services or a database. Duplicating this code in the presentation layer is not only expensive but also incurs a performance penality when triggering serveral client-server round-trips. An example for a validation framework for Swing is JGoodies Validation.

Form Layout
Designing ergonomic and visually attractive form-based user interfaces is far from trivial. If you have ever tried to achieve this with the basic Swing components and the gridbag layout manager you know what I am talking about. Granted, there are better layout managers, e.g. MiG, JGoodies Forms, the GroupLayout Manager, or the new ULC form component. If you are looking for a comparison of different layout managers, the layout manager showdown has a nice overview. Using these layout managers it is definitely easier to design forms but if you have to implement dozens of densily crowded forms it is still a drag. The problems are efficiency and consistency. Most likely your applications features a few basic form patterns, e.g. a master detail view, search view, etc. Even with an advanced layout manager there is too much design variability for a developer which hampers efficiency and certainly does not lead to a consistent user interface., especially when developing in a team. Therefore, it is recommended to build project (or company) -specific form components which kind of hard-code the layout. This easily pays off with increased development efficiency and user interface consistency. In a recent project we identified the common user interface patterns upfront (we call it meta design) and implemented the necessary form components. As a result, the developers are way more efficient and the user interface of this application (featuring hundreds of form views) is surprisingly consistent.

The presentation model is indispensible for realizing the complex user interfaces of Rich Internet Applications. It takes very little infrastructure (implemented as a framework), even when extending the presentation model approach with application components for a hierarchical decomposition of complex user interfaces. If you add binding, a component factory, validation and meta design to that your Rich Internet applications will be ahead of those from your competitors with respect to time to market and visual attractiveness.

Part 1: MVC and the Brave New World of RIA
Part 2: The World Needs More Models
Part 3: A Simple View on Complex Stuff
Part 4: Hierarchies
Part 5: Presentation Model Framework
Part 6: What’s Needed Besides the Presentation Model