Sunday, 30 November 2008

I still have a problem with the DLR

Microsoft's Dynamic Language Runtime shipped its first Beta a few days ago. For those who don't know, the DLR is Microsoft's effort to bring support for Dynamic Languages on top of the .NET Virtual Machine. Catch it ? Dynamic Languages are the rage today, and .NET and Java now want to catch the trend on their respective VMs. The DLR initially lived in the IronPython codebase (IronPython is the .NET implementation of Python), but it now seems to live on its own.

I expressed some concerns about the state of the ongoing work for the DLR some time ago, and some people from the DLR team tried to answer. These concerns were (in short):

  • A lot of hard coded references to IronPython and IronRuby, the currently two Microsoft project heavily leveraging the DLR

  • Compilation directives looking for Silverlight everywhere in the code

In short, my concern was that the DLR may be too tied to Microsoft implementations specificities, and not really language / or implementation agnostic. I know this is not what Microsoft folks want, but all this just adds complex interwoven ties between parts of Microsoft's offerings that should never meet explicitly ;-). People already encounter repeated problems when trying to build IronRuby under Mono, this can only make it worse.

And sadly, when looking through the code, I saw as many Silverlight directives as before. And now, some new LINQ references that were not there before. My problem is not that there are dependencies, it's the fact that they seem to be everywhere in the code. I would greatly prefer to see them limited to a specific module in the code, and I'm worried about these new LINQ dependencies. Plus why compilation directives ? Why is it not possible to limit Silverlight specificities to a separated assembly (preferably implementing an interface with a default implementation), and link to this assembly at runtime ? And why Silverlight is so different from the core .NET runtime ?

Update 6/12/2008: Since Bill Chiles comment, I downloaded the code (before I just browsed in the codebase through the web access), and here is what I discovered:

  • 139 files with ifdefs for SILVERLIGHT in the code (that makes roughly 25% of the files), mostly in the Core package (71 files in Core and its subpackages), but widespreaded in the codebase.

  • 4 files referencing IronRuby, and 12 referencing IronPython !!! Again these are not limited to a particular package in the code, and I really wonder why there are more references to IronPython than IronRuby. In short, I don't know how anybody would be able to use the DLR for a new scripting language without changing the core DLR code

  • 302 files using Linq specific libraries and/or functions.

I'm sorry to say that it does not look to me as a well-designed code IMHO (for the moment). I would very much like to see:

  • ALL specific references to IronRuby and IronPython removed.

  • If it's not possible to avoid ifdefs for SILVERLIGHT (I hate ifdefs in general) at all, then limit them to a specific package in the code, and access these by a neutral interface

  • I really don't think that the idea to put Linq there was very good to begin with, but at least I would prefer to see Linq references limited to a Linq-specific package

Update 2 (7/12/2008): About references to IronRuby and IronPython, I maybe was a tad too fast to criticize (I still stick to my previous point with Silverlight references). There's only one file with a real hard reference to IronPython, IronRuby, and JScript. I really don't know why the PlatformAdaptationLayer class needs to explicitly add assembly mappings for these implementations. Why not leaving it to each implementation to add its own mappings ? How a new scripting language will be able to add its own mappings without changing the PlatformAdaptationLayer code ?
But there's still a lot of comments about IronPython in the code, which makes me think that some of the DLR code is still tied to this implementation. However, this should improve in the future. Except that... I now saw another file with an explicit new compilation directive (argghhh !!) referencing IRONPYTHON_WINDOW. That looks bad to me.
And to show my point about the SILVERLIGHT references, let's use one simple example, again in the PlatformAdaptationLayer class. The code is:

public virtual bool DirectoryExists(string path) {
return Directory.Exists(path);
throw new NotImplementedException();

OK I think its because Silverlight impose limitations on access to the File system (sandboxing), so you may not access directories at will. I have no problem with that limitation, but... It would have been very easy to access to a platform-specific assembly here, instead of using these dreadful compilation directives. The Windows platform assembly would simply return Directory.Exists(path), the Silverlight assembly would return the NotImplementedException. This would have been way better IMHO.

Saturday, 8 November 2008

Web 2.0 taken hostage

I tried today to access the .NET 4.0 (Dublin) roadmap on Microsoft website. Unfortunately, you need to have a Word Office 2007 compliant reader to be able to even read this.

Want to access some (maybe) cool content on websites ? Be sure you have the last Silverlight plugin available. But for the moment it will not work on Linux, because Moonlight is still a work in progress.

Aren't you concerned by the fact that an increasingly number of Web sites use proprietary technology for their rendering ? Some time ago we only had to bother about Flash, but it was almost OK, we only had to download one plugin. Now it seems that every big Web 2.0 contender is trying to tie people to their own technology.

Web 2.0 is in danger of breaking in a myriad of little pieces. What is going on now is contrary to what made the web ubiquitous. I'm really looking forward to HTML 5, jitted Javascript and canvas rendering on HTML pages. I really want this to kill both Flash and Silverlight, else I don't know where we are heading.

Sunday, 2 November 2008

new XUL on Java project

Remember this June post about using XUL, Javascript, and Beanshell in a ARINC 661 Client-Server framework ?
Well it occurred to me that the XUL / Javascript / Beanshell part of this was not specific to ARINC661 and could be useful to others as well.
Also if you look in the wild you will only find two Java XUL frameworks:

  • A Java project called jXUL had exactly this goal, but it seemed that its development stalled very quickly in 2001, while still in Beta or even Alpha stage (no activity since then)

  • Luxor is huge and complex, and also has no activities since some years

So why not sharing some code, being able to use XUL "out of the box" in Java can be useful, and even cool ;-)

So let me introduce my new project: javaXUL.

javaXUL is not intended to compete with much more complete RIA offerings, such as Flash, Silverlight or javaFX. Instead it tries to leverage the expressivity of XUL in the java developement area. Compatibility with Mozilla XUL (such as the Firefox implementation) is a goal, but ease to use in the Java world is also one.
The goal of version 0.1 (underway) is to be able to use javaXUL "out of the box" to add user-defined UIs on Java projects:

  • import existing sources and make them compile

  • make them work on simple use cases

  • add simple examples

  • allow setting of Look and Feel

  • ability to add other script engines than Javascript

And now, Just a simple example for your pleasure:

Lets look at the code for this example (its available in the javaXUL website):

import java.awt.BorderLayout;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTabbedPane;
import org.xul.script.scripts.AbstractScriptContext.JSFunctionBinding;
import org.xul.script.scripts.ScriptListener;
import org.xul.script.xul.DefaultScriptManager ;
import org.xul.script.xul.model.XULDocument;

