Pete Morgan's Blog

Programming Archives

Of Netbeans form files, Widget macros and Matisse.

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

IP v IP. (Intellectual Property versus Innovation Protection) Part 1: Courts and Coders

There are numerous small open source projects hosted on java.net and whilst this post, in itself, is not Java specific it is as the owner of one of those small projects that I voice my concerns!

It's a reasonable guess that many programmers find legal stuff boring as hell and as far as possible ignore it. Unfortunately in this world of patents and copyrights it could be only too easy for an ordinary open source coder to fall foul of alleged intellectual property infringement. Ignoring the legalities is not an option, in the eye of the law "Ignorance is no defense". Also complacency is anti-innovative and therefore unacceptable.

If you program in a purely commercial environment you may feel legal issues don't affect you, but if you use any open source software at all then you should at least consider how legalities could affect that software and its future availability.

Just to make a point consider this scenario:

I have a project hosted on java.net.
I upload some code and make an announcement telling all the world how clever it is.

Now here's the essence of the problem:
I wrote the code in the UK but it is hosted on an American server. What jurisdiction does it fall under?
This code is visible anywhere in the world that can be accessed via the internet.
Can I be 100% sure my code doesn't infringe somebody's IP according to my own country's laws?
Worse how do I know it doesn't infringe someone's IP according to some other country's law?
Even worse, what if someone wants to stop me from continuing my development because they perceive a commercial threat to their own products? If they have enough money they can simply sue me in a country of their choosing on some dubious grounds knowing that it is unlikely I can possibly afford to defend myself. So I'm then left with the choice of disbanding my project, with the hope that they withdraw the lawsuit or risk having the court rule against me, levying some ludicrous fine and basically preventing me from ever going to that country for fear of being arrested for non-payment of that fine. At least if I got sued in my own Country I may be able to attempt to defend myself, although the likely outcome of that is far from promising even if I am genuinely innocent.

Far fetched isn't it?

Unfortunately not! (apart from the implication that I could ever write some clever code)

As an example of what can happen, although not IP related, consider UK based anti spam company Spamhaus being taken to court in Chicago [ http://arstechnica.com/news.ars/post/20060915-7757.html ].
Although Spamhaus could have probably won the case, they chose not to defend themselves and got heavily fined. Since a US court has no jurisdiction in the UK, Spamhaus can avoid paying the fine but will it's directors ever be able to visit the US without fear of being arrested? This happened in a US court but it could happen anywhere. Is this justice?
[ http://en.wikipedia.org/wiki/Justice ]

If something like this happened to me it might mean I'd never be able to meet Mickey, Minnie, Donald and Goofy again, not to mention missing out on $3.99 breakfast buffets and 7.5 ounce choc chip sandwich ice creams. Now that is serious!

The problem is that legal systems don't prevent you being sued even when you haven't done anything wrong. Consider SCO v IBM. Even though this case involves two large companies rather than large versus tiny, which is my real concern, it still shows how a business with enough money can launch a lawsuit against anyone on pretty tenuous grounds. There is also a far more sinister undertone in the popular belief that SCO were in fact "put up to" the action by a third party.

Anyway, whether or not these cases are relevant, my point is that the patent/copyright jungle is a nightmare for ordinary hackers to even begin to cope with. Larger projects and especially commercially supported ones probably have the resources to at least give a supportive legal umbrella for its members. Any of us working alone or in small groups have no support whatsoever.

Remember that open source is making it in the big league, some of the existing big league players could get seriously worried about losing their position and the money that goes with it. They will stop at nothing to maintain that position, these guys play dirty and enjoy bullying little guys so beware, things could get very nasty!

One possible solution is to try to get your own ideas accepted as a sub project of an existing large commercially supported project. Even this could be problematic. Who do you contact? Do you send a detailed description or even source code to someone you don't even know? Remember, in this scenario, you probably haven't even published your work so if they chose to they could claim it as their own and you, an unknown outsider, wouldn't stand a chance of convincing anyone of the truth. Of course they could simply tell you your idea is rubbish because they genuinely think it is, or even because they think it could undermine their own cherished ideas. I know it sounds a very dark picture to paint but history is full of stories of people being fleeced, even Walt Disney got ripped off before he created Mickey Mouse.

Innovation and the right to innovate do not just belong in the hands of the rich and powerful. It is no good pretending that innovation only occurs in large corporate environments. The beauty of computer programming, particularly in the Java environment, is that pretty well anyone can join in and innovate with minimal resources. The problem is that such individuals are potentially wide open to abuse by anyone with the money to employ a lawyer.

You could point out that even in this hostile environment there have been plenty of successfully exploited innovations and many more will occur. But how many innovations have failed or been lost because of it? Taking the lame view that "it's always been like that" is simply not acceptable it is anti-innovative.

So to conclude:
If the companies that claim to support open source really want open source innovation to continue at all levels, not just in their own pet projects, then they should seriously consider setting up some sort of legal support service to at least give helpful advice to open source projects. An international facility primarily funded by interested corporations with an affordable membership fee for bona fide developers would be a good start.

There is one organization that is along the right lines, namely New York based Software Freedom Law Center
[ http://www.softwarefreedom.org/index.html ]. Perhaps, with sufficient funding, they could form the core of a global facility.

Anybody got any thoughts or suggestions?

Comments containing "sucks" and "go away you boring old fart" will be considered "off topic" and the poster should be "sued for every penny they have", although I have a preference for $100 bills myself.:).

Sorry but there will be a follow up
Part 2: Is a Java interface copyright protected?

To anyone that read this far, thanks for your time.

Happy hacking,
Pete

This work is licensed under a Creative Commons License.