For RIFE (web application framework) I'm investigating how to retrieve the local variables of an executing method.

The only portable solution that I could find on the web is Brakes, a portable thread serialization mechanism for Java. After reading through its white papers and sources I found that it instruments the bytecode of the classes in which it should be able to serialize the thread state. It replaces all bytecode instructions with a number of wrapper instructions. These maintain a context object and modify it in parallel with what the bytecode does to the local variable scope. This seems like a terrible waste of resources to me since I don't need to be able to resume at any arbitrary execution frame, I just need to obtain the local variables.

The white papers of Brakes hinted me towards a possible alternative, it says : 'Although code migration and data migration is strongly supported in Java, thread migration is completely not supported ...'. If Java strongly supports data migration, I should be able to retrieve the data I need somehow. Sadly I have little experience with these low-level aspects of Java and its VM and wonder if someone could shed some light on this issue.

Please provide any information that you have about this!

Below are the highlights of this release.

• first version of users guide [ more ]
• further abstracted resource handling [ more ]
• templates can now be stored in a database [ more ]
• authentication and print elements now support non html templates [ more ]
• participants can now be named and support cleanup [ more ]
• support for Hessian web services [ more ]

first version of users guide

The first version of the users guide has been released and can be downloaded from the same location as the RIFE distribution. The online HTML version is available here and the PDF version here.

[ top ]

further abstracted resource handling

Until now resources have always been looked up through the abstracted ResourceFinder interface. However the retrieval and storage of the their content was mostly left to the application code that found the resource.

The handling of resources has now been significantely extended and moved into a dedicated package : com.uwyn.rife.resources. The ResourceWriter interface has been added to provide an abstract way of storing resources.

It's now possible to store and retrieve resources from a database by using the ResourcesDatabase class which implements both the ResourceFinder and ResourceWriter interfaces. The ResourcesDatabase class only needs a Datasource object as its constructor argument and you'll have to call the install() method before using it, for example:

Datasource ds = Datasources.getRepInstance().getDatasource("pgsql");
ResourcesDatabase resources = new ResourcesDatabase(ds);
resources.install();
resources.addResource("file.txt", "some content");

Afterwards, you can provide this resource finder to any class or method that needs it. Currently only templates have been made fully compatibile with pluggable resource finders, but work is underway to do the same for most of the other parts of RIFE.

[ top ]

templates can now be stored in a database

Thanks to the abstracted resource handling, templates can now be stored, modified and retrieved from a database. To make this work you'll have to make sure that the resource structure has been installed in the database through the install() method, as described above.

The only thing that you need to do to make RIFE stop looking up templates through the classpath, is to make the template factory aware of the resource finder that you want to use instead. Since you typically do that for your whole application, this would be commonly done by modifying the globally known template factories through their setResourceFinder() method, for example:

Datasource ds = Datasources.getRepInstance().getDatasource("pgsql");
ResourcesDatabase resources = new ResourcesDatabase(ds);
TemplateFactory.ENGINEHTML.setResourceFinder(resources);

From now on, all engine html templates will be retrieved from your database instead.

It's probably the easiest to do this in a custom participant, for example:

public class ParticipantTemplateFactory extends RepParticipant
{
    private ResourcesDatabase    mResources = null;

    protected void initialize()
    {
        Datasource ds =
            Datasources.getRepInstance().getDatasource("pgsql");
        mResources = new ResourcesDatabase(ds);
        TemplateFactory.ENGINEHTML.setResourceFinder(mResources);
    }

    protected Object _getObject(Object key)
    {
        return mResources;
    }

    protected ArrayList _getObjects(Object key)
    {
        ArrayList objects_list = new ArrayList();
        objects_list.add(mResources);
        return objects_list;
    }
}

Finally, don't forget to add this participant to your participants.xml file.

[ top ]

authentication and print elements now support non html templates

All authentication elements and the PrintTemplate element now support the template_type and template_encoding initparams. By default these use the enginehtml type and your platform's default encoding.

Just add these initparams to your element declarations if you wish to use other values for this.

[ top ]

participants can now be named and support cleanup

When declaring participants in the participants.xml file, it's now possible to add an optional name attribute. This allows you to use several participants of the class by differentiating them through their name. If no name is specified (as before) the class name is used.

Rep's getParticipant method has also been updated accordingly since it now looks up participants by name instead of by class name. Note that this is fully backwards compatible. Also, even though a participant has been registered with a name, it'll still be known under its class name. When a class name is provided as the argument, the first known participant of that class will be returned. This can be seen as the default participant for the specified type.

The repository will now also clean all participants up in the reverse order of their registration. Each participant can optionally overload the cleanup() with the logic that needs to be executed to nicely terminate the participant. The whole cleanup procedure will be called when the virtual machine shuts down, or when the gate servlet or filter is destroyed.

[ top ]

support for Hessian web services

I stumbled into Caucho's Binary Web Service Protocol which seems very nice for communication between internal application parts. It has been integrated into RIFE in a similar way as SOAP with Axis. There is no concept of auto-deployment through jws files though. To declare a Hessian element you just have to do this, for example:

<element extends="rife/webservices/hessian.xml">
    <initparam name="service_class">my.hessian.Basic</initparam>
</element>

With the following java source classes:

package my.hessian;

public interface BasicApi
{
    public String hello();
}

and:

package my.hessian;

public class Basic implements BasicApi
{
    public String hello()
    {
        return "Hello, world";
    }
}

Assuming that your element is registered in the site structure like this:

<site>
    <element id="BASIC" file="my/hessian/basic.xml" url="/basic"/>
</site>

You'll be able to use the web service like this:

String url = "http://localhost:8080/basic";
HessianProxyFactory factory = new HessianProxyFactory();
BasicApi basic = (BasicApi)factory.create(BasicApi.class, url);
System.out.println(basic.hello());

Which will print "Hello, world" to the standard output.

Pretty easy, no?

I like the fact how in Java2D, images are loading asynchronously and you're able to go on with your work until exactly the information that you need is available during the construction of the Image. Most of you probably know how to simply load an image and how to wait until it has arrived before continuing. If not, you'll quickly need it when manipulating images since it's often exactly what you want. There's not much use drawing something that is not yet there, is it? Luckily the JDK has the very handy MediaTracker class that does all the dirty work for you and you can use it like this inside a java.awt.Component:

Image image = getToolkit().getImage(image_resource);
try
{
    MediaTracker tracker = new MediaTracker(this);
    tracker.addImage(image, 0);
    tracker.waitForID(0);
}
catch (Exception e) {}

This works well and is very easy to use. However, what to do when you've got no UI, no java.awt.Component, but are working with the Image in backend code, performing some hidden and invisible wizardry? I found that information about this on the web is lacking and that even the Java2D examples on Sun's website don't explain how to proceed in this case. I went through several versions of the implementation and while they all worked all the time under Linux, threading issues made applications under Windows incredibly unresponsive (taking sometimes 4 minutes to load a simple gif) and even completely stalled the application under MacOSX.

The short answer is that you have to use the ImageObserver interface, it is a required argument when drawing an image or when trying to obtain its dimensions. Here is the simple ImageObserver I came up with for this purpose:

class WaitingImageObserver implements ImageObserver
{
    private Object    mMonitor = null;
    
    WaitingImageObserver(Object monitor)
    {
        mMonitor = monitor;
    }
    
    public boolean imageUpdate(Image image, int info, int x, int y, int width, int height)
    {
        synchronized (mMonitor)
        {
            boolean result = false;
            if (0 == (info & ImageObserver.ALLBITS))
            {
                result = true;
            }
            else
            {
                result = false;
            }
            
            mMonitor.notifyAll();
            
            return result;
        }
    }
}

It takes an Object as the sole construction argument, it will be used as the thread monitor to synchronize on and to notify the code that is actually waiting for the image to fully arrive. This code looks like this in it's most basic form, the explanations are in the comments:

Toolkit          toolkit = Toolkit.getDefaultToolkit();
Image            image = toolkit.getImage(image_resource);
Object           monitor = new Object();
ImageObserver    observer = new WaitingImageObserver(monitor);

// prepare the image for rendering, ie. start obtaining the data
// asynchronously in another thread
toolkit.prepareImage(image, -1, -1, observer);

synchronized (monitor)
{
    // check if the image has fully arrived by bitwise checking the
    // flags that are returned after the check
    // if the image has not fully arrived yet, wait until the image
    // observer receives newer data and perform another check
    while (0 == (toolkit.checkImage(image, -1, -1, observer) & ImageObserver.ALLBITS))
    {
        try
        {
            monitor.wait();
        }
        catch (InterruptedException e) {}
    }
}

// draw the fully arrived image
g2.drawImage(image, 0, 0, observer);

Hope this will help somebody since it took me quite some time to assemble all the information about this.

After many months of providing bugreports and asking for feature additions during the beta process, Codeguide 6.1 has finally been released. The complete feature list is available here and the screenshots can be seen here.

Thanks to Codeguide I've already been able to fully use the upcoming java 1.5 features since more than a year for RIFE's development and they are all very nicely integration with every aspect of the IDE. The really great thing is that the generated bytecode is 100% backwards compatible without any required libraries. This stands in sharp contrast against the JSR-014 v2.2 pre-release where one needs to add an undistributable runtime jar to the bootstrap classpath of the application.

I can warmly suggest everyone to try out this avant-garde, lightweight IDE that makes great use of the screen estate so that you're able to comfortably do what you do best : code.

Recently I've been doing a lot of swing coding and it's now slowly starting to dawn on me why a lot of people refer to Java as 'write once, test everywhere'. I never was confronted with this problem when writing server-side applications.

While the application does some neat stuff under Sun's version of Swing, I spent already quite some days trying to work around inconsistancies in IBM's and Apple's implementation. There are even area's were the same JDK vendor creates incompatible changes across minor revisions.

The latest Apple update 1.4.1_01 broke so much that it's not funny. My custom drag&drop implementation with specialized drop targets and transfer handlers just stopped working completely, while nothing close to this area is mentioned in the changelog. After more than a day of debugging and searching I just gave up and consider performing UI changes which allow an alternative manipulation method instead of drag&drop under MacOSX.

Apple's implementation of Java2D is also becoming rather ridiculous. They clearly state in the known issues that diagonal lines will turn up much bigger (3 pixels instead of 1 pixel wide) as a workaround for some issue that caused 1 pixel-wide lines to not appear. Does that sound like a dirty hack or what?

They also succeeded in making XOR painting completely broken so that I had to check for the JDK platform to draw selection lines in a plain color instead of the standard XOR approach that's used by so many applications. The last blatant bug I just discovered is that with wide strokes, ovals turn up as mini spirals since the start and end joins of the shape are shifted by a pixel, thus not creating a nicely closed geometrical form ... horrible and impossible to work around.

What ever gets into the mind of JDK vendors to ship software in such a state. Yes I know that bugs are part of every application, but issues as visible as these are clearly a sign of lack of dedication and quality assurance.
I'll consider SWT for my next GUI project. Maybe a library that's maintained by one central source and that is thus the same for every platform creates less problems. Let's hope.