Tuesday November 28, 2006

Farewell After John Kline recently left the company for new ventures, it is now my turn to move on as well. It was a lot of fun to work on Project Semplice.

If you have any questions or comments regarding Project Semplice, please don't hesitate to send them to semplice-public-feedback-AT-sun-DOT-com

Good luck!

Herbert C

Technorati Tags: Project Semplice

Monday October 30, 2006

Project Semplice and ActiveX controls The idea behind Project Semplice is to take existing VB6 applications and run them ontop of the Java platform. One of the caveats was that we said that we would not support any ActiveX controls. The thinking behind this is that ActiveX controls are not very portable and don't run on all the architectures that the Java platform runs on. And then of course there are some security concerns about ActiveX controls.

After looking at some serious, real-world VB application we realized that they are using lots of 3rd party controls. Of course this would mean that people trying to give Project Semplice a try by compiling their existing VB application would fail to make them work. When I try a new product and the first thing I do fails, I am usally very disappointed.

The solution that we have come up with is to supply a simple COM server for Java that would allow connecting to ActiveX controls with Project Semplice applications. That way people can more easily try their existing applications on Project Semplice. Of course the long term goal would still be to replace the ActiveX controls with controls from the Java world, but at least this is an easy way to get started.

Let's look at an example. Say we have a VB6 application and with an ActiveX movie player control on a form. Then we import the application into Netbeans and compile the imported application. First the compiler tries to look on the classpath to resolve any form components found in the project. Otherwise it will generate code for starting the COM server and some adapter classes so that the ActiveX control can be displayed in the Java/Project Semplice form.

When we try to execute the compiled application and we are on a non-Windows platform then the application will start up with a message box warning you that some of the controls are not available on the platform you are running. On the forms of the application there will be a special icon in place of the ActiveX control indicating missing functionalty. When you are running on a Windows platform on the other hand, then the COM server will be started and the application will execute and look just like the original VB6 application. With one difference. We will open a message box warning you that you are about to execute an ActiveX control. This is to alert you that there are some safety concerns about ActiveX (which uses a quite different security model than Java).

Please let us know what you think about this!

Technorati Tags: VB, Visual Basic, Java, Project Semplice

Monday October 09, 2006

Project Semplice - Update Just to show you that we are still working hard on Project Semplice, here is quick status update.

Recently we got another sample application from the original VisualBasic 6 distribution working. The Optimize application is a little benchmark application demonstrating the execution speed of VisualBasic. So far there wasn't really anything you could compare the results against, but now we can run it with Project Semplice and compare it against the original. Lower numbers are better and, as you can see, the results are encouraging. The VB6 application is compiled (not interpreted!), everything else would be unfair, obviously, since the Project Semplice code is compiled by the Java Virtual Machine as well.

First, the original VB6 application screenshot:

And finally, the Project Semplice application screenshot (there is some more UI work needed in our libraries as can easily be seen):

Technorati Tags: VB, Visual Basic, Java, Project Semplice

Sunday July 30, 2006

Java Posse Interview The Java Posse interviewed me recently and has now posted the podcast on their site. They asked me questions about compilers, bringing new programming languages to the Java platform, and of course Project Semplice.

Technorati Tags: VB, Visual Basic, Java, Compilers, Java Posse, Project Semplice

Semplice Feedback Email Address We now have an email address for any feedback you have regarding Project Semplice:

semplice-public-feedback-AT-sun-DOT-com

Even if we don't have time to respond to all emails directly, we are reading all of them and appreciate any comments and suggestions!

Technorati Tags: VB, Visual Basic, Java, Project Semplice

Tuesday May 23, 2006

Project Semplice - Q&A First of all, thank you for all your comments. Here is a little Q&A based on those comments (from the blog and our demos). Please keep in mind that all answers are subject to change without warning as we are in the very early stages of development.

Q: Are you converting VB source files into Java source files?
No. This is a true VB source to class file compiler. It should be possible though to run a decompiler on the generated class files to convert them into Java source code. But you would loose any comments from your source files that way though.

Q: Isn't it a little bit too late for a VB6 compatible project?
According to our information there are still a lot of companies out there with substantial investments in VB6 code. VB6 was a great programming language for non-professional and casual programmers. VB.Net has a much higher learning curve for these programmers.

Q: Do you have plans to support VB.Net?
We are investigating support for VB.Net. We already added some VB.Net inspired language features such as namespaces and imports as well as single inheritance which we use to better interface with Java applications and class libraries. For the VB6 programmer all these new features are optional. You do not have to use them but may choose to whenever you feel comfortable with them.

Full VB.Net support is difficult to do for various reasons. To pick just a selected few: The generics model for VB.Net is similar to that of C++ where a type instantiation results in the creation of a new type at runtime. Java Generics, on the other hand, are about type reuse. The short story is that type information is checked at compile time. Another problem are delegates (or to call them by a simpler name: function pointers) for which there is also no equivalent in the Java world as of now. And of course there is the ever growing CLR.

How important is VB.Net support for you? Do you just want the language or a subset of it? Do you also want CLR support?

