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.

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 com.sun.java.swing.plaf.windows.WindowsLookAndFeel;
import java.awt.BorderLayout;
import java.net.URL;
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.add(pane);
        this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        init();
        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());
        manager.setScriptListener(listener);
        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));
            }
            manager.setActive(true);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    public static final void main(String[] args) {
        BasicXULSample sample = new BasicXULSample();
        sample.setVisible(true);
    }
    private class XULListener implements ScriptListener {
        public void print(String message) {
            System.out.println(message);
        }
        public void setCurrentJSScript(JSFunctionBinding binding) {
        }
        public void showException(String message, Exception e) {
            e.printStackTrace();
        }
        public void showException(Exception e) {
            e.printStackTrace();
        }        
    }
}

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 ;-)

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.

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.