WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.
As mentioned previously, Project Semplice (Visual Basic for the Java platform) was unveiled at JavaOne, both with a technical session, as well as a keynote demo during the technical keynote. The video stream of the broadcast is available - choose
high bandwidth or
low bandwidth.
This is the third part of the keynote, and the Semplice segment begins at around 10:40, where Graham presents the intro slide, and lasts until about 14:40. If you have time, you should check out all the keynotes.
The audio comes through well, but it's hard to see the screen in the video. So let me show you the code in more detail.
I built a temperature converter application, converting Fahrenheit degrees into Celsius. To do that, I dropped three components: a textfield, named fahrenheit, a button, and a label, named celsius.
I then added an event handler to the button click event, which will convert temperatures according to the standard formula:
celsius = (fahrenheit - 32) * 5/9
To motivate why BASIC can be attractive, especially to new programmers, I showed what we'd write in a standard Java application utilizing the above JSF components:
celsius.setText(""+(Integer.parseInt(fahrenheit.getText())-32)*5/9);
I agonized over what code to write here. I personally don't like to use the trick with ""+ to cause integer to String conversion; the code I would have written is using Integer.toString(int):
celsius.setText(Integer.toString((Integer.parseInt(fahrenheit.getText())-32)*5/9));
But I'm not out to try to make Java look bad! And given that many people do use ""+, I went for the shorter solution. There is of course another possibility I could have used, which may be more true to the spirit of JSF. I could have dropped an IntegerConverter on the textfield. I could then have written code like this:
celsius.setText(""+((Integer)(fahrenheit.getValue())).intValue()-32)*5/9);
but as you can see this is not simpler than calling
Integer.parseInt() directly - and it adds more complexity to the demo. (auto-unboxing might eliminate the need for the .intValue() call but you'd still need the cast, and that alone is a showstopper for "newbies".)
So the next step was to write what the equivalent code looks like in BASIC. Here it is:
celsius.text = (fahrenheit.text - 32) * 5/9
Notice that this looks a LOT like the original formula. In fact, at the end of the demo I actually comment out the above line and uncomment the original line - and that's the code I compile and deploy!
As I mention in the demo, there are several interesting things to note here.
- The BASIC code is extremely simple. In this particular instance, Java looks complicated. There are two reasons why the BASIC code is simpler.
- First, it performs a lot of automatic type conversions. We're mixing strings and numbers here, and the Right Thing happens. Strings containing numbers get parsed into numbers, computations happen, and when a String is needed it's generated from the numerical result.
- Second, we're able to access Java class properties using simple property syntax. Instead of calling
celsius.setText(), we're
writingcelsius =, and the right hand side expression is fed into the setter. Similarly, we can refer to thegetTextmethod of the textfield by simply referring to it by its JavaBean property name.
Java is more strict in which type conversions it will allow. "Automagic" type conversion can be dangerous. In Java you frequently get compiler
errors or warnings if you do something that is probably wrong. In BASIC you won't notice until runtime - and hopefully it's not a rare scenario that
goes undetected until a customer runs into it.
A classic example of this happens in C, where any number is converted to a boolean when
needed - nonzero is considered true, zero is considered false. If a programmer writesint x = getFoo(); if (x = 50) { ... }, Java would complain, because theifstatement evaluates to an integer rather than the expected boolean (notice that it's a single=, not==). In C, some developers like to
take advantage of this "expressiveness", but it's usually a sign of a bug.
Even in Java, where typing is pretty strict, you can run into trouble
with some of the automatic conversions. For some great eye openers, read Java Puzzlers! See Puzzle #1
in the sample chapter for example. - First, it performs a lot of automatic type conversions. We're mixing strings and numbers here, and the Right Thing happens. Strings containing numbers get parsed into numbers, computations happen, and when a String is needed it's generated from the numerical result.
We're calling into Java classes from BASIC! Thecelsiusandfahrenheitreferences point to Java objects that are instances of JSFUIComponentclasses, written in Java.
We've written an event handler (attached to the button event) in BASIC. This event handler is being invoked from Java code (the JavaServer Faces web framework). Thus, we have Java calling BASIC calling back into Java.
The reason I could uncomment the original line, the one which doesn't specify thetextproperty of the textfield or labels, is that
the compiler also understands JavaBean default properties. If you leave out the property, it will look at the default property (which these JSF components specify in their BeanInfos) and use that one.textis the default property for both of these. The compiler cannot always do this - in some
cases it's ambiguous - but when there is no ambiguity, it compiles without complaining.
Anyway, at the end of the demo I deploy. This compiles the BASIC file down to a Java bytecode class, which is located and instantiated by the
JSF managed beans machinery at runtime. As a result, the application works and the JSF framework has no idea it's talking to BASIC code.
So that's the keynote. At some point, the technical sessions will be made available online, so you can get all the gory details from TS-3576. Last year's presentations are available here - as you can see, you get both the slides and the synchronized audio track. This year they asked us to reduce the resolution on our laptop, even though it was showing fine on the projector, because some recording equipment needed it, so if we're lucky, the demos will be included in this year's multimedia version. As I mentioned the other day, for now you can see some demo screenshots and descriptions in Herbert's blog.