Q: Will there be support for Web Applications?
Tor Norbye showed creating a web application at Graham Hamilton's keynote. We are looking into making it really easy to create Web Applications. But we just started working on this. So, sorry, that I can't give anymore details on this currently.

Q: Will you support the 'Edit&Continue' debugging feature?
Yes, we are planning on.

Q: Is this project Open Source?
This is currently being investigated but no decision has been made.

Q: Is there a time scale on availabilty?
Without any promises: We hope to have some early access available by the end of the year and hopefully be finished for next years JavaOne. But as I said earlier, everything is subject to change...

Please continue to send us your comments, questions and suggestions. Thanks and happy programming!

Technorati Tags: VB, Visual Basic, Java, Project Semplice

Friday May 19, 2006

Project Semplice - Visual Basic for the Java Platform Yesterday we - that is Tor Norbye, John "Get a blog" Kline and I - presented our project at JavaOne in session TS-3576 under the deceptively unexciting title "Visual Basic and the Java Platform". Well, it actually is "Visual Basic for the Java Platform"!

We are in the early stages of development for a compiler and tools for writing Visual Basic (VB) programs for the Java Platform. That means we will compile VB source code into Java class files that will run on the Java Virtual Machine. Even better, you will be able to import existing VB6 applications into any of the Netbeans family of tools and continue to work on them. Of course I must add a word of caution at this point. If your existing VB6 application contains any calls to the Windows 32 API, we will not be able to emulate all these entry points. We will also not be able to handle any OCX controls that you don't have the sources for. That said, let me show you some of the stuff we demoed yesterday in our session. The slides of the session are also available on the JavaOne website.

Importing and Maintaining an Existing VB6 Application
Our first demo was to import one of the sample applications that comes with VB. We imported the Calculator project, compiled and ran it. Next we made a modification to the Calculator by changing the 'X' character on the button for the multiplication operator to the '*' character. This also required a modification to the source code as well because it checks for 'X' and now needed to check for '*'. We then recompiled and ran the Calculator again and voila, we could use '*' as the multiplication operator!

Creating an new VB Application from Scratch
The next demo was to write a Celsius to Fahrenheit temperature conversion application from scratch. We used the Netbeans GUI builder to create the form and then added an event handler for the conversion button. In the event handler, we take the contents of the Celsius textbox, apply the conversion formula and output the result into the Fahrenheit label. Note that in Basic you do not need to worry about type conversions as you need to in Java. Note also that we are taking advantage of default properties in this example.

Creating an new VB Application that interfaces with a Java Class
An important thing for us is to allow VB programmers access to the all the existing Java Beans and libraries. Therefore, we wrote a VB application that called a Java class for our next example. The application finds all prime numbers in the range from 1 to 8192 using the Sieve algorithm by Eratosthenes. The application has a UI written in VB from which we can call the Java version of the algorithm as well as a VB version of the same algorithm. Note that the runtime of the Java version is slightly faster because the VB version uses non-zero-based arrays, which causes a slight overhead at execution time. We will try to make some improvements here in the future. Disregarding the aforementioned non-zero-based arrays, the performance for VB compiled and Java compiled applications is very similar.

Calling VB Classes from a Java Application
In the previous example, we showed how to call into Java classes from a VB application. In the next example, we will call a VB class from a Java application. We will take the Sieve algorithm again, except this time we are writing a Java UI and call the Java version and the VB version from there. Also this time we are going to deploy the application to the SavaJe Jasper S20 cell phone. Yes, that means that VB is running on a cell phone! Note again that the VB version of the algorithm is slower because of non-zero-based arrays.

A Fractal Application
For our last demo we downloaded a VB application that computes a fractal (similar to the famous Mandelbrot fractal). We also obtained a version of the example that was compiled into native code with the VB6 compiler. As you can see in the screenshot (the upper left corner of the fractal shows a label with the time it took to compute the fractal), the Java version performs significantly better than the natively compiled original. Be aware though that a performance of this magnitude cannot be expected for all applications.

What's next?
We would like to hear from you! Is this a project that you could use, either yourself or in your company? Do you prefer VB6 or VB.Net? Are there any extensions to the VB language you would like to see?

Looking forward to your comments and happy programming!

Technorati Tags: VB, Visual Basic, Java, JavaOne, Project Semplice

Monday May 15, 2006

My JavaOne Top 10 Restaurant List On the eve of JavaOne, when everybody publishes their session recommendation list, I decided to instead publish a restaurant recommendation list.

10. Johnny Rockets
I know it's a chain, but I like the milk shakes and the free nickels for the music.

9. Fog City Diner
Must see San Francisco dining landmark.

8. 21st Amendment
They serve tasty bar food and brew their own beer. What more is there to say?

7. Pancho Villa Taqueria
Cheap and flavorful Mexican food. No dinner jacket required.

6. Market Bar
Have never been disappointed by their consistenly good food.

5. Sam's Grill
Old school (the waiters wear tuxedos); make sure you try the clam chowder.

4. La Suite
I tried a lot of french restaurants in the city and this is my favorite.

