Herding and Branding

Marketing people have a concept they use known as "branding". As a capitalist and entrepreneur, I love the idea of branding. I'm impressed by anyone who can get otherwise intelligent people to pay $50 for a five dollar white underwear t-shirt by putting the name of their brand on it. That is really cool. I wish I could do that!

But with that said, as a consumer I find branding kind of insulting.

I suspect that Lexus, Toyota and Scion (all Toyota brands) do not represent 3 categories of car as much as they represent categories of marketing strategy. In other words, different people respond differently to different sales gimmicks. By creating 3 virtual car companies, Toyota can ensure that each person receives the exact sales message that works on them.

There is nothing inherently wrong with this kind of thing. Obviously it works on some people - maybe all people. But none the less, it's annoying to me - just as it's annoying when the used car salesman uses a cheap sales line on me.

IBM WebSphere
At one point WebSphere was a product (an app server). Then the marketing people at IBM thought: "How can we leverage the success of that product?" Their answer: Rename every other product to WebSphere. So IBM's IDE was renamed to WebSphere, IBM's messaging product was renamed to WebSphere, and so on. Yes. IBM really does think we are that stupid. Or perhaps their sales pitch isn't geared to the cats, but rather the cat herders. But in the end the word WebSphere, with so many meanings has no meaning at all. The whole WebSphere craziness just serves to confuse.

J2EE
I think the biggest culprit of branding craziness has to be Sun. I am a Java specialist. It's all I do. Yet, I have no idea what the current version of Java is. We started with 1.0, then 1.1, then 1.2, then 1.3, 1.4,1.5 and 1.6. But then there is also Java 5 and Java 6. And what the hell is Java 2 (as in J2SE and J2EE)?

