JavaFX: one year later

Just as JavaFX SDK 1.0 was released about a year ago, I was eager to give it a try. At first I was surprised at how many features and APIs were cut from the beta version that I had also tried. By the way, a couple of books had been written based on the beta version and I probably should now recycle those books because they have become worthless since 1.0 came out. I guess it was done to achieve release quality. Well, nevertheless, the quality of JavaFX 1.0 was no short of horrible. I personally had filed 3 serious bugs before I decided to put it “on the shelf”.

Later during the year I revisited JavaFX: 1.1, 1.2, 1.2.1. I also tracked the bugs that I had filed – one was resolved, two others weren’t. Not to mention the bugs I filed for NetBeans plugin – it looks like they have their hands so full that NetBeans plugin is under the radar. It was also funny to watch Sun’s attitude towards JavaFX for Eclipse change from denial to acceptance.

The real reason I am writing this article though is JavaFX and Swing. Sun still doesn’t want to make JavaFX components be embedded into Swing apps although most Java developers would agree that this is a must have feature -- just read Josh Marinacci’s article on the topic and all the comments that follow. What Sun has been hiding from the beginning is that JavaFX is based on Swing, that JavaFX-in-Swing integration is easy to implement, and that the APIs actually exist but they aren’t published. Huh?

Have you imagined that there are APIs available at runtime but not in the SDK? Well, that’s exactly the case with Swing integration APIs. For a developer, it means that you can’t compile your program using the SDK but you can if you download the runtime. Many thanks to Michal Margiel and his colleagues for discovering it. Do you know another company that does such things? I'll give you a clue: its name starts with "Micro" and ends with "Soft".

All this bullshit is just inconsistent with the spirit of Java. I can really feel Marketing’s evil hand here. Is there a hidden agenda that we aren’t aware of? Sun’s VP of Marketing, Eric Klein, who so passionately presented JavaFX in his “Getting Started with JavaFX” video, started it like this: “When we were working on JavaFX, we were really thinking that there’d be three groups of folks who would love the power and the potential inside JavaFX. The first group we thought of was our existing Java developers”. See? He is really thinking about Java developers. Wait a minute, according to Eric’s LinkedIn profile, he joined Sun in February ‘08. How long has he been working on JavaFX? That guy, actually, is also an angel investor in a startup called Zoodles, which uses Adobe AIR as the technology for its rich internet application. This really stinks.

Closures in Java: another proposal

I am glad that none of the proposals for Closures have been chosen for Java 7. If you don't know, their code names are: BGGA, CICE, and FCM. Why? Because they all suck. Here is my proposal: to introduce alternative syntax for defining an anonymous inner class that extends Object and implements an interface with only one method, with the following construct: { arg1, arg2,... argN => statements; } or { statements; } if the method doesn't have any parameters.

Example 1:
SwingUtilities.invokeLater({field.setText("Hello");})

which is equivalent to:
SwingUtilities.invokeLater(new Runnable() {
public void run(){
field.setText("Hello");
}
});


Example 2:
List<String> list = ...;
Collections.sort(list, {a, b => return a.compareToIgnoreCase(b);});

which is equivalent to:
List<String> list = ...;
Collections.sort(list, new Comparator<String, String>() {
public int compare(String a, String b) {
return a.compareToIgnoreCase(b);
}
});


JSP Sucks

The first time when I used JSP was in 1999, with WebLogic server. I used a “cookbook” approach: make a JSP, deploy, test, enhance it, and so on – what’s called “rapid development”. My understanding of HTTP and DOM was poor. That’s my excuse to having used it in the first place. Back then there were plenty of thick books on J2EE, and JSP was practically the only JAVA technology for rendering dynamic web pages. It was hard to argue that the pros of JSP must outweigh the cons. Let’s recall what the claims of JSP are:

1. Easy conversion of legacy HTML pages to dynamic pages;
2. Separating code from presentation;
3. Ability to extend JSP language via tag libraries.

But before I go into dismissing those claims, I will describe my point of view on software design.

The Biggest Design Flaw

The biggest design flaw you can have in a program is code duplication. Source code is for humans to read. A typical program or module includes tens of thousands of lines of code, which is equivalent to a thick book. In literature lessons, they teach you that repeating your thoughts is bad, and so it’s bad to repeat code, including comments.