3. Oyaji
The owner is known to be a little bit eccentric, but also one of the best sushi chefs.

2. Straits Cafe
Singaporean cusine at its best! They have three locations in the Bay Area, but the original in San Francisco beats the rest.

And my choice for best restaurant in the city:

1. Slanted Door
My favorite dishes at this Vietnamese restaurant: Slanted Door spring rolls, shaking beef, and chocolate pot de crème! It is almost impossible to get a dinner reservation on short notice. The trick is to go for a late lunch...

One of the following days I am going to write a little bit more about the project Tor Norbye, John Kline and I have been working on for the last months. We will have a very short demo in Graham Hamilton's keynote and then on Thursday a technical session during which we will have some more extensive demos. So, mark your calendar for session TS-3576 "Visual Basic and the Java™ Platform" on Thursday, May 18th from 9:45am to 10:45am in the North Meeting Rooms 121/122. It is going to be very cool (much better than the title suggests)!

Posted by herbertc ( May 15 2006, 10:10:00 PM PDT ) Permalink Comments [1]

Tuesday March 14, 2006

Programming Accidents (aka Bugs) - Revisited In my previous blog I was describing a bug I ran into, that was caused by me forgetting to pass a parameter on to a superclass constructor. This could have been avoided if the Java compiler would have warned me that I had never used the parameter passed to the subclass constructor. But unfortunately javac doesn't support this kind of warning (at least yet).

Meanwhile I found a plugin for NetBeans named PMD for NetBeans. PMD (short for ... well nobody really seems to know what PMD stands for) is a tool that scans for potential problems in Java source files. It is highly configurable, which is a good thing, because some of the rules used to identify potential problems might be controversial to some people, but not to others. It is even possible to write your own rules. Anyway, I installed it, configured it for my own needs, and I am pretty happy with it.

You should give it a try too. Worst thing that can happen is that you find some potential problems in your sources.

Happy programming!

Posted by herbertc ( Mar 14 2006, 08:45:00 AM PST ) Permalink Comments [0]

Sunday March 05, 2006

Programming Accidents (aka Bugs) I remember reading a magazine for private pilots a couple of years ago and there was a column analyzing accidents. The idea was to learn from the mistakes other pilots had made and ultimately help the readers to become better, safer pilots themselves.

In the undoubtedly error prone programming business, bugs are all too often just fixed and then forgotten. Rarely is any time spent on reflecting about what caused them and sharing any of the experiences with other programmers. But that is going to change today as I will share the following programming accident that happened to me last week.

I started out with a program that looked roughly like this:

class A extends B
{
    A(int...aarr)
    {
    }

    public static void main(String args[])
    {
        A a = new A(1, 2, 3, 4, 5);
        a.print();
    }
}

class B
{
    int array[];

    B(int...barr)
    {
        array = barr;
    }

    void print()
    {
        for (int i : array)
        System.out.println(i);
    }
}

The source compiled fine and when running it, I expected it to print the numbers 1 through 5, but of course, nothing was printed at all. The program didn't crash either; it just didn't print any numbers. After a little bit of debugging I saw that the content of a.array was an array of length 0 rather than the array of length 5 that I was expecting. So what happened? Where did my numbers disappear to?

When a Java compiler generates bytecode for a method with a variable length parameter list (as in the constructor for A) it actually creates an array of the formal argument type and with the number of actual arguments and copies the actual arguments into that array. If there are no actual arguments passed for the variable length parameter list, the compiler generates an array of length zero. That means variable length parameter lists are nothing but some compiler magic allocating arrays, filling them with the actual arguments and passing those arrays in place of individual arguments.

In the above example the array arrived at the constructor of A but was never passed on to the constructor of B because I forgot to add an explicit "super(aarr)" call at the beginning of the constructor. But since the superclass constructor for B also accepts a variable length parameter list, the compiler silently assumed that I meant to write just "super()", which the compiler inserts for you if there is no explicit call to the superclass constructor. But "super()" can be interpreted as a call to a superclass constructor with a variable length parameter list, which is what the compiler did. It created a zero length array for the variable length parameter list, which was then assigned to the array field of B in its constructor. And that's why my program didn't work. Before Java added variable length parameter lists to its language, the compiler would have raised an error because it would not have been able to find a matching constructor.

Could it be that this is a bug in the compiler? Let's take a look at the the Java Language Specification. Its 3rd edition says in §8.8.7, "If a constructor body does not begin with an explicit constructor invocation and the constructor being declared is not part of the primordial class Object, then the constructor body is implicitly assumed by the compiler to begin with a superclass constructor invocation “super();”, an invocation of the constructor of its direct superclass that takes no arguments." Well, the constructor B(int...barr) is a superclass constructor taking zero or more arguments. Therefore the compiler is behaving correctly.

It remains to be asked, how can this pitfall be avoided in the future? I haven't really found a great solution except to be careful when defining a constructor that takes no other parameters except a variable length parameter list.

Happy programming!

Posted by herbertc ( Mar 05 2006, 10:15:00 PM PST ) Permalink Comments [0]