This year’s JAX.de conference hosted many great Java thought leaders, including one of my personal favorites Gilad Bracha. If anyone has the authority to critique Java and the Java platform then surely it is Gilad who spent years working for Sun on the language and platform tools. If you haven’t followed him recently, I recommend reading his papers on Pluggable Type Systems and Objects as Software Services. Lucky for me, my “Code Generation on the JVM” talk was sandwiched between his “Java: A Post Mortem” and “Newspeak: A Principled, Dynamic Language”. It was surreal to see my name next to someone I’ve revered for many years, and I felt a bit like the rookie professional athlete who has to play his first game against someone they grew up watching on TV.

As expected, his talks were good mix of humor, strong opinion, and thoughtful analysis. Here are my favorite bits:

If you can’t abstract over it then it doesn’t belong there.
An original sin of Java was constructors. They are static methods that commit to returning a concrete implementation. Remember the design mandate “program to interfaces”? Constuctors subvert this and gave rise to a cottage industry of Dependency Injection frameworks to get around the issue (as long as you consider VMWare a cottage industry!). You wouldn’t need DI if your language supported proper inversion of control in the first place. The next generation of languages hopefully won’t have this limitation.

Class initialization is absurd. There should be none.
Static state is bad, bad, bad and read Gilad’s great blog post if you aren’t persuaded. Without static state there is no need for class initialization. We’ve all heard that the JVM start up times are slow, but that is a bit of a myth. The problem is that through class initialization we’re asking the JVM to do millions of operations that could be avoided without static state. A Lambourgini isn’t slow, but it sure seems that way if you try to drive it to the Moon. Likewise the JVM.

Why should a high level language need a memory model in the first place?
The original Java memory model was incoherent, the revised memory model is understood by only five people in the world, and the actors for concurrency idea existed since the Gulati paper of 1970. Bracha’s point wasn’t that we need a better Java memory model, it is that we should have made a language that did not need to expose a memory model to the developers. As with many of the Java original sins, Threads were the wrong level of abstraction and something better like Actors should have been chosen.

Java is going to stay but it is going to stay where you don’t want to look
Everyone wants to predict the demise of Java, don’t they? But few people offer a real, long-term alternative. There is enough risk with any of the other JVM languages to persude Enterprises that sticking with Java is the best choice. The evening’s speaker panel agreed (mostly) that the real successor to Java didn’t exist today. So where will the next big lanugage come from? Who can monetize a programming language? Microsoft has somehow done it with .NET, but show me the Oracle business plan that details how to get rich from writing a programming language. Or any other company for that matter. Here is my prediction: all this language innovation results in the best ideas making it into libraries and frameworks available for the Java language, and Java remains number one on our beloved TIOBE index, clunky syntax and all.

Webapps make you reboot. It is called “session expired”
Newspeak was funded to solve the problem of always on, always updated software. Quick question: what version of Google do you use? I’ve never in my life seen a version number at Google.com and that is a deployment success story. All software should work this way. I’m unclear how Newspeak is going to solve the session state problem but I’m also certain that I do <i>not</i> fully grasp the Newspeak vision.

If you want a static language you should look at Egyptian heiroglyphics because it hasn’t changed in a long time
And another quote from Brian Hurt: “Demand that you not have to learn something new to learn new languages, and then wonder why languages don’t improve much”. Newspeak is a bold change, and people are going to be very resistent. Incremental changes like Groovy are much easier to sell than big sweeping language changes. And an always changing language can hardly be adopted by the masses. I left the session wondering if Newspeak is an experiment meant to fuel language innovation or a real alternative as a mainstream programming language.

Complicated is not a sign that you’re clever. It is a sign that you failed.
Simple solutions can be achieved with a low number of non-overlapping concepts. If you need something more complicated then build it by composing the simpler pieces together. Special cases like primitive types are the road to ruin. Or the road to massive popularity and success as is the case with Java. In my humble opinion: success is an accident, much better to aim for happiness.

Language development has moved away from professional language writer and into the hands of hobbiest developers
As a hobbiest developer working on the Groovy language, I have averaged a mere 2-3 hours a week of work over the last 12 months. The good news: I’m clearing my schedule after the GR8 Conference to work on Groovy’s GEP-4. The bad news, I am and will remain a non-professional hobbiest developer hacking on a language in my spare time. Life couldn’t be better.

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!

