Emacs on N810

August 15th, 2008

I already mentioned it a couple of times that Emacs is running on Nokia N810. Today, I installed it. One of the biggest hurdles I had to take - not such a big hurdle at all - is to apt-get install some of the required libraries myself. I installed the X version, but I’m thinking about downgrading to the no-X version instead; much easier to use than the X version.

A couple of gotchas you would have to know: The meta key is the lower key of the keys left from your display.

… and by the way, this is all running on Diablo, in case you were wondering about that.

My first experience: it’s quite good. I think I will try to install nxml-mode, to see if that works. In that case, I can even edit DocBook documents on my Nokia. ;-)

Spring on Java Mobile has Arrived!

August 7th, 2008

Once you get in the habit of using dependency injection in your software, there is no turning back. That is, unless you are working on Java ME. In fact, it is even impossible to use any of the popular dependency injection mechanisms at all.

The reason why all of the popular dependency injection framework fail on ME, is because they all rely heavily on reflection. For instance, in order to set fields of an object to a certain value. Or to determine the type of the object injected, and do some adaptation on the fly. And, unfortunately, Java ME does not support reflection.

The attempts to create a Java ME-based dependency injection framework that I know of (like the Israfil micro container) all try to compensate for not having reflection by putting the burden of configuration on the developer. As a consequence, you end up writing more code than what you are used to; not necessarily desirable for a platform on which every byte counts. ;-)

So I decided to take another stab at it. I decided to implement reflection on Java ME. Just kidding.

What I did instead is, first of all, decide that I do not actually need the just-in-time runtime decisions on how my objects are going to be wired. I decided that it would be fine, if all of that would be done at build time. At build time I have all the tools to obtain the metadata I need. At runtime, I hardly have any at all.

Next I figured that - if I want this dependency injection mechanism to survive - I better stick to what people are used to. So instead of defining yet another way of expressing dependencies, I figured it would be good to build on the existing popular frameworks. Spring in particular.

After that, I decided that I did not need all features of Spring. Not even all of the features provided by its core dependency injection mechanism. So I decided to have my own meta model of the instances and their dependencies, and have the ability to instantiate that model from a Spring application context.

And then the fundamental trick: instead of using this meta model to construct a BeanFactory at runtime, this new dependency injection mechanism uses the meta model to construct a BeanFactory at build time. It will source code for the entire BeanFactory. It turns out, this is possible, and it also turns out it leaves you with no runtime dependencies at all, which is also a nice side effect.

So, here is an example of a Spring application context:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
	
  <bean name="teacher1" class="com.tomtom.di.spring.Teacher">
    <property name="name" value="Wilfred Springer"/>
    <property name="age" value="35"/>
    <property name="courses">
      <list>
        <ref bean="course1"/>
        <ref bean="course2"/>
        <bean class="com.tomtom.di.spring.Course">
          <property name="topic" value="C++"/>
        </bean>
      </list>
    </property>
  </bean>
	
  <bean name="course1" class="com.tomtom.di.spring.Course">
    <property name="topic" value="Java"/>
  </bean>
	
  <bean name="course2" class="com.tomtom.di.spring.Course">
    <property name="topic" value="Erlang"/>
  </bean>
	
</beans>

… and here is the BeanFactory that is created from it:

package com.tomtom.spring;
	
/**
 * An object factory, providing access to a network of wired objects,
 * some of them lazily instantiated. You can refer to some objects by
 * name. The named objects managed by this class are:
 *
 * <ul>
 * <li>teacher1 : {@link com.tomtom.di.spring.Teacher}</li>
 * <li>course1 : {@link com.tomtom.di.spring.Course}</li>
 * <li>course2 : {@link com.tomtom.di.spring.Course}</li>
 * </ul>
 *
 */
public class BeanFactory {
	
    /**
     * A cached reference to the bean named "teacher1".
     */
    private com.tomtom.di.spring.Teacher teacher1;
	
    /**
     * A cached reference to the bean named "course1".
     */
    private com.tomtom.di.spring.Course course1;
	
    /**
     * A cached reference to the bean named "course2".
     */
    private com.tomtom.di.spring.Course course2;
	
    /**
     * Returns an object by looking it up by its name.
     *
     * @return The object with the given name, constructed by the BeanFactory.
     * @see BeanFactory
     */
    public Object getBean(String name) {
        if ("teacher1".equals(name)) return getTeacher1();
        if ("course1".equals(name)) return getCourse1();
        if ("course2".equals(name)) return getCourse2();
        return null;
    }
	
