Pete Morgan's Blog

October 2006 Archives

Of Netbeans form files, Widget macros and Matisse.

Java is on it's way out? Not from where I'm standing!

I've just been musing over the current java.net poll What do you prefer for enterprise Java persistence? and noticed that out of a total of 1425 votes cast 107 voted for "I don't develop enterprise Java". I am one of those 107.

Now I know the poll is about enterprise Java so you may get a slightly higher response rate from people that do develop enterprise Java, but this roughly indicates that 92.5% of java developers do enterprise Java development and 7.5% don't. Yes I also know the old saying about “lies, damn lies and statistics” and I can't help wondering how many of those developers also do desktop application development.

The reason for my interest in these numbers lies in the fact that in my nosing around the internet I often see posts by the “Java is dead” brigade, and whilst I have never tried quantifying anything, they also seem predominantly enterprise related rants.

To get to my point, I honestly think that Java, from my desktop only perspective, is “top of the pile”. To my mind Java encapsulates such a high percentage of whatever I need to do the job that I actually don't have to look elsewhere to get the job done. Swing is being improved all the time plus you have the innovative work of people like Kirill Grouchnikov, or you can use SWT if you prefer. And all this is platform independent! So from my vantage point Java is very much alive and kicking.

On the desktop you only really need one tool, an IDE, beyond that, with Java you have all you need to get developing. Yes you may prefer to use, for example third party widget libraries or re factoring tools etc., but you don't have to have them to be productive. Lets face it you could do without an IDE if you want. Yes just J2SE JDK, an editor and off you go!

I know Java gets knocked as a desktop environment as well, but quite frankly, unless you are a “ ' softy” and want to be ensnared in the "net", what other languages give you all you need in one package? Yes I am aware of the Mono project, but I don't get a warm comfortable feeling about it, I still feel that "net" closing round me!:-) We all know nothing is perfect, there is always room for improvement but all too often whingers make statements like “C# has pass by reference so Java should have it too, otherwise I'll just have to move over to C#”. <rant>Well all I can say is if a dumbass like me can emulate the whole VB core language in Java, including, pass by ref, GoTos, weird operator precedence and pretty well every other VB strangeness then “Java don't need changing” and certainly not to keep some lame brain troll from “defecting to C#”!</rant>

In the enterprise scenario, part of the problem, as I see it, is that if all or most of your development is geared around a browser at the client end, it isn't so much what the language does or doesn't give you in itself, but more about the tools and frameworks that are available for your chosen language. So often the ranters don't distinguish between the way Java enterprise solutions are created and the language they are created in. I have even seen Ajax used as a reason why Java is doomed. That is a weird view since I thought you can “do Ajax” in Java, but then what do I know? I wonder how many posts on non-Java sites there are praising Java? Not many I guess. Why? Because real Java developers know they are on to a good thing and don't waste their time trying to convince “non believers”. The language is only as good as the people who use it! Enough said!

So from a lowly, part time, desktop bod to all you real Java developers I say ignore the trolls, let them get on with their latest “next best thing” you know you've already found it and its called Java.

Happy hacking,

Pete

Projects Semplice, OpenOffice.org & PaNaSeaM: Supporting classic VB.

Earlier this year, at JavaOne, project Semplice was announced, the aim of which is to allow VB code to be compiled directly into Java bytecode. The development environment is an extension to Netbeans.

Prior to this, Novell has been working on a sub project of OpenOffice.org to allow VBA scripts embedded in documents to be executed directly in OpenOffice. This is not a Java solution although the extended, VB compatible API will presumably be accessible to Java through the Java UNO binding but the execution of the VB code will presumably be via extensions to the OOBasic interpreter built into OOo. It is unclear as to whether or not editing and debugging of VB code will be allowed.

There is also, a virtually unheard of java.net project, panaseam, that is also aimed at classic VB support using Java. This project uses the concept of conversion to Java, but attempts to maintain program semantics by emulating the VB runtime environment as closely as possible. Hence the converted code is recognizable when compared with the original.

In order to do anything with VB code in another environment you have to emulate the functionality of the core VB language engine. I do not know any details as to how Semplice or OOo are doing this. Presumably, as OOBasic is conceptually very similar to VB, extending the interpreter was not too difficult. With Semplice they are presumably doing the “conversion” in the compiler so that the JVM actually sees nothing but perfectly standard Java bytecode.

