Type erasure and autoboxing in Java

I'm using Java 5 (and 6) for some time now, and I don't really understand all this hatred about type erasure and autoboxing in Java. But I really think that the Java guys were right at the end:

Generics can be easy to use, but they are never easy to implement at the library level for programmers. I don't think that they are really useful for VM languages, except for type safety. I agree that C++ STL could not have been implemented easily (or at least in a manner that would allow to use them easily) without templates, but templates are hard to understand when you need to develop libraries using them.

So for me I'm using Java generic a lot, but as a user of the collections library (which is the main area were they are useful IMHO, and in every language), and I'm perfectly OK with that. When using generics like that, they are very easy to understand. See this example:

public Map<String, String> getMap() {
...
}

It is a really cool here to know what is returned by the method, and also to be sure that types mistakes on the content of the Map will be detected at compile time.

Page Up and Page Down patent

Microsoft has just been granted a U.S. patent for "a method and system in a document viewer for scrolling a substantially exact increment in a document, such as one page, regardless of whether the zoom is such that some, all or one page is currently being viewed", in other words, the "Page Up" and "Page Down" keystrokes !!! (see here). This is another example of where this crazy software patents system can go.

The problem is that these software giants present the patents they filed as valuable assets (maybe products of extensive research and investments) that could be put at risk by others, say for example evil open source advocates or other competitors. But although I don't doubt that some of their patents deal about real inventions, how to separate these from this over-increasing amount of crap ?

Concerns with the Dynamic Language Runtime