    /**
     * Returns the bean named "teacher1".
     *
     * @return The bean named "teacher1".
     * @see #createSource0()
     */
    final private com.tomtom.di.spring.Teacher getTeacher1() {
        if (teacher1 == null) {
             teacher1 = createSource0();
        }
        return teacher1;
    }
	
    /**
     * Returns the bean named "course1".
     *
     * @return The bean named "course1".
     * @see #createSource9()
     */
    final private com.tomtom.di.spring.Course getCourse1() {
        if (course1 == null) {
             course1 = createSource9();
        }
        return course1;
    }
	
    /**
     * Returns the bean named "course2".
     *
     * @return The bean named "course2".
     * @see #createSource11()
     */
    final private com.tomtom.di.spring.Course getCourse2() {
        if (course2 == null) {
             course2 = createSource11();
        }
        return course2;
    }
	
    /**
     * Constructs one of the required instances of {@link com.tomtom.di.spring.Teacher}.
     *
     * @return One of the required instances of {@link com.tomtom.di.spring.Teacher}.
     */
    final private com.tomtom.di.spring.Teacher createSource0() {
        com.tomtom.di.spring.Teacher result = new com.tomtom.di.spring.Teacher();
        result.setCourses(createSource8());
        result.setName("Wilfred Springer");
        result.setAge(35);
        return result;
    }
	
    /**
     * Constructs one of the required instances of {@link com.tomtom.di.spring.Course}.
     *
     * @return One of the required instances of {@link com.tomtom.di.spring.Course}.
     */
    final private com.tomtom.di.spring.Course createSource9() {
        com.tomtom.di.spring.Course result = new com.tomtom.di.spring.Course();
        result.setTopic("Java");
        return result;
    }
	
    /**
     * Constructs one of the required instances of {@link com.tomtom.di.spring.Course}.
     *
     * @return One of the required instances of {@link com.tomtom.di.spring.Course}.
     */
    final private com.tomtom.di.spring.Course createSource11() {
        com.tomtom.di.spring.Course result = new com.tomtom.di.spring.Course();
        result.setTopic("Erlang");
        return result;
    }
	
    /**
     * Constructs one of the required instances of {@link com.tomtom.di.spring.Course}.
     *
     * @return One of the required instances of {@link com.tomtom.di.spring.Course}.
     */
    final private com.tomtom.di.spring.Course createSource7() {
        com.tomtom.di.spring.Course result = new com.tomtom.di.spring.Course();
        result.setTopic("C++");
        return result;
    }
	
    /**
     * Constructs a java.util.Vector of objects, to be injected elsewhere.
     *
     * @return A list of objects.
     */
    final private java.util.Vector createSource8() {
        java.util.Vector result = new java.util.Vector();
        result.add(getCourse1());
        result.add(getCourse2());
        result.add(createSource7());
        return result;
    }
	
}

Now, the only public operation on this class is obviously the getBean operation. It’s all you need. You could try to understand all of the other operations, but this is the code that you should not be worrying about. It’s just provided here for illustrative purposes.

The current state of the framework is that there is Maven plugin that is doing all of this. There are a couple of things that I want to add, such as completing constructor injection and support for factory-method and a factory-bean. But the current incarnation is already working fine.

Now, if you have made it this far, you hopefully started to search for the download button. Now, unfortunately, this stuff is not open sourced yet. However, if you feel this is what you need, I suggest you make yourself heard, by posting your wish for getting your hands on this code as a comment on this blog. The more people displaying their interest in getting this out there as open source, the easier it will be for me to convince some people to do it.

Technorati Tags: , ,

On how it is OK to be lazy

August 4th, 2008

A couple of days ago, I blogged about a lazy loading caching object reference, and I said I was going to use MultithreadedTC to test if it was behaving OK. First of all, the implementation I uploaded is not threadsafe. Second: Ecto, the OSX based blogging client is awful: I spent half an hour writing up the problems with my first implementation, and detailing how I implemented the new one, saved it in Ecto, and - what do you know - Ecto just conveniently dropped it.

Anyhow, back to the lazy loading caching reference. I think I now have something that works. I don’t have the time to discuss it again entirely, but I will just give you the source code, and a UML diagram that basically explains the basic idea.

package com.tomtom.quarks.util;
	