In order to avoid “surprises” for the end user it is very important to maintain total functional compatibility between the original and target environments. There are a few issues that they must have dealt with if the VB code is to run exactly as it did in the VB environment. I am not saying that they haven't dealt with these issues, but if they haven't there will be problems for the end user.

VB passes parameters by reference normally. Java ALWAYS passes by value. Not to be confused with passing a referent by value this is not the same thing at all. It means an object passed by reference can be replaced by a new object in the called procedure and this new object will also appear in the scope of the calling procedure. This works the same for primitives as well, but, thankfully, not for constants. Whilst using this functionality may be considered bad programming practice, in order to maintain 100% functional compatibility it needs to be implemented.

VB operator precedence is significantly different to Java. Good maintainable code should not rely on operator precedence however who said the VB code is going to be good?

VB has a “Static” declaration that causes procedure local variables to retain their values between calls. This is nothing like the static modifier in Java. This functionality is probably little used but again it needs to be implemented.

There are some legacy Basic elements in VB the worst ones are
GoTo, GoSub, On .... GoTo etc. Unfortunately VB uses GoTo for error handling.
If the error handling semantics are not accurately reproduced some very odd problems could arise.

VB file handling is a bit odd. When files are opened they are allocated a number and all references to that file use that number.

Open FileName for Output As #92 'Opens a file
Print #92, Tab(12), "A bit of text" 'Writes some data to the file
Close 92 'Closes the file
Name FileName As NewFileName 'Rename the file

Now it's not that difficult to emulate this behaviour but it's oddness must be accurately reproduced.

VB has a wonderful “data type” called a Variant which can contain anything you like or don't like come to that.

So all in all lots of fun!

Neither Semplice or OOo are attempting any sort of code conversion, One advantage of this approach is that you maintain interoperability with the original environment. Hence, particularly in the OpenOffice case, you could share documents that include macros between Windows, Mac and Linux users for example.

If, however, your only aim is unidirectional migration from a platform locked environment then retaining backward compatibility becomes moot.

I see the three projects as primarily complimentary not competitive.
Semplice is addressing continued support for standalone classic VB.
OpenOffice is addressing interoperability in the office productivity environment.
Panaseam is addressing VB to Java migration.

Yes panaseam overlaps the other two in the sense that it is taking a holistic approach to VB but it is certainly not a compiler and it is definitely not an office productivity suite.

One problem I see with both the Semplice and OOo approach is that if an end user hits a problem because either the compiler or runtime VB emulation, or whatever, is not quite right, they cannot do anything about it! All they have is VB code that doesn't work in the new environment. Even if both projects open source their work, Semplice will probably be deep JVM and compiler stuff, and OOo will all be implemented in C++ and UNO, neither of which is suitable for the likes of ex VB coders or even some Java coders to unravel. So all the end user will be able to do is send a bug report and wait.

Also neither project appears designed for end users to directly add missing functionality.

The panaseam approach is via code conversion, coupled with an open source Java runtime environment that emulates the whole VB core language in Java. If the end user hits a problem due to a drop off in translation or runtime emulation, they can compare the translated code with the original to see if the program semantics have been messed up by the translator and they can also delve into the runtime environment, which will be pure Java, to see what is going wrong there.

Also as the environment will allow pluggable runtime modules to be used, the end user could even create their own tweaked version and simply plug it in place of the supplied module. It also means missing functionality can be added readily as it becomes available without having to be released as a complete update of the whole environment.

A big advantage for the Semplice and OOo projects is that they can choose to keep their solutions closed and as a result they won't expose themselves to copyright infringement claims and anyway they are under the umbrella of large organizations. Yes I know closed source would be a problem for OpenOffice but at the moment the VBA extensions are still being developed by Novell and could be released as a closed source add on.

The panaseam project has already proved that the concept works but has hit a “slight” problem.
In order to go any further and turn panaseam into a production usable system it means creating and publishing the entire VB and core MSOffice APIs re-defined in Java. As a lone developer I have no financial or legal support so if I publish and Microsoft decide I have infringed their IP, I could be flattened.

That leads me neatly on to the next part of my blog IPvIP Part2: Is a Java interface copyright protected?

Happy hacking
Pete

This work is licensed under a Creative Commons License.