Multiplatform JavaFX for real – Hessian

I’ve already blogged about running JavaFX on Android and discovered that my first generation Nexus 7 is quite able to run such an application, including an animated gauge. So it is time to step up the ante and go for a fully working application.

As the (unwilling) candidate I chose my own time registration application. It is a 10+ year old application that I helped write and was sold commercially. As a rent-a-nerd I’m now using it myself to keep track of my hours, for billing at the end of the month. It’s main component is an applet that acts as the primary user interface, and it talks with the backend using Hessian. Remember, this was all before SOAP and REST became popular and Javascript on browsers was mostly disabled.


Yes, applets / Swing applications can look pretty decent as well. And I think it hasn’t lost much of its looks in these 10 years, it even has some animation going on. The backend also had a web application for administrative functions, but I now just SQL the stuff straight into the database, I don’t need all the fancy logic that was in the web application.

Recent developments in browsers means that I can only start the applet in IE at the moment, and Oracle will discontinue the plugin completely. So that means I either convert the applet into webstart application, or write a JavaFX version, that just happens to also run on Android and other mobile hardware.

There isn’t much challenge in the first option, is there? So the choice was easy.

Following my own rule to first get all of the technical obstacles out of the way, before starting to make things look pretty or work on trivial stuff, I created a JavaFX application that has a date picker (JFXtras’ CalendarPicker), a table, a tree and some buttons and made them work.


Yeah, that is a pretty boring GUI, but it took quite some steps to get there, because exchanging data with the backend using Hessian on Android was not trivial. First I (naturally) tried the Hessian library that is used both by the Server and the Applet. It works perfectly on a windows desktop, but on Android it fails:

java.lang.NoClassDefFoundError: com.caucho.hessian.client.HessianProxyFactory

Strangely enough the Hessian jar is included and processed by dex, so there is no obvious reason why the class can’t be found. Luckily José Pereda showed me that more people already ran into this problem.

Following his advice, the next attempt was using Hessdroid. But it is only available as source and is compiled against Android 1.6. Some frustrating tweaking and twiddling later it was compiling against Android 5.1, but unfortunately not working either: expected hessian reply at 0x48 (H)

In the discussions another Hessian port by Flamingo was mentioned, but that project has completely disappeared from the interwebs. Googling revealed that it was used in a project called “JFXperience“, and that was still around. But more importantly: it had the supporting jars in its source tree! So I downloaded the sources, and found the ‘flamingo-android-hessian-client’ jar in there… But no luck again:

java.lang.NoSuchMethodError: No virtual method putDouble(Ljava/lang/Object;JD)V in class Lsun/misc/Unsafe; or its super classes (declaration of ‘sun.misc.Unsafe’ appears in /system/framework/core-libart.jar)

Sun.misc.Unsafe? Oh oh, that probably won’t be easily fixable.

I was about to give up and settled on the idea that I had to build a REST service, when I noticed a blogpost by Monkeyboy mentioning a stripped down version of Hessian. Hmmmm. Maybe stripping it down… You never know until you try. So I downloaded the sources, the compilation went without a hitch and, well, you’ve seen the results! Thank you, Monkeyboy!

So now all the technical issues are out of the way, I can move forward with finishing up and polishing the JavaFX application. But I figured I should document my travels in case someone else runs into the same problem. And if that source link goes down, I’ve got a copy tucked away in my Nexus.

10 year old software and I can still build on it. Ain’t Java great?

Posted in Android, Java, javafx, jfxtras, UI | Leave a comment

I am worried

On the morning of the JFall I find myself pondering about Java, chatting to the people in the community does that. And I find myself wording to my fellow Javagians the feelings I have been getting lately. Pure from a technical standpoint Oracle’s stewarding of Java has been good. They have picked up the language and platform, pushed it into a new gear; lambda’s were added, JavaFX is maturing nicely, and Jigsaw is on track. One cannot possibly complain about what has been happening to the product Java.

