Wednesday Nov 29, 2006

Semplice Is Dead. Long Live Semplice!

My co-conspirators on Project Semplice, John Kline and Herbert Czymontek, have both recently left Sun. Rest assured, I'm not going anywhere. But where does that leave Project Semplice?

Well, the spirit of the project was to support scripting on the VM. We started our research with BASIC, but the vision all along was to design things in such a way that we could support multiple scripting languages, without starting from scratch each time. The tooling aspect was my responsibility, and I'm happy to say it has not been in vain. With the hiring of the JRuby developers, I've been focusing on how to adapt everything to support Ruby, and it's going really well. I'll post a second blog entry on that shortly.

Back to BASIC. Like most software at Sun, open source is the obvious strategy and we have started the process. On the other hand, just "dumping code on the community" is not likely to be successful, so we're looking for interest and support to decide how to proceed.

In any case, as the blog title suggests, the project is not dead. It was a research project, we've learned a lot, and the technology is now forming the basis for some great new scripting tools coming your way very soon. Rising out of the ashes, so to speak! We'll have more to show at JavaPolis in a few weeks, so keep your eyes peeled!

Monday Jul 31, 2006

My first BASIC compiler

Picture of compiler advertisement I started my programming "career" on a Dragon 32 microcomputer in 6th grade. It had 32K of RAM, although once you turned the computer on it would launch a Microsoft BASIC interpreter which left 24K for your own programs. I spent countless hours on that computer in 1984, 85 and 86, writing a lot of BASIC code.

It's fun to have looped around in my career and to suddenly be working with BASIC again - in the Semplice project. If you missed it, my coworker Herbert was interviewed on the Java Posse. In addition to talking about supporting BASIC on the Java platform, he talks about supporting other VM languages in general. It's a good, meaty technical talk.

Anyway, back to BASICs. I have moved recently, and as part of the large cleanup, I had to decide what to keep. I found a stack of old computer magazines that I had held onto. These were British computer magazines I subscribed to - and were largely responsible for teaching me English. Understanding the articles in those magazines were a lot more inspiring than the stories we were encouraged to read in English class!

I realized I can't drag these magazines with me forever, so I decided to thumb through them one last time before throwing them in the recycling bin. And in one of the magazines I noticed a part of a page had been cut out. Major flashback! This was the advertisement for the first piece of software I ever purchased! The missing piece was the order form I had cut out and mailed in. And what was this product? A BASIC compiler! (I've scanned in a portion of the ad on the right.)

Yep, I was programming BASIC, but performance was slow, and I realized (from all those computer magazines) machine code was where I wanted to be. I thought a compiler would do the trick - so I bought it. My programs did execute faster - but I didn't end up learning assembly code until I got a Commodore 128, and later a Commodore Amiga. Ah the memories. The advertisement has a picture of the tape cover (I didn't have a floppy drive until the Amiga), just the way I remember it.

Monday May 22, 2006

Keynote Demo Explained

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:


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):


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:

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 writing celsius = , and the right hand side expression is fed into the setter. Similarly, we can refer to the getText method 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 writes int x = getFoo(); if (x = 50) { ... }, Java would complain, because the if statement 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.

  • We're calling into Java classes from BASIC! The celsius and fahrenheit references point to Java objects that are instances of JSF UIComponent classes, 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 the text property 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. text is 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.


Tor Norbye


« July 2016