Jabaco - Java VB6 clone

Has anyone else looked at Jabaco (rhymes with "tobacco") yet?

It is in what looks like a fairly early beta stage. Nowhere near as clownish looking as REALBasic but also a thousand miles further behind in fit and finish. For one thing there is ZERO documentation as I write this.

Considering it appears to be a one- (to maybe three-) man show this should not come as a surprise.

In some ways it seems to be a remarkably good VB6 imposter. In others it falls flat. Some of this is the long way its IDE has to go in terms of basic amenities we've come to depend on in VB6. Another is the curse of Java frameworks in general. By default it uses Swing, but you can rework the Jabaco Framework to use alternatives if you're very ambitious.


Depending on the sort of programming you do in VB6 you'll either find Jabaco easy to port to or incredibly difficult. Many standard things carry over easily, other basic things must be done entirely differently.

Quote:

---

A better replacement by keeping the spirit of VB6 in the development process. Making it useable for experienced VB6 users.

---

So they say, but for anything but Hello World in a Form programs I think you'll find Jabaco at least as nastily different as VB.Net.

It does free VB6 programmers of the Great Treason of Redmond to some extent, since the code can be ported to many Java-supported OSs. As far as I can tell you still have to develop on Windows though.

We'll see once Jabaco matures a bit how well the community treats it.


Simple Program

Code:

---

Public Sub Form_Load()
  Dim fItems As VBFileHandler
 
  fItems = open(App.Path & "\stuff.txt", Input)
'  Do Until EOF(fItems)              'Goofy EOF syntax 1.
  Do Until fItems.EOF                'Goofy EOF syntax 2.
'    List1.AddItem readLine(fItems)  'Goofy read syntax 1.
      List1.AddItem fItems.readLine  'Goofy read syntax 2.
  Loop
'  Close fItems                      'Goofy close syntax 1.
  fItems.close                      'Goofy close syntax 2.
End Sub

Public Sub Form_Resize()
  If Me.WindowState <> vbMinimized Then
      List1.Top = 0
      List1.Left = 0
      List1.Height = Me.ScaleHeight
      List1.Width = Me.ScaleWidth
  End If
End Sub

---

One Form, with one ListBox. Start up and read lines of a text file into the ListBox. Resize the ListBox to fill the Form.

Even here we see the seams showing.

No With... End With yet. Controls have no Move() method.

Funky Java-esque I/O: both inside-out and outside-in syntaxes. These are a common curse in Java and related worlds with overweight frameworks, such as .Net.

However more extensive examples doing a lot more work seem to show much better performance than VB.Net, so that's a plus.


Who can say? A VB and Java guy might love it.

Interesting.

About 99% of the value in VB6 is in the way it gives you access to COM and standard libraries, many of them system libraries. This can make it very clumsy to convert a non-trivial VB6 program. Even controls that are part of the VB6 Extended Runtime and others that ship as part of the VB6 package don't always translate well. There is a capability to import VB6 projects though, and it is no worse than VB.Net's.

Of course using anything OS-specific in Jabaco almost misses the point, which is largely portability to Java-supporting OSs. This makes it a little more than just a VB6 alternative, in much the same way as REALBasic.


As with porting VB6 to VB.Net or anything else, there are little things that may make you chase your tail a bit until you find them. Then you have to come up with some sort of workaround. For example:

Code:

---

strLine = "ABC,XYZ"
strArray = Split(strLine, ",")

---

This pretty much does what you'd expect, resulting in a String array with 2 elements. However:

Code:

---

strLine = "ABC,"
strArray = Split(strLine, ",")

---

That does not do what you'd expect. You get back a String array, but with one element, not two with the second one = "". Quick hack (but unpleasant):

Code:

---

strLine = "ABC,"
strArray = Split(strLine, ",")
If Right$(strLine, 1) = "," Then
    Redim Preserve strArray(UBound(strArray) + 1)
End If

---

Bleh!

Bug? Or Java "feature" spilling over into Jabaco? If a bug, will it be fixed later, thus breaking all of your Jabaco where you've hacked around the issue?

Perhaps you'd want to tag all such code just in case, for easy tracking and changing later:

Code:

---

strLine = "ABC,"
strArray = Split(strLine, ",")
If Right$(strLine, 1) = "," Then '@@HACK:SPLIT@@
    Redim Preserve strArray(UBound(strArray) + 1)
End If

---

As I mentioned in the earlier post, there is no documentation right now at all. However there is a crude sort of "object browser" like thingy based on Java reflection as far as I can tell. Nowhere near as good as we're used to though and Enums don't seem to show up at all. Properties, methods, events - all show up as just Sub or Function signatures.

Setting control tab order in a Form seems to be a black art. It seems to roughly follow the order in which you added controls to your Form. But not quite. Carefully stripping all controls and then adding them back in order came close but the tab order that resulted seemed to want to move left to right then top to bottom. After tabbing past the last control it doesn't start back at the top, but seems to go into limbo.