So why am I worried? Well, Java is not alone out there. Things like Ruby and DotNet are slowly but continously nibbling away at it. And the most important thing keeping Java the #1 choice is its user base. And that is where Oracle is missing the point over and over again. Most recently the dismantlement of the evangelist team, but we all remember the OpenOffice fiasco or Hudson. Oracle is not getting that in order to grow a tree, you need to nurture its roots. And Java’s roots is its community. Java sky rocketed the concept of open source, and a lot of all the good things in software development nowadays grew from there; dependency management, web and application servers… Too much to name. (In comparison usually the corporate invented concepts were very flaky, like EJB2.)

But there are more subtle issues as well. By now we have all but forgotten about the Oracle – Google lawsuit over Android, but it is still happening. Android represents a very large part of where Java is used nowadays, and it is stuck on Java 7. Ah well, you say, just roll in retrolambda and you’re good. Actually that got me started on this though train a few weeks back, when I retrolambdaed JFXtras. As great and impressive as retrolambda is, it should not be necessary. Android should be on Java 8. And not for long Java 9 will come around, and Android will move even further away. Ah well, you say, Java 9 mostly is about cutting it up. Well, yes, but in order to do that A LOT of packages will be renamed and moved into the public API of Java. When libraries will start using those public API, there is no back porting.

And Oracle won’t ease down, it wants to excises full control. The product Java will be assimilated and honed and tuned and improved and polished until it is glowing Oracle red. There is no room for community or cooperation.

Google (or IBM) should have bought Java.

Posted in Java | Leave a comment

JFXtras: lessons learned developing in JavaFX

JFXtras is my pet open source project. I like visual things, and HTML and CSS are way to frustrating, so I’m running with JavaFX. Since 2012 I’ve been submitting controls to it, simple ones at first; the ListSpinner, then the CalendarPicker (date picker), and eventually Agenda (Google Calendar) and gauges. Doing this has resulted in many satisfying moments when a control worked, but the road to that point was littered with many chunks of frustration and sometimes even scrapping whole controls and restarting on them (Agenda has three iterations).

Writing these controls in JavaFX 2 and later has teached a lot of lessons; things that work, things that didn’t work, or worked better than others, and in the end resulted in a few best practices. It’s not like I have all the wisdom on JavaFX or anything, but being on this for so long, well, at least some commonalities were found. So during Christmas holiday 2014 some of this knowledge was wrapped up in a small 1 – 1.5 hour presentation / talk, touching on some of JavaFX’s strong points, slip ups and other topics like code structure and testing JavaFX applications. It’s titled: “Lessons learned developing in JavaFX”, or “Let us make your mistakes for you”.

I gave the presentation three times and after incorporating the feedback, decided to submit it to a number of conferences. To my amazement the talk was not selected by any of them, based on that JavaFX is not interesting enough for the intended audience.

Ok. That was unexpected.

So following the three-strike-out rule, I’ve decided to not submit it to conferences anymore, and put my energy elsewhere (probably back in developing more JFXtras controls or testing JavaFX on mobile). But letting that presentation collect dust is not sitting right. So, if anyone feels like it would be of interest, if it fits in my schedule and I don’t have to lose money over it… I’m glad to run it again!

Below are the first two slides.

jfxtrasSlide1 jfxtrasSlide2

The whole presentation in PDF can be found here
JFXtras presentation

Posted in Java, javafx, jfxtras, UI | 9 Comments

JFXMobile – first attempt follow up

The previous post contains a detailed log of my adventure in getting a JavaFX application running on Android. It highlights the initial hurdles, the amazement how easy it was once those hurdles were taken, and comes with the conclusion that I need a new hardware.


Turns out I do not need a new hardware.


Besides the date picker my application will also need an editable table. So continuing the HelloWorld test, I added one. Tables are never simple, but after you have done JTable, TableView is a breeze. After compilation it started on the Nexus without a hick and was very responsive!

Ok, but a TableView is not a simple component! If Jonathan is able to get that thing working responsive, why isn’t JFXtras’ CalendarPicker responsive? I mean, I admire and respect the magic mr. Kiwi does with the controls in JavaFX, and do not pretend to know half as much about that as he does… But a two second sluggish response?! Boundaries have to be drawn, limits need to be set! ;-)


So I revisited the source code of the skin of calendar picker, and did some analysis. It was the second component I wrote for JavaFX and has undergone MANY refactorings. Turns out it could use a bit more. Some events were listened to, but did not contribute anything. Some code could be a bit less, ah, British (as they call it).

And after a good 30 minutes of tuning, things still ran on the desktop as they should, but on the Nexus it was a major difference! Instant responses to a click! Wow!

A desktop is very forgiving if code is not optimal, and on Android it does not have to be perfect, but a bit of tuning really pays off!

I do not need a new hardware after all…

Posted in Java, javafx, jfxtras, UI | 2 Comments

JFXMobile – first attempt

Who would not like to be able to write a single code base for desktop and mobile? I know I want to, and the applet I’m using for time registration is getting into a pinch with all the browsers dropping support for applets, so why not give JavaFX a try? And see if things go as smoothly as Gluon’s tweets make it sound?

So, first things first and setup a nice virtual machine for this project with Java and Eclipse, hookup the old 1st gen Nexus 7, then download the HelloWorld demo project from Gluon. Finally a “gradlew androidInstall” should do the trick…

But no such luck!

Execution failed for task ':dex'.
> org.gradle.api.GradleException (no error message)

Dex fails and without an error message. Great! But luckily --debug shines a light on the problem: dex is started with a default of Xmx=2g, and I’m still in the habit of installing 32 bit Java, even if I run a 64 bit operating system. And 2g for a single process is a problem then.

But what is the best solution? Either 64 bit Java needs to be installed, and I often run into issues with that, or dex needs to be convinced to run with a lower Xmx. Some researching into Gluon’s JFXMobile plugin reveals that the android block has a subblock called dexOptions, where the javaMaxHeapSize can be defined; and 1024m works just fine.


And look at that: one HelloWorld JavaFX application running on my Nexus 7 Android tablet! Startup time ain’t bad at all either.

Next step: including JFXtras. The application I intend to write needs a date picker and being the guy behind JFXtras, well, I of course want to use my own library. The dependency is added quickly to the build.gradle file, the HelloWorld application quickly changed to add a CalendarPicker next to the Label, and redeploy! InvokeDynamic not supported

Que??? Oh… Right… Android uses Java 7, and JFXtras 8.0 uses Java 8, including Lambda’s.
I forgot.

It would be an option to use JFXtras 2.x, which is Java 7 based, but it is so old, I really want to use the 8.0 branch.

Luckily there is a tool called RetroLambda, which apparently allows backporting of lambda’s to Java 7. It’s an easy include in the build.gradle script, so let’s give it a try. 

Compile is still ok, good, good, and… InvokeDynamic not supported

Eh??? Ah… RetroLambda’s only processes the active project, being the HelloWorld application, not dependencies like JFXtras. So JFXtras needs to be RetroLambda-ed as well. Hm. Thread carefully there, I’m not the only one using it. So let’s just install that 8.0-R5-SNAPSHOT in the local Maven repository only.

JFXtras compiling is ok… Let’s see if JFXtras samples runs under Windows…

default method found in version 50.0 classfile

Ah. Yeah. It would have been too good to be true. RetroLambda is actually generating Java 6 classfiles, but those can’t handle default methods in interfaces used a.o. by JFXtras’ Agenda.

But again RetroLambda might offer a solution: it has a rudimentary implementation for default methods, activated by:

retrolambda {

Compile is ok… Running samples… Hey! That actually seems to work! Samples are coming up. Interesting! 

Alright! Let’s try and build the HelloWorld on Android again.


I’ll be damned! It works! Those month and year ListSpinners need to have their arrows moved to opposing sides (with the -fxx-arrow-position CSS property), but for the rest it looks quite ok.

Let’s click a bit… Oh… That is sluggish. The time between the touching of the screen and the calendar picker actually responding is almost 2 seconds. I know my aging Nexus 7 isn’t the fastest, but… No… Actually that seems accurate for other apps as well. I need a new hardware.

That was not too hard at all. I probably stumbled into everything that reasonably can go wrong, but I do that all the time, being a bug magnet and all. The performance is a bit of a concern, let’s see what a newer tablet does.

What really worries me is the RetroLamda. Don’t get me wrong, it’s a great tool, but having to postprocess Java 8 files is not very promising for the future… What will happen when Java 9 with JigSaw comes out in 2016? Oracle and Google really need to get their heads out of each other’s b*tts and stop blocking progress.

For Oracle having the penetration on mobile hardware that Android has, is just free ‘presence’, so stop wining about it. Android and Java were was already in place before you became the boss of Java. Use the situation to your advantage, instead of frustrating the ecosystem.

OTOH Google seems a bit short sighted that it won’t let Oracle be part of that ecosystem by compromising. Open source is not for everyone, and having to switch to some other programming platform besides the JVM (class files need not be written in Java after all) is in many ways a step back. I, for one, would not mind something like a 1% fee on my Android hardware, in order to get regular updates of official Java on Android. Or a pay-per-update (of the JVM) model. It should be possible to have separate updates of the JVM available for apps. Some companies simply have different earning models, there must be a common ground somewhere.

Anyhow. To be continued…

Posted in Android, Java, javafx, jfxtras, Lambda | 10 Comments

Enzo’s simple gauge in JFXtras

Gerrit Grunwald is an enspiring internet of things (IoT) evangelist and his JavaFX library ‘Enzo’ contains many visually attractive controls, well suited for IoT but also many other JavaFX applications. Gerrit used to be an active contributor to JFXtras, but he decided to move his work to his Enzo library. Why? Because the scope of JFXtras did not fit his needs.

As an IoT evangelist he develops many JavaFX controls for his demos, and he wants to get results fast; there is always that next conference in a few days.  JFXtras on the other hand tries to uphold a certain quality by a.o. requiring tests to prevent regression. This is not something a roaming evangelist wants to invest his time in. So we end up with an interesting situation; great but risky controls! Examples of this are all the gauges that are part of JFXtras-labs 2.x: they were never ported to 8.x and thus all their users have a problem there. This of course is the risk of using anything from JFXtras-labs, it is after all JFXtras’ playground, with no guarantee what-so-ever.

So what now? Great controls but too risky to touch? For Enzo that may be the case, as Gerrit states on his blog; “Please keep in mind that all controls in that library are made for my personal demos and are not production ready”. However, Gerrit and I have an agreement that I’m allowed to become ‘inspired’ by (aka blatantly copy) his demos. This already happened with CornerMenu, which was inspired by one of Gerrit demo’s and spawned CircularPane and CirclePopupMenu. The next inspiration Gerrit gave me was his SimpleGauge.


The control you see above is from  JFXtras and is known as SimpleMetroArcGauge and it (at the time of writing this) is part of JFXtras-labs. Currently it is in the process of fleshing out the API, which will be much more minimalistic than SimpleGauge, relying more on stylesheets. And also the concept of a single LinearGauge superclass is tried. After all, there is more to a good gauge than just a beautiful face.

When the gauge is finished, tests are written, and a sample is added to the samples, the gauge will move from labs to a new “gauge” module of JFXtras.

So there you have the explanation why suddenly Enzo controls start appearing in JFXtras.

Posted in Uncategorized | 7 Comments

circle popup menu

And once you are able to layout things in a circle…

Besides the CornerMenu described in the previous post, another incarnation of CircularPane is the CirclePopupMenu. It, as the name suggests, pops up a circle shaped menu on a mouse press.


And since it is based again on CircularPane, several animation options are available and others can be created manually. A few examples are:

circlePopupMenu-appear circlePopupMenu-fromOrigin circlePopupMenu-overTheArc

CirclePopupMenu is available in JFXtras-8.0-SNAPSHOT-r2. And like CornerMenu; let me know how it works in real world applications.

Posted in Java, javafx, jfxtras, UI | Leave a comment