the Dynamic Language Runtime is an Open-sourced library developed by Microsoft to bring support for scripting languages on top of the .NET Framework. The code currently live in the IronPython codebase, and it is used by IronPython, the upcoming IronRuby (the Microsoft .NET implementation of Ruby, and it is planned for the upcoming releases of JScript and VB.NET. The first release is announced late 2008.

I browsed the code shipped in the IronRuby repository and I have two concerns about this code:

• Currently there are some hard links in the code to IronPython, IronRuby, and JScript. I think these should be deleted in favor of a more generic approach, to allow any scripting language implementation to take advantage of the DLR.


• There are compilation directives looking for Silverlight everywhere in the code, which I consider shameful, because what is achieved by compiling against Silverlight is not clear. Also having to use two very different runtimes, one for a regular .NET application, and another for Silverlight, is not very good IMHO. It reminds me of the old times of C pragma hell... Also what are the constrainsts for the hosting scripting language implementation ? As Silverlight is not open-sourced or standardized, what will become of the DLR API when Silverlight will change, a thing which will surely happen ?

Of course, the DLR is still under development, and things will evolve and maybe change in the course of time. But it reminds me of the old Microsoft attitude: propose new tools and libraries, with heavy advertising, declare them as open for everyone, and then tweak them heavily for working with Microsoft implementations only (I don't think that this is a conscious attitude)... This is not a problem for now, but it could become one after the first "official" release, when people will start to use it in their own scripting languages.

Have fun with ARINC 661, XUL, Javascript, beanshell, and Java

One of my project is a Client-Server ARINC 661 framework which use a lot of socket-bound activity from the Client (called User Application in the standard, it handles the logic here) to the Server (which perform the graphic rendering).

The communication protocol in ARINC 661 is specific and a bit complex (no SOAP, no REST, no CORBA, not RMI, but purely specific binary messages on top of the lower-level bus-level layer protocol). So to ease development of Java clients, I developed a generic API to handle this.

I thought it could be cool to allow users to prototype the logic of the Client. Using beanshell for this was the logic thing to do (pardon the pun), because it is very close to Java, so transcoding from beanshell to Java is straigthforward.

The second step was to be able to add scripted control panels for the Client. I don't want to recreate the wheel, so I decided for the use of XUL. One cool side-effect is that users would be able to debug their scripts using Firefox.

OK, it's one thing to create control panels in Java by parsing XUL scripts, but if you are not able to wire the widgets commands to the logic, it's no use. I decided for using Javascript (by using Rhino). Then I had to wire beanshell methods to Javascript. It involved a bit of code to be able to do that, but it was possible.

But getting or setting widget attributes at the Javascript level is also mandatory ! With some amount of work (in fact not a lot of work, I only had to use the right approach to do it), it was also possible.

So basically now I have a framework where I can script ARINC 661 logic in beanshell, and wire these scripts to commands in XUL declarative files. I have a purely scripted ARINC 661 Client.

In this process, I found that Rhino is really a very good Javascript engine, but that there is few informations or tutorials when you have to perform specific things like I had to do (hmm, it's no so specific). I will blog about what I discovered about Rhino specificities in some days (there's not much to say about beanshell / Java, it just work, but as it is so close to Java, there's no surprise). I thing it can be useful to others.

New projects ?

It seems I did not blog here for a long time now. This blog is still active, although I blog more often here (hmm, I acknowledge that my musical tastes may be a little specific).
This entry is just a reminder, so I can look at it a few months from now, and look if I made any progress at all...
First I created two open source projects, called:

• MDIFramework, which aim to provide a ready-to-use desktop application infrastructure in Java. I mainly created this project because I always reused the same piece of code in my own work, so I wanted to have a generic library instead. I thought it was better to open source it, so that's what I've done. Seems that there is not a lot of activity in this project for some time, but I have upgraded the code internally, and I will soon upload a lot of code, and bump version to 0.2. I perfectly understand that this project is not very relevant now that the Appframework and the associated JSR have been created, and the relevant code integrated in Netbeans. But I used my own library before this existed, and it is not always easy to switch to another framework. Maybe I will do it in a little while...


• MDIUtilities, which is a utility library with various classes in the swing, IO, geometry, etc... fields. There's tons of other libraries in the open, but it is not always easy when all you want is a small library to provide utility classes. Sometimes you could end-up with tons of different libraries, for which you only use few classes.

And now, for possible new directions:

• A Java port of Povray. There's a problem with the license (Povray began when GPL did not even exist, so it's not really open source for now, even if they will maybe distribute the next version under a GPLv3 license), but at least I may never begin this work, and I still could give it to the Povray team. I would really like to benchmark the Java version against the C reference. Even if I know that the C version will be faster than the Java one, the question is to what extend ?


• Perl on Java, to be able to reuse simple Perl scripts in the Java world. There is already a language called Sleep (in LGPL) which does even more than that, so I think that could be "easy" (just kidding)


• The same thing for C (what, C ?), also using JNA to leverage legacy C libraries. What would be wonderful would be to be able reuse small C programs as scripts (or even compiled code, but here I'm dreaming) in the Java world without even have to bother with compilation options, and also to be able to debug much much much much more easily (dynamic allocation, pointers, etc...). But I'm sure this one would not be an easy one


• Open Dynamic Engine ported to Java. It would be interesting, for example to use it with a Java game engine such as JMonkey Engine (which already is able to do fabulous things)

But for now, I will have to send patches to the Batik Java library (the most conformant SVG library, I think). Patches will be in the area of WMF to SVG conversion.

On Microsoft and Open Source

OK, I'm not really what you can call a Microsoft fan. Not really... But everyday I encounter new evidences that I'm right. What bothers me is that some people have a tendency to take MS marketing "as it is", and it is often not completely accurate, to say the least.

A new example: The Dynamic Language Runtime.
It is an ongoing effort to ease implementation of dynamic languages (like Python, Ruby, ...) on top of the .NET Framework. When you read articles on the web (for example, see here), you are under the impression that it is up and running, but... the code currently lives in the IronPython repository and the developers plan to release the first 1.0 version by the end of the year. I'm not saying that this project is not exciting (hmm, i'm not excited...), but people should wait a little before writing things like Microsoft developers have already been able to build implementations of Python, Ruby, Javascript, and Visual Basic that can run on the DLR, when these are planned for the end of the year (IronPython), currently in the pre-alpha stage (IronRuby), or planned for the future (VBx).

Update February 10: After a discussion with fuzzyman, I feel I need to update this a little. I said that I needed to see successful non-Microsoft projects built on top of DLR to say that DLR have succeeded. He pointed that there were more than Microsoft projects on the go, for example IronLUA, or IronScheme. I must agree that people are expecting a lot from the DLR, and starting to use it in their projects, but neither IronLUA or IronScheme are close to completion yet (which is normal, considering that they still have a lot to do to implement their respective languages, and also that the DLR API is still far from stable).

This is not only a formal discussion for me, because the idea behind the DLR is that it is possible to abstract AST to be able to use them in ANY dynamic language. I am very coutious because this very same assumption was made before with the CLR, which was said to be really language-agnostic, and (contrary to the JVM) could be used to implement ANY language. It turned out that it was no more the case for .NET than for Java (and no less, I agree), and languages built on top of CLR were often slightly different from their reference. So, just one last word for DLR: Wait and see... I can be wrong, but if we go back to the beginning, we are far from saying that it's done.

News news

OK, my PC is repaired now and kick ass (since December). I had to replace the defunct hard drive by new one, in perfect shape, and with 160 GB instead of just 60 for the old malfunctioning one ;-). Plus I added some memory. So this is all right now thanks. Except that I had to reinstall all my apps, and tried to find copies (even old ones) of things I had only on this PC...

As for development news, I will shortly upload the version 0.2 my Application Framework library. OK, maybe you think that it values very little in front of Sun's appframework an you may be true, but I developed this library before we heard of appframework, it helped me to not reinvent the wheel for my own applications every time, and now it would be some work to adapt all my apps to this new framework, even if it is better. However, I will surely do that at the end, but for now I have no reason not to maintain my own library. And that's what is great about Java, you have the liberty to choose amongst several ready-made solutions for any of your needs ;-) Even if you are not interested, you should know that the actual version of this library is working well, I'm using it in approx. 7 to 10 of my own apps... OK, no more advertising.

What I would like to do (in the area of development) for the new year (and probably I will never do) is:

• A Perl interpreter coded in Java, going from the Sleep language


• A POV-Ray port in Java. No need for now to bother about license, because I will probably never have something good or complete enough to be able to C compiler or interpreter coded in Java, would be great to be able to debug C applications with the Java debugger


• A pure-Java port of the Open Dynamics Engine


• A SVG to WMF converter built on top of Batik, the pure-Java SVG library. I have almost something working now, so this one could be done for this year

What interests me in Java ports of big libraries like ODE or POV-Ray, apart from the "because it's fun" reason, is the fact that it should be interesting to have an idea of the performance difference between the original C or C++ app performance and Java ;-)


But as you can see, these are mainly dreams for the new year. Not that it is not possible to do, but because I have a lot of other things to do, and this would involve a lot of work...