What I'm Missing in JavaFX 1.2 ;-)
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.
(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
Peter Stricker replied on Thu, 2009/06/04 - 12:18am
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 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
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
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.
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.