JavaFX
So now Sun is at it again. JavaFX (Sun's cool new programming language) is not a language - it's a brand. That means JavaFX could refer to a programming language or a mobile phone but it could also refer to a banana.

JavaFX

So JavaFX is my new favorite programming language. Thats right - JavaFX is a new programming language.

I think a lot of people might be getting the wrong idea about JavaFX because of the marketing hype. When I first heard about JavaFX, it was positioned as an alternative to Flash (or Flex). As a way to create (and deliver) Rich Internet Applications. But upon further inspection one realizes that, at its core, JavaFX is really a new language that runs on the JVM. I would say that comparing JavaFX to Groovy (or even Spring) would be more appropriate than comparing it to Flash.

[Correction: Technically speaking JavaFX is a brand - JavaFX Script is the name of the programming language.]

I'm low on time right now and can't go into many details, but let me say this: JavaFX is not just another language that runs on the JVM, its a very cool language. By cool, I mean that JavaFX has a number of innovative features that produce immediate and pronounced payoffs. For example:

1. Type-safe JSON
Any one who has used languages like Ruby or Groovy or even JavaScript knows that those languages don't need all those damn XML files that are part and parcel to modern Java frameworks.

Essentially, any language that has syntax for array literals PLUS map literals has built-in support for declarative, XML-ish constructs:

For example in JavaScript:

var company = {
  name: "Smart Soft",
  url: "www.smart-soft.com",
  people:[
    {firstName:"Dave",lastName: "Ford"},
    {firstName:"Michelle",lastName: "Goldstein"}]
}

Now JavaFX has this same feature - but with one distinct advantage: the map literals are not maps - they are typed Java objects. Here is how this would look in JavaFX:

var company = Company{
  name: "Smart Soft"
  url: "www.smart-soft.com"
  people:[
     Person{
         firstName:"Dave"
         lastName: "Ford"
     },
     Person{
         firstName:"Michelle"
         lastName: "Goldstein"}
  ]
}

This "typed" feature means that the IDE can give you auto-completion and find your errors sooner rather than later. Bottom line: integrated declarative-style programming + type-safe IDE auto-completion and early error detection = big productivity gains.

2. Language level support for bi-directional data binding. This is analogous to JSF's "value binding expressions" or Microsoft's "bound controls". The data binding feature supports MVC architectures in the most elegant manner I have seen yet. You simply declare that a particular UI text field is bound to some field in your model object. And then JavaFX keeps the model and view in synch automatically.

There is much more to JavaFX than I have mentioned, but this should give a you a basic feel.

Minimal JavaFX Demo

Here are the absolute simplest steps to get a demo of JavaFX up an running:

1. Download the 3 JavaFX jar files:
   
javafxrt.jar
Filters.jar
swing-layout.jar
   
   You can get them from here:
   
   https://openjfx.dev.java.net/source/browse/openjfx/trunk/lib/


2. Create a text file called Hello.fx:
   

   import javafx.ui.*;
   
   Frame {
       content: Label {
           text: "Hello JavaFX"
       }
       visible: true
   }



3. Add the 3 jars and Hello.fx to your classpath


4. Run the script like so:
   
   java net.java.javafx.FXShell Hello
   
   Note: The name Hello is resolved via the classpath (not the file system).
   
   Here is how my folders looked:
   
   
~/DavesJavafxDemo/classes/Hello.fx
~/DavesJavafxDemo/lib/javafxrt.jar
~/DavesJavafxDemo/lib/Filters.jar
~/DavesJavafxDemo/lib/swing-layout.jar
   
   Thus, my classpath must include the classes folder plus the 3 jar files:
   
   
~/DavesJavafxDemo/classes
~/DavesJavafxDemo/lib/javafxrt.jar
~/DavesJavafxDemo/lib/Filters.jar
~/DavesJavafxDemo/lib/swing-layout.jar
   
   Here is the shell script I used:
   
   

   cp=./lib/swing-layout.jar:./lib/Filter.jar:./lib/javafxrt.jar:./classes
   java -classpath $cp net.java.javafx.FXShell Hello

   
   Note: The way I have the paths specified, you must run this script from within DavesJavafxDemo folder.
   
   On Windows, the shell script (runDemo.bat) would look like this:
   
   

   set cp=.\lib\swing-layout.jar;.\lib\Filter.jar;.\lib\javafxrt.jar;.\classes
   java -classpath %cp% net.java.javafx.FXShell Hello

Dynamic Language Benefits

Here is a specific, concrete example demonstrating one of the benefits of a dynamic language (like JavaScript and Ruby) as compared to a static language like Java.

Suppose you want to do some ad hoc profiling (and you don't have a profiling tool handy). Here would be one way to do it in Java:

long t1 = System.currentTimeMillis();
slowMethod();
long t2 = System.currentTimeMillis();
long delta = t2 - t1;
System.out.println("slowMethod: " + delta);

And here would be the same thing in JavaScript:

executeAndTime(slowMethod);

This works because JavaScript treats functions as just-another-object. As such, the function can be passed around like any other object. In this example, slowMethod (an object of type function) is passed as an argument to the executeAndTime() function. Here is what executeAndTime looks like:

function executeAndTime(f){
    var t1 = new Date();
    f();
    var t2 = new Date();
    var delta = t2 - t1;
    document.write("Delta for [" + f.name + "]: " + delta + " millis");
}

What to Hide?

In the world of computer programming, a lot of thought goes into deciding "what to hide" - in particular, what to hide from the computer programmer.

For example, at some point in history people wrote applications in machine language. Today machine language is hidden from the developer and we see something more human-friendly, like C or Java. The stuff that gets hidden is usually closer to the way machines communicate. The stuff that remains visible is closer to the way humans communicate. At least that's the idea.

The terms high-level and low-level are used to convey this concept. Low-level technologies are more machine-ish and ripe for hiding. High-level technologies are more human-friendly. The high-level technologies are often referred to as abstractions that encapsulate or hide the low-level technologies. Today's high-level technology often becomes tomorrow's low-level technology.

Char and Array

Two language constructs that I once used daily are the char and the array. Today, I use them only indirectly, preferring higher-level constructs like String and Collection. In other words, the char and the array are going the way of machine language: mostly hidden.

SQL

Sometimes it's not alway clear what should be hidden and what shouldn't. For example, many years ago a high-level language called SQL was invented for working with data. SQL is an abstraction designed for humans. SQL is, in no way, a reflection of how machines or hardware work. It was designed for humans. Yet still, SQL is gradually crossing over to the world of the hidden, joining the ranks of machine language, chars and arrays. If you have ever used JDO, EJB Entity Beans or Hibernate, then you know what I'm talking about.

JavaScript

The blogs are filled with developers singing the praises of dynamic languages (formerly known as scripting languages). The two most popular dynamic languages that I use are JavaScript and Ruby. Dynamic languages are often more terse, flexible and feature-rich than static languages. Static languages, like Java, do have their advantages though. They are typically more IDE'able and optimizable. The thing to note here is that both Java and JavaScript are pure abstractions. Both were invented to be human-friendly ways of programming computers. But if I had to pick one as being "lower-level", it would be Java.

So which is the preferred abstraction? Java or JavaScript? Not everyone agrees. But if you look at frameworks like the Google Web Toolkit (GWT) or ICEfaces you will see that JavaScript may be crossing over into the land of the hidden. With GWT, the human codes in Java, then the GWT compiler translates your Java into JavaScript. No human ever sees the JavaScript. Only the machine sees it. In this case the machine is the JavaScript enabled web browser.

Hiding Gone Wrong

The key point here is to choose your abstractions wisely. The stuff that's not hidden ultimately becomes a dependency. The goal is to encapsulate things that are complicated or volatile behind abstractions that are simple and stable. Here are a few examples where, in my opinion, the choice of "what to hide" is sometimes wrong:

Web Service Toolkits
XML is simple and stable. HTTP is simple and stable. Web service toolkits (like Axis) that hide the XML are not simple or stable. They add unnecessary layers and complexity. For most developers that need to produce or consume web services, it makes more sense to work directly with XML. Tools like Axis have their place, but in my opinion, that place is a fairly small niche*.

O/R Mappers (like Hibernate)
SQL is simple, stable and extremely versatile. I can teach anyone SQL in a half day. Hibernate is not so simple. Contrary to what anyone tells you, it's a very sophisticated tool. If you don't know what your doing, it can easily cause more trouble than it saves you. Again, Hibernate does have its niche*. In fact, I love Hibernate. But do keep in mind that with Hibernate (and O/R mappers in general) you are encapsulating something really simple with something really complicated. So be sure you are clear on the benefits and drawbacks before moving forward.

* Note: if you take our Hibernate or Web Services workshop, we do cover these decision making criteria. That is: when does it make since to forgo Hibernate or Axis and work directly with the underlying technology (like SQL or XML)?