import java.lang.ref.SoftReference;
import java.util.concurrent.Callable;
import java.util.concurrent.CancellationException;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;
import java.util.concurrent.FutureTask;
import java.util.concurrent.atomic.AtomicReference;
	
/**
 * A <i>reference</i> to a an instance of type {@link T}, to be dynamically
 * loaded, on demand, whenever the reference is resolved by calling
 * {@link #get()}; once loaded, the reference will hold on to the instance of
 * {@link T} until the garbage collector collects it. After that, the instance
 * of {@link T} will - again - be recreated, whenever required.
 *
 * @author Wilfred Springer
 *
 * @param <T>
 *            The type of object referenced.
 */
public class LazyLoadingReference<T> {
	
    /**
     * An {@link AtomicReference} to a {@link SoftReference} to a {@link Future}
     * producing an instance of {@link T}. The {@link AtomicReference} makes
     * sure the value can be updated atomically. The {@link SoftReference} makes
     * sure the garbage collector will release the reference if it needs more
     * memory. The {@link Future} makes sure that - once the value has been set,
     * all calls to obtain the data will be blocked until it arrives.
     */
    private final AtomicReference<SoftReference<Future<T>>> reference = new AtomicReference<SoftReference<Future<T>>>();
	
    /**
     * A {@link Loader} of {@link T}.
     */
    private final Loader<T> loader;
	
    /**
     * Constructs a new reference, accepting the {@link Loader} that will lazily
     * load the data when required.
     *
     * @param loader
     *            The {@link Loader} loading the data.
     */
    public LazyLoadingReference(Loader<T> loader) {
        this.loader = loader;
    }
	
    /**
     * Returns an instance of {@link T}, lazily constructed on demand using the
     * {@link #loader Loader}.
     *
     * @return The referenced instance of {@link T}.
     * @throws InterruptedException
     *             When blocking call is interrupted.
     * @throws ExcecutionException
     *             When the {@link Loader} threw an exception trying to load the
     *             data.
     */
    public T get() throws InterruptedException, ExecutionException {
	
        // We may need to try this a couple of times
        while (true) {
	
            // Let's first get the current SoftReference
            SoftReference<Future<T>> softReference = reference.get();
	
            // And assume this SoftReference actually resolves in a Future
            boolean validSoftReference = true;
	
            // If the SoftReference is null
            if (softReference == null) {
	
                // Then we need to prepare loading the data:
                // (1) Define what needs to happen if we need to load the data
                Callable<T> eval = new Callable<T>() {
	
                    public T call() throws Exception {
                        return loader.load();
                    }
	
                };
	
                // (2) Create a FutureTask, that will eventually hold the result
                FutureTask<T> task = new FutureTask<T>(eval);
	
                // (3) Create a replacement SoftReference, pointing to the value
                // to be calculated.
                softReference = new SoftReference<Future<T>>(task);
	
                // Now try to set the AtomicReference, if it's still null
                if (validSoftReference = reference.compareAndSet(null,
                        softReference)) {
	
                    // We've set the AtomicReference, now let's make sure there
                    // is a value held by the SoftReference.
                    task.run();
	
                }
	
                // Otherwise, if the AtomicReference has been populated
                // meanwhile, we are just going to drop the FutureTask and
                // SoftReference created.
            }
	
            // In case we now have a valid SoftReference
            if (validSoftReference) {
	
                try {
	
                    // Obtain the Future
                    Future<T> future = softReference.get();
	
                    // ... and if it is not null
                    if (future != null) {
	
                        // ... we can return the value
                        return future.get();
	
                    } else {
	
                        // ... otherwise it's obviously a collected reference.
                        // In that case, we need to make sure it's getting
                        // replaced by a new SoftReference if we reenter the
                        // loop.
                        reference.compareAndSet(softReference, null);
                    }
	
                } catch (CancellationException e) {
	
                    // If Future.get throws a CancellationException, we need to
                    // set the AtomicReference to null.
                    reference.compareAndSet(softReference, null);
	
                }
            }
        }
    }
	
    /**
     * The interface to be implemented when loading instances of {@link T}.
     *
     * @param <T>
     *            The type of object to be loaded.
     */
    public interface Loader<T> {
	
        /**
         * Loads the instance of {@link T}.
         *
         * @return The instance of {@link T} loaded.
         * @throws Exception
         *             If the {@link Loader} fails to
         */
        T load() throws Exception;
	
    }
	
}