The SetFocus method seems to be erratic (or broken, i.e. no-operation) for runs in the IDE, but better (seems to work) in compiled code.


Who can say whether (or when, or if) any of this will be changed later. But as they say "the amazing thing about a dancing bear is not how well it dances, but that it dances at all." Impressive work considering the small team involved.

Jabaco would be just great if it produced standalone (native) executables. The only reason why I will never switch to .NET is its framework and Jabaco does not solve this problem, as it also relies on a virtual machine.

I agree that this is its major downfall. However its goal is to offer "VB in Java" so that leaves native code out as a possibility.

It also "compiles to" a fairly large EXE. Its JAR output might be smaller, not having the Java boorstrap code included. It can also make browser applets, though without code signing a VB6 ActiveX Control is almost as portable - the advantage with a Jabaco applet is support on more browsers and OSs.

The only thing I can really say in Jabaco's favor is that Java VMs are more widely deployed (even to Windows systems) than .Net's are.

I have been avaluating different migration paths for my VB code and so far there is no solution that delivers 100% compatibility. I dont know what my final choise will be but so far i like Jabaco.

When it comes to bytecode vs Native code there are many tools that can compile bytecode to executables. One of the more popular is Excelsior (http://www.excelsior-usa.com/). They also have an free installer for Windows. I dont know if it really gives a speed advantage, modern JIT-engines are quite fast. However it could be useful for building neat installers...

Of course there are drawbacks with Jabaco. It is still in Beta and does not support all VB functionality.

One of the most important issues is that it does not support COM like VB does. However COM can be used trough the COM support in Java. Also all Java classes and libraries can be used so finding substitutes for your COM objects is possible.

The main porblem is that it does not support ADO and other old database technology. It has its own DataBase class that has a neat funcion to connect to MDB databases. This is actually built on top of JDBC, and one can use JDBC classes instead of those provided by Jabaco.

The old COM-based database support in VB Classic is among the things being EOL:ed by Microsoft. One should keep that in mind that sticking to adodb is a dead end. So porting to another database enging is required no matter what migration path you chose. At least JDBC is the dominating engine and is not likely to get EOL:ed in the near future.

As Jabaco is implemented on top of Java one could use libraries like Hibernate to do database programming easy. However, as far as i know Hibernate cant be used directly within Jabaco. Instead you would have to create Java classes and use them as references.

Why not just use Java?
When porting a VB application the answer is obvious. Also the VB-like GUI editor is unlike anything that i have ever seen in a Java IDE. Jabaco is also quite small compared to monsters like eclipse and netbeans. Its use more memory then old VB but far less then any other IDE i tried.

What do i want in Jabaco?
There is a lot i miss from VB. I am not sure i want all of it. For exemple i prefer to make multi-platform apps and COM would mess that up.
As Jabaco run on top of Java i think i would like to see more Java integration. The database code that have to be rewritten anyway could be written as Java classes and make use of Hibernate and other Java stuff.
Of course i also want more from the framework and the GUI, but this is growing and maturing for every release so i think making it an issue would be overkill.

Also note that i have just been using Jabaco for a day, exept for playing with it for ten minutes months ago... I may have other opinions next month... :)

Jabaco is still somewhat interesting to me. I don't have a use for rooting through the Java ecosystem to accomplish important things though, and would prefer a native Windows alternative to VB6 someday.

Concern over ADO is misplaced in my opinion. It will be around as long as a VB6 program can still run. Eschewing COM strikes me as odd as well. COM is native to Windows, unlike .Net which is as foreign to Windows as Java is.

The quality shown in the Jabaco beta versions makes it obvious Microsoft had no excuse for dropping the classic VB line of development tools. I've read lots of excuses from that quarter about how difficult the existing IDE and compiler were to support and carry forward into the future. Clearly that is sheer FUD from the forces holding Microsoft's development tools group in thrall today. They're still trying hard to shoehorn .Net into Office programs as a VBA replacement.

Quote:

---

Originally Posted by dilettante

Jabaco is still somewhat interesting to me. I don't have a use for rooting through the Java ecosystem to accomplish important things though, and would prefer a native Windows alternative to VB6 someday.

Concern over ADO is misplaced in my opinion. It will be around as long as a VB6 program can still run. Eschewing COM strikes me as odd as well. COM is native to Windows, unlike .Net which is as foreign to Windows as Java is.

The quality shown in the Jabaco beta versions makes it obvious Microsoft had no excuse for dropping the classic VB line of development tools. I've read lots of excuses from that quarter about how difficult the existing IDE and compiler were to support and carry forward into the future. Clearly that is sheer FUD from the forces holding Microsoft's development tools group in thrall today. They're still trying hard to shoehorn .Net into Office programs as a VBA replacement.

---

