Posted by panaseam
on October 2, 2006 at 1:34 PM PDT
A brief look at three different attempts at supporting classic VB code.
Semplice, OpenOffice & PaNaSeaM.
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?