Technorati Tags: ,

Maven + J2ME Polish (part 1)

July 15th, 2008

The question I am trying to answer today, is if it would be possible to have a decent multi module build based on Maven and J2ME Polish.

Combining the two seems to require something like cold fusion; they both try to control the entire build lifecycle.

So, here are some of my first conclusions.

Just running the J2ME Polish build from Maven is easy. You just plug in the maven-ant-run plugin, and it just works:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>run</goal>
            </goals>
            <phase>package</phase>
            <configuration>
              <tasks>
                <ant antfile=\"build.xml\" target=\"j2mepolish\"/>
              </tasks>
            </configuration>
          </execution>
        </executions>
      </plugin>

So, that sort of works. But is it also desirable. That’s hard to tell. At this stage, the pom.xml file controls J2ME Polish. I already pull in dependencies in the pom using the Ant tasks for Maven (see below). However, if the pom.xml file’s packaging type is set to jar, and if you have set your source directory to point to the actual location of your sources, your build will fail if you use J2ME Polish’ preprocessing directives.

  <typedef resource=\"org/apache/maven/artifact/ant/antlib.xml\"
           uri=\"urn:maven-artifact-ant\"
           classpath=\"antlib/maven-ant-tasks-2.0.9.jar\"/>
	
  <artifact:pom id=\"maven.project\" file=\"pom.xml\"/>
	
  <artifact:dependencies pomRefId=\"maven.project\"
                         filesetId=\"dependency.fileset\"/>
	
  <artifact:dependencies pomRefId=\"maven.project\"
                         filesetId=\"test.dependency.fileset\"
                         useScope=\"test\"/>

The easy way out is to set packaging type to pom. Quite to my surprise, that actually works. I expected the Maven Eclipse Plugin to basically ignore this project and its source directories. (I think I remember this is the way it used to work in the past.)

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-eclipse-plugin</artifactId>
        <configuration>
          <additionalProjectnatures>
            <projectNature>de.enough.mepose.core.polishNature</projectNature>
          </additionalProjectnatures>
        </configuration>
      </plugin>

But let’s not get too excited; this is just a single module build.

Macro Annotations

July 14th, 2008

In my spare time, I am working on a framework that will allow you to declaratively map a data model to a bitstream representation, with support for all of the funky encoding mechanisms that you can imagine.

My framework - just like all other frameworks in Java these days - is based on annotations. Just to give you an example: this is the way you map an integer field to a 13 bit representation:

@BoundNumber(size="13", endian=Little)
private int fooBar;

The Problem

Now, what if your code is speckled with 13 bit little-endian encoded integer numbers. The framework is general purpose framework, so having dedicated support for 13 bit little-endian encoded integer numbers would be awkward. However, at the same time, it’s also a little akward to have these annotations all over the place where integers are read.

The solution might be something I dub macro annotations for now: annotations that will be expanded at runtime into other annotations. So suppose the application using my framework is providing satellite data, and for some reason, every integer sample is represented as a 13 bit int, then I would define an @SatelliteSample annotation, to be expanded to a @BoundNumber(size=”13″, endian=Little) annotation at runtime.

The net result is that my code would look like this:

@SatelliteSample
private int fooBar;

It’s almost a domain specific language.

Defining Macro Annotations

Now the question is how you would define macro annotations like these. Here’s a thought; what about using annotations? No seriously. This is what I propose:

@Macro(
    @Annotation(type=BoundInteger.class, elements={
        @Element(name="size", value="13"),
        @Element(name="endian", value="com....Endian.Little")
    })
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface SatteliteSample {
}

I don’t think the mechanism above would be all that hard to implement, even transparently, without ever having to touch the framework that assumes the @BoundNumber annotation is present. (The specific way to do it is left as an excercise to the reader ;-) .)

And Beyond…

Now, it turns out, I am not the only one who would be interested in a mechanism like this. In fact, somebody on the JAX-RS mailing list was also asking for it, to keep the Spring and JAX-RS annotations in sync. Basically, he wanted his own annotation that would ‘generate’ a Spring and JAX-RS annotation at runtime, and have one place to manage the scope of the bean, for instance.

Of course, in that case, the annotation driven macro annotation approach given above would require the capability to refer to elements (the annotation specification name for fields) of the macro annotation. The macro annotation would define a scope element. The annotations on the macro annotation would define how that would translate to a Spring and JAX-RS annotation.