The forces holding Ms development tools is Microsoft management. That is forces that are not likely to go away. I see .Net as parallell to the Windows API. ITs not at all that foreign. I do not really se a need of sticking to the WinAPI when there are good frameworks that wraps it neatly, and works on other platforms. I really like the fact that Jabaco applications can run on other operating systems.

ADO like all other microsoft API:s is subjet to Microsofts whims. I rather rely on fact then on whats likely. The fact is that there are several independent java environments, including the java to native compiler i talked about above. Java and JDBC is notorious for being backward compatible even in cases where it would be better to break compatibility. While i am used to using ADO and COM, i am personally going to migrate now so i dont have to do it later. At least for all new code.

Also it should be noted that COM and ADO is possible in Java and Jabaco. There are info about it on jabacos forum. It is also fully possible that Jabaco classes that are compatible with the old VB ADO classes will be written, using this.

Personally i dont think there will be a native Windows alternetive to VB. Most languages written to day are for Java or .NET, because its easy to write compilers for those... and realbasic is written for *nix and ported to Windows. It does not use the Windows API directly.

I have been playing around a bit more with Jabaco now. Jabaco programs consume a bit more memory from the start, but on the other hand they are a lot faster then VB programs. Also i have found several bugs in the classes and had them patched upstream, so the feedback process is really fast. Language bugs that i found havnt been patched jet but its understandable that such changes takes more time. I remember when i tried to report the variant property bug to Microsoft...

But I think you're going to find yourself frustrated with Jabaco sooner than later.

It is a nice idea, but it will always be a second or third-class citizen in the Java ecosystem. It may be nice for some learning, teaching, introductory programming scenarios but I don't think it will ever be used much for anything but that and recreational programming. I don't mean it lacks potential, it just has an uphill journey to gaining any real acceptance.

Java guys want to write Java. .Net guys want to write C#. VB.Net guys are already pretty marginalized in the market.

Have you figured out yet how you would even package a Jabaco program to deploy it as freeware? What tools are there to help you bundle up a JVM and the necessary Jabaco libraries to let somebody run your program on a computer that doesn't have Jabaco installed for development?

Quote:

---

Originally Posted by dilettante

But I think you're going to find yourself frustrated with Jabaco sooner than later.

It is a nice idea, but it will always be a second or third-class citizen in the Java ecosystem. It may be nice for some learning, teaching, introductory programming scenarios but I don't think it will ever be used much for anything but that and recreational programming. I don't mean it lacks potential, it just has an uphill journey to gaining any real acceptance.

---

I think there still is room for VB even in the Java world. First of all there is room for a language that makes it possible to port old VB apps without rewriting them in Java. Secondly VB is still superior for RAD development of GUI:s.
I dont think VB or any BASIC language will have the position it once had. That would be foolish. But i still think its room for it. There is a lot of former VB developers in the community and one should never underestimate nostalgia...

Quote:

---

Originally Posted by dilettante

Java guys want to write Java. .Net guys want to write C#. VB.Net guys are already pretty marginalized in the market.

---

One does not have to stick to one language for everyting. VB and Jabaco is very good for greating GUI:s and Jabaco Framework neatly wraps Swing in a way that makes it easier to work with -> faster development.
Yeah i know VB is our of fashion. But i dont think this basic dialect is dead quite yet. Yes Java dominate the market and C# has almost all shares thats left, but i still think that there is room for a IDE like Jabaco

Quote:

---

Originally Posted by dilettante

Have you figured out yet how you would even package a Jabaco program to deploy it as freeware? What tools are there to help you bundle up a JVM and the necessary Jabaco libraries to let somebody run your program on a computer that doesn't have Jabaco installed for development?

---

Jabaco Framework and code for it is compiled to Java classes, and can be handled with the usual Java tools. One of them is Excelsior (http://www.excelsior-usa.com/) mentioned in my previous post.

Well I appluad the effort anyway, and I hope others take the time to give the Beta a test drive. Jabaco may be exactly what some people are looking for, and with time and continued development may answer the needs of even more people.

I wonder what the final product is expected to cost?

Quote:

---

Originally Posted by dilettante

Well I appluad the effort anyway, and I hope others take the time to give the Beta a test drive. Jabaco may be exactly what some people are looking for, and with time and continued development may answer the needs of even more people.

I wonder what the final product is expected to cost?

---

Jabaco is two projects. The implementation of VB classes called the Jabaco Framework is open source, and the compiler and IDE that is closed source. I think that if it becomes to expensive there will be other compilers and IDE:s that can make use of the Framework. I think that an OSS compiler and IDE would be what we need to boost the project and take it out of beta.

VB still has a place but we need tools. While i commit some time to Jabaco Framework my main development is done in Java. Most of the old VB developers have migrated to Java, C# or C++ already.

However i still see the need for a RAD tool like VB. None of the other languages mentioned above is really a good replacement when it comes to making forms and db-driven apps with a minimal amount of code. Also VB was a great language for beginners who wanted to learn programming. Basic has always been a great tool for introduction to programming classes, and still is.