Fabrizio Giudici is a Senior Java Architect with a long Java experience in the industrial field. He runs Tidalwave, his own consultancy company, and has contributed to Java success stories in a number of fields, including Formula One. Fabrizio often appears as a speaker at international Java conferences such as JavaOne and Devoxx and is member of JUG Milano and the NetBeans Dream Team. Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

What I'm Missing in JavaFX 1.2 ;-)

06.03.2009
| 5129 views |
  • submit to reddit

OK, tons of new things in JavaFX 1.2, but of course we developers always want more! I'm not asking for major stuff right now, as I understand that the effort behind JavaFX is huge. But there's really a small thing, that I realize is missing right now: support for logging.

Of course I'm not talking of the desktop profile: you can use anything you want, from java.util.logging, to log4j or SLF4J. I'm talking of the mobile profile, where we don't have anything.

And, of course, you can write your own, and would be pretty simple. But look at this:

def x = 3;
logger.fine("x = {x}");

The problem is about performance. Even though the "fine" logging level is disabled, the JavaFX compiler will always first build the string parameter, converting x to a string, putting into the template according to the braces placeholder and then call the method, where it will be ignored. In contrast, SLF4J approach is smarter since when you write:

int x = 3;
logger.debug("x = {}", x);

you don't have any string manipulation before calling the method; instead, it is SFL4J code that inspects the string template and replaces the braces placeholder. Of course, only if the debug level is enabled.

Clearly, this is really important in the mobile profile, where every single piece of performance is needed; and polluting the code with "if (debugLevel) ..." is even worse than in Java, since JavaFX is so concise.

Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Priya Dandekar replied on Wed, 2009/06/03 - 10:35pm

Sure looks like a room for improvement. Hw much perf imp it will make though? I guess very low? and u r always free to use the other option anyways. Sometimes when writing big frameworks like this they can't keep everyone happy. wt do u say? Kzvi

Peter Stricker replied on Thu, 2009/06/04 - 12:18am

As long as JavaFX undermines the promise of "Write Once Run Anywhere", I won't touch it with a ten foot pole.

Jess Holle replied on Thu, 2009/06/04 - 12:28am

I'm not sure JavaFX undermines this.

As I see it Java ME is a gaping violation of Write Once Run Anywhere -- in 2 dimensions:

  1. Available API set
  2. Language version

#1 can be readily subsumed into a more modular notion of Java.  #2, however, is a festering wound.  The fact that Java ME still does not support Java 5/6 language features and core APIs is a travesty.  It means libraries that leverage and depend upon these features can't be used on Java ME -- and forces every problem that applies to mobile spaces to be solved twice: once for mobile and once for everything else.

I understand and value supporting code written for old Java versions and older hardware which only supports older JVMs.  What I don't understand is Java ME hardware shipping today without support for Java 5/6 language features and APIs.

FX gives a common shellac over all of this, but it doesn't help when you need to use Java libraries under that layer and you can't use the same basic language features (e.g. generics) in mobile as you do elsewhere.

Peter Stricker replied on Thu, 2009/06/04 - 1:50am

So where can I download the officially supported JavaFX 1.2 for Linux?

Sidney Beekhoven replied on Thu, 2009/06/04 - 3:40am in response to: Peter Stricker

Philippe Lhoste replied on Thu, 2009/06/04 - 5:31am

You are probably already aware of that, but for the others, I will mention that the new Storage class is probably suited for storing the logs. Obviously, such log shouldn't be too verbose on most mobiles...

I was about to write one could use Formatter Java class to do the job of lazy string building, but after checking I see it is missing from Basis Profile... :-(

Actually, I just notice JavaFX just doesn't support variable number of arguments in function, unless I missed it somewhere. Too bad.

Peter Stricker replied on Thu, 2009/06/04 - 6:01am in response to: Sidney Beekhoven

Great, I was not aware of that download page. I am sure that I wisited the download page for JavaFX only a few days back, and there was still no Linux edition. And also no mention of a timeframe for when we could expect it to be finished.

Anyway, thanks Sidney.

Fabrizio Giudici replied on Sun, 2009/06/07 - 11:01am

As long as JavaFX undermines the promise of "Write Once Run Anywhere",

Can you elaborate where the promise of WORA is violated (more than it already happens as per comment by Jess Holle? For instance, I've just written code that runs in the mobile emulator (and soon on a real phone, as soon as I grab it) and as an applet. With plain Java, this is possible only for smaller things, supposing you're using some JME library that emulates Swing.

Actually, I just notice JavaFX just doesn't support variable number of arguments in function, unless I missed it somewhere. Too bad.

You're right, it doesn't. You could construct sequences on the fly with very few syntax overhead (e.g. foobar([a,b,c])) but sequence are heavy from what I understand (unless there's some specific compiler optimization that kicks in if you don't use binding etc...). What I'm resorting to is the same trick as SLF4J that doesn't use varargs to keep compatibility with older Java version, that is overloading each method with 3/4 variants having 1..4 arguments.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.