So, what do you think? Would this be useful? Have you ever come across cases in which this might be applicable?

Technorati Tags: ,

WADL API

June 3rd, 2008

The fact that WADL is XML is both a bless and a curse. It is sort of convenient not having to worry about syntax, getting code completion in Emacs nxml-mode, and to have the ability to transform WADL into other things, using XSLT for instance. However, no matter what you try, there will always be some chunks model relationships that are available as first class citizens in the Infoset representation of WADL. So something that seemed really easy, often turns out much harder, and you find yourself having to pull in EXSLT to accomplish something simple.

So the question is, is the XML representation actually all that convenient at all? What about using Java instead?

A couple of months ago, I looked under the hood of the current collection of WADL tools, to find out there is not such a thing as a real convenient API layer to build to build your own processing tools. The classes in wadl-core currently postprocess a JAXB decoded representation of the WADL file, but you cannot access that postprocessed instance unless you modify or copy source code.

So I figured to see if I could create an API and get that injected eventually. You can find the results here. As you will notice, there is not a single line of real documentation, but I hope I will have some time to work on that soon.

Any way, what I tried to do is to marry a couple of conflicting concerns.

First of all, I want to be able to process a model using StringTemplate. As a consequence, you need to be able to traverse your entire model using bean property accessors. So I wanted to stick with the bean naming convention, and expose all of that in the most straight-forward way.

Second, I also wanted the different chunks of metadata found in a WADL file to be linked. So if I am referencing template parameters in my path attributes of a resource, I want to the path’s template parameter’s representation in Java to be linked to the metadata that is normally defined in the param sub elements of the resource.

Third, I wanted the API really to reflect the constraints WADL imposes. According to the schema, you can use plain style parameters everywhere. According to the spec, you can only use them inside of representation elements. I want to make sure the API reflects that.

And then I also wanted to be able to deal both with the expanded URI templates as well as the individual paths. The path normally does not contain query parameters. But the URI template should.

The trouble with APIs like these is that there are just different views and different ways to provide easy access to the different model elements. I’m trying to strike a balance here. Hopefully you will appreciate it.

New Language Features

May 8th, 2008

One of the BOFs I attended yesterday was the new Java Language Features BOF. Some of the things they are able to do and planning to get into a next version of Java are pretty cool; however, I can’t help to wonder if we really need this, and if there isn’t something wrong with the power-to-weight ratio.

Question is if these kind of efforts don’t get in the way of the adoption of alternative languages, such as Scala. Personally, I think they do. Rather than trying a new language that also runs on the Java platform, people are waiting for Java to be stretched, bended and molded in such a way that it’s capable of supporting a poor-mans implementation of the features found in those other languages.

Apart from that, it’s not all that clear what’s causing the team to work on these features in particular, and not on other features. Again, I can’t help to wonder if it is not partly fueled by the hacker paradigm (”It can be done”) and by a sheer scientific interest. Now, I am in total support of the hacker paradigm and scientific curiosity. However, I don’t think that should always blindly be endorsed into the standard.

The @Nullable and @Interned annotations are interesting, but shouldn’t we be working on languages that are capable of inferring these kind of things?

Today, I decided to do the yearly “what’s going on in JSR 277″ update. This is not my favorite JSR. Not that I don’t like module systems. It’s just that I am not sure we should be breaking up the language to have built-in support for it. Same story. Is retrofitting an existing language really the way to go?

JavaOne@code.google.com

April 10th, 2008

I just uploaded the schedule builder tools I mentioned during the last couple of entries to http://code.google.com/p/j108. All disclaimers apply. If you want to build this stuff yourself, then you will need to install the right Google Calendar jars to your own local repository first. I haven’t checked, but I am not entirely sure if they can be distributed through a Maven repository.

IETF Draft URI Template in Java

April 5th, 2008

I just uploaded a first stab at a Java implementation of the current IETF URI Template Draft Specification. At this stage, all it does it parse the URI template and call a SAX - or rather StAX-alike - handler for all the different pieces of the URI.

Find the project hosted here (http://code.google.com/p/uritemplate/).

Technorati Tags: , ,

Personalized JavaOne Schedule Google Calendar

April 4th, 2008

I changed a couple of lines to my JavaOne Google Calendar synchronization tool. Now it is also able to create a personal schedule on Google Calendar.

Find the actual calendar here.

Technorati Tags: , ,