A few weeks ago on a Friday evening, Canoo opened its doors to the public and hosted a new programming user group called Hackergarten. The goal of the group is different from other user groups: instead of learning from listening to a presentation they want to learn by writing code. In their own words:

Our goal is to create something that others can use; whether it be working software, improved documentation, or better educational materials. Our intent is to end each meeting with a patch or similar contribution submitted to an open and public project.

We’re excited to say that their contribution to the Gradle build system was accepted last week! The next release of Gradle 0.9 contains an “Announce” plugin that can notify you and your customers of build events using Twitter, Snarl, or the Ubuntu notification system. You can notify yourself of local build failures or notify your customers of successful formal build releases. It was a long Friday night, but the group of over 10 developers are all happy to see their work accepted. As the group sponsor, Canoo is happy to have kept them caffeinated and well fed.

The next Hackergarten is this Friday, 30 April 2010. The group plans to write some Griffon plugins, a desktop application framework written in Java and Groovy. The Griffon Project Lead (and Canoo employee)Andres Almiray will be present to help guide the group. If you are anywhere near the Basel area this Friday, then please stop by Canoo and come join the fun. Don’t worry if you’ve never seen Groovy or Griffon before, the point is to learn new skills and meet new people.

You can find out more information on the Hackergarten mailing list or follow @Hackergarten to stay up to date.

Come join the fun. Here’s what people are saying about the last event:

.

The first Hackergarten was a great event, not only because there was free pizza, but primarily because it was a true team event with everyone actively contributing. Submitting a patch for a new Gradle plugin at the end of the night was our goal which we reached successfully. I look forward to learning more about Griffon at the next Hackergarten.

Etienne Stuber

.

I learned how easy and powerful Gradle is. The fact: with a little group and in a little time, we wrote a worth-making contribution to an open source project. Did I have fun? Definitely, it was like meeting with friends but for a beer but enjoying coding at the same time. In the future I am interested in writing Grails or Griffon plugins.

Alberto Mijares

.

At Hackergarten I learned about the Pomodoro technique and how to use groovy closures to do exception handling in a smart way. And yes, I had a lot of fun! For future events I am interested in anything with new technologies but especially with testing different approaches on how to program in teams.

Christoph Sperle

Canoo Software Engineer Hamlet D’Arcy was interviewed for the GR8 conference about his professional background and his conference contribution as well as Groovy and the Canoo Hackergarten.

Here’s the link to the interview! And here are some pictures of Hamlet during Canoo Day 2010:

Canoo Engineering is proud to present the next generation of UltraLightClient! Download the Beta here!

The RIA-Framework (Rich Internet Application) has been completely overhauled and enhanced with a series of innovative and useful functions. These will enable more efficient and convenient deployment in future, as well as adding some attractive features to the design of the user interface.

UltraLightClient will bear the name ULC Core from now on, and forms the basis of the new Canoo RIA Suite, which will officially be released at the beginning of May. The suite is designed in a modular fashion, allowing you to compose functionality according to your own needs. And you only pay for those modules which you actually require.

.

The Highlights

• The new Chart Functionality enables you to present even complex facts and figures clearly and simply.
• Using the integrated Animations Framework you can develop dynamic and attractive content in future.
• Further sophisticated graphic features allow even more attractive designs: transparency, rounded angles etc.
• Easy integration to Google App Engine.

THE NEW MODULES AT A GLANCE

ULC Table Plus: this package enables you to implement even the most complex tabular requirements in a rapid and straightforward manner.

ULC Web Integration: simply integrate any browsers such as Safari, Firefox or Internet Explorer into your application developed under ULC. Web services and plug-ins like Google Maps or Flash Player can thus be launched directly in the application.

ULC Office Integration: this ULC Core module supports the future import and export of Excel and Word files out-of-the-box. The contents can then be stored as PDF files and later printed.

ULC Enterprise Portal Integration: using this optional extra, existing portlet applications can be easily and efficiently augmented with ULC applications.

ULC Visual Editor: with the optimized visual editor you can generate your ULC applications by drag & drop even more easily and, as usual, without any manual programming effort whatsoever.

ULC Load: put your ULC applications though extensive load and performance tests using ULC Load. Thus you can be confident that your applications can bear up to the most rigorous demands in an operational environment.

Download the Beta here!