Another, stronger reason why code duplication is bad is because the thought process during code writing includes a great amount of generalization. Generalization is a fundamental component of human intellect. In fact, human languages have been evolving together with advances of human intellect by adding the words representing generalized or “abstract” terms. If our language didn’t have words such as “circle”, “food”, “vehicle”, we could still communicate, but our communication would have been much lengthier and confusing. Duplicated code reflects the lack of generalization during programming process. The programmer, who repeats the same code over and over, fails to generalize those pieces of code. Then the people who read duplicated code will have to spend more time understanding it because they would have to perform the generalization process themselves, essentially doing the job that the first programmer failed to do.

And now we come to the third reason: maintenance. When it comes to maintenance of a program, duplicated code is the killer. Here is a typical life story of a program: it’s designed with the ability to be extended. But when the extensions are written, there is no more design, and therefore lots of duplicated code. During maintenance, every piece of duplicated code needs to be carefully changed and separately tested. And then, the system becomes too expensive to maintain. It is illustrated by the chart below.

I have to admit, most software projects go this route. However, a program’s life can be shorter or longer depending on how good the framework is, and how much attention is paid to enhancing the design while writing the extensions. Every decision to write duplicated code instead of re-writing existing code shortens the life of the program.

JSP and Duplicated Code

Everything said above has direct relationship to the title of this article, because JSP technology doesn’t just promote duplicated code, it EQUALS duplicated code. Let me prove it to you.

First of all, any Java code that resides in a JSP page is not reusable, period. If you ever need to design a similar page, it’s much easier to cut and paste that code, than remove it from the original JSP page and put it in a Java class.

Does it contain <html>, <head>, <body> tags? If yes, it’s code duplication. Do any tags that you use contain any formatting, or JavaScript handlers attached to them? If yes, it’s code duplication because I am sure you use the same tags with the same formatting attributes (CSS is not an exception) in other JSP pages. Does your JSP page contain other repeated sets of nested tags perhaps with different parameters? If yes then it is code duplication.

This leaves only custom tags. Indeed, the only way to avoid code duplication in JSP is to make it consist of only custom tags. But that would defeat the first claim of JSP, “Easy conversion of legacy HTML pages to dynamic pages”, because writing custom tags for the legacy HTML pages means practically re-writing them.

Separating Content and Presentation

In order to achieve separating content from presentation, a JSP page must not contain any Java code. In practice, it requires a great deal of discipline to do so because all JSP books and tutorials teach you how to mix Java code with HTML. There are in fact advocates for this approach. The only way to populate a data table without using a Java loop is to use custom tags. The Standard Tag Library, JSTL, defines such tag and many other tags exactly in order to avoid using Java code in JSP. Here is a quote from JSTL home page:

“ JavaServer Pages (JSP) technology makes it easy to embed bits of Java code (or scriptlets) in HTML documents. This solution, however, may not be suitable for all HTML content developers, perhaps because they don't know Java and don't care to learn its syntax. To serve these HTML developers, you can introduce custom tags through the JSP Standard Tag Library (JSTL 1.0), which can be deployed and used in an HTML-like syntax.”

Okay, perhaps you can find a web designer who will use JSTL tags in the JSP pages that he/she will write, and Java developers will just write Java Beans. But what about text? Menu names, copyright, column titles, whatever else static text needs to be displayed on the page? If your web app needs to be localized, no text should come with the page from the HTML designer. But then visual design tools become kind of pointless.

Also, how would an HTML designer create reusable elements? Fancy borders, fancy buttons, fancy menus, fancy whatever. It all needs to be reusable. Because it’s not possible, HTML that comes from the HTML designer contains a lot of duplicated code, with all the consequences. And CSS is not a panacea, because in CSS you can’t define JavaScript event handlers, you can't specify the tag used for rendering the element (for example, whether to use an <a> tag or a <button> tag), and some attributes simply don’t have CSS equivalents (example: cellpadding and cellspacing).

To be fair, there is <jsp:include> using which big page elements, such as “masthead”, “navbar”, and “footer” are made reusable via JSP include directories. But using “include” for fancy borders and buttons just isn’t practical. There is even a more “advanced” way to include those “mastheads” and “navbars” intended to avoid duplicated code for page layout: Tiles. But because a “tile” is not a fully-functional HTML document, you can’t use traditional visual design tools for JSP.

Tag Libraries

As it was mentioned above, a good JSP page should contain only custom tags. Essentially, it becomes an XML document. Does XML need to be compiled? Would pre-compilation bring any benefits at run-time? Perhaps, but not in the case of JSP. When you use a custom tag, JSP compiler doesn’t call your tag class to render the corresponding HTML tags, it just places a call to your custom tag class in the generated JSP class.

The conclusion: if you’ve managed to design your JSP pages with only custom tags then there are better technologies that you could use instead, but that’s another story.