public class BasicXULSample extends JFrame {
private JTabbedPane pane = new JTabbedPane();
private XULListener listener = new XULListener();

public BasicXULSample() {
super("Basic XUL Sample");
this.setLayout(new BorderLayout());
this.setSize(500, 500);

private URL getResource(String name) {
return Thread.currentThread().getContextClassLoader().getResource(name);

private void init() {
DefaultScriptManager manager = new DefaultScriptManager ();
manager.setLookAndFeel(new WindowsLookAndFeel());
try {
URL boxes = getResource("org/xul/samples/resources/boxes.xul");
XULDocument boxesdoc = manager.addXULScript(boxes.toString(), boxes);
JComponent boxescomp = boxesdoc.getRootComponent();
if (boxescomp != null) {
pane.addTab(boxesdoc.getFile().getName(), new JScrollPane(boxescomp));
URL test = getResource("org/xul/samples/resources/test.xul");
XULDocument testdoc = manager.addXULScript(test.toString(), test);
JComponent testcomp = testdoc.getRootComponent();
if (testcomp != null) {
pane.addTab(testdoc.getFile().getName(), new JScrollPane(testcomp));
URL buttons = getResource("org/xul/samples/resources/buttons.xul");
XULDocument buttonsdoc = manager.addXULScript(buttons.toString(), buttons);
JComponent buttonscomp = buttonsdoc.getRootComponent();
if (buttonscomp != null) {
pane.addTab(buttonsdoc.getFile().getName(), new JScrollPane(buttonscomp));
} catch (Exception ex) {

public static final void main(String[] args) {
BasicXULSample sample = new BasicXULSample();
private class XULListener implements ScriptListener {
public void print(String message) {
public void setCurrentJSScript(JSFunctionBinding binding) {
public void showException(String message, Exception e) {
public void showException(Exception e) {

All you have to do is:

  • Create a Scriptmanager (the library provide a ready-to-use DefaultScriptManager implementation)

  • provide a ScriptListener which will be fired for actions on the javaScript side (for now, it is very very basic, I agree)

  • Add various XUL Scripts for this manager, and grab the corresponding components:

    URL test = ...;
    XULDocument testdoc = manager.addXULScript(test.toString(), test);
    JComponent testcomp = testdoc.getRootComponent();

You can already grab the code and make it work. a LOT of things need to be done on it of course, but I think it can already be useful. As soon as the ability to add other script engines than Javascript has been added I will post a first 0.1 version. For now, consider it a Beta ;-)

Sunday, 26 October 2008

On Eclipse versus Netbeans

It's amazing how Eclipse has gained so much momentum that people don't even try to look on Netbeans to see if their need could not be fulfilled by this other IDE. OK I am a longtime Netbeans user, but my (recent) experiences with Eclipse were not good ones:

  • having the right install and dependencies for a particular plugin is very very often a nightmare. Believe me, it never works out of the box, even with commercial plugins

  • I really don't like the perspective stuff, it is surely a good idea, because you think that you will only have what you need for your current task, but at the end this forever changing environment is really disturbing. And having the IDE saying that "you must change your perspective" is something that is the contrary of a user-friendly experience

  • Eclipse UI is bloated and not homogeneous. I don't count the times when I had to search for a particular basic thing, and discover that it was hidden deep somewhere in the configuration options

  • Some things that are done very well and "out of the box" by Netbeans are complex with Eclipse: UI development (no good UI designer in Eclipse), Jar creation and ant configuration (I was amazed to discover how it was complex to simply create a jar with a main class attribute on the version of Eclipse I used, and you have nothing to do to make it work with Netbeans, it is working out of the box)

  • Some cryptic bugs in Eclipse with the projects, that can be very very annoying, especially considering that they don't disappear when you restart. I never had these in Netbeans

But the problem is that people like Eclipse, just because they never look at Netbeans and they think that the problems of Eclipse are just a downside of all What Eclipse can offer to them. It reminds me of the dreaded "Start" button of Windows. In more than one cases, I discussed with people who wanted to begin development with Java in my company, they had a pre-installed version of Eclipse on their PC, and as they asked me, I stated the differences between these two IDEs (it is very easy to work with Netbeans even with copying the installation directory anywhere). They often choose to work with Eclipse (because of the buzz, I think), so they never choose. And they are happy, because they know nothing else, and think that their problems can't be avoided. And in the end, I often had to help them with their Eclipse problems...

Update: And The Visual Editor only works with Eclipse 3.2 (Callisto), it has not been updated since then. Eclipse is now 3.4 !!! Want to do easy Java UI development ? Use Netbeans or buy MyEclipse. Beware that if you want the UI designer (code copied from Netbeans, so don't expect it to be bleeding edge stuff), you have to throw 60$ a year for the professional edition. Netbeans UI designer is bleeding edge and is free.

Saturday, 27 September 2008

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.

Saturday, 30 August 2008

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 ?

Thursday, 19 June 2008

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.

Sunday, 8 June 2008

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.

Sunday, 4 May 2008

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.

Saturday, 9 February 2008

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.

Saturday, 19 January 2008

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...