Spring Me

Spring ME A framework so small, it makes you feel like a giant December 1, 2008

Table of Contents 1. Introduction ................................................................................................................. 1 2. How does it work? ........................................................................................................ 1 3. Show me an example .................................................................................................... 2 4. What else is supported? ................................................................................................ 4 5. What does the future behold? ........................................................................................ 5 6. Summary and Conclusions ............................................................................................. 5

1

Introduction During the last couple of years, Spring has essentially taken over the Enterprise world, by introducing a simplified and coherent programming model, and a powerful dependency injection framework. Unfortunately, if you were working on Java ME™, you were basically out of luck, for various reasons. First of all, 'classic' Spring is totally dependent on reflection, a capability not present in Java ME. But even if it would be present, then the sheer size of the minimal Spring runtime would grow the size of your application beyond any reasonable numbers. That basically leaves the Java ME developers in the dark. In fact, coming from the EE world, it feels awkward to start programming on Java ME. Once you got used to dependency injection, it's hard to do without. However, there is light at the end of the tunnel. This article introduces Spring ME. A framework that does work on Java ME, and moreover has no runtime dependencies at all.

2

How does it work? Now, if 'classic' Spring relies on runtime reflection for dependency injection, Spring ME clearly requires something else. That 'something else' is build time analysis and code generation. The BeanFactories in 'classic' Spring are library-provided classes that use reflection for two purposes. First of all, it is used to gather data about the object graph to instantiate. Secondly, it is used to perform the construction and configuration of these objects. The BeanFactory in Spring ME is quite different. Instead of a class provided by the Spring runtime, it is a class that is generated, addressing the needs of your application explicitly. Instead of using

1

Spring ME

reflection to gather data about the object graph to construct, it relies on 'compile time' source code analysis only. And in order to instantiate the classes, it uses plain old vanilla Java code. In order to illustrate the difference, Example 1, “'Classic' Spring Approach” shows the classic approach to Spring bean construction and configuration. It's a simplified example, and it omits the slew of exceptions that you would need to catch, but you probably get the picture.

Example 1. 'Classic' Spring Approach Class cl = Class.forName("Person"); Object instance = cl.newInstance(); Method meth = cl.getDeclaredMethod("setName"); method.invoke(instance, new Object[] { "Wilfred Springer" });

Example 2, “Spring ME Approach” illustrates the Spring ME approach. It looks ridiculously simple, and in fact, it is.

Example 2. Spring ME Approach Person instance = new Person(); instance.setName("Wilfred Springer");

The important thing to note here is that both examples could be based on the same snippet of Spring configuration, such as the snippet in Example 3, “Example configuration”. The 'classic' Spring example interprets it at runtime; Spring ME generates source from it at build time.

Example 3. Example configuration <property name="name" value="Wilfred Springer"/>

Now, the smart readers might start wondering where the type information is coming from. After all, the bean configuration does not provide it. How do we know if the value "Wilfred Springer" actually represents a String, and not something else? A primitive int, for instance?1 The answer is simple, that data is gathered build time as well, by analyzing the sources.

3

Show me an example In order to understand what this means in reality, let's look at a simple example example first. In this simple example, we define two different classes: Teachers and Courses. A teacher can teach many courses. Each of these courses has a certain topic.

1

Note that the code that would have to be generated in Example 2, “Spring ME Approach” would need to be different if the name property would be an int. I leave it as an exercise to the reader to figure out how it would be different.

2

Spring ME

Example 4. Teacher and Courses class Teacher { public void setName(String name); public String getName(); public void setAge(int age); public void getAge(); public void setCourses(List courses); public List getCourses(); } class Course { public void setTopic(String topic); public String getTopic(); } Now, assume that we are going to create some instances of these classes by defining a teacher (Rudy Rucker), teaching a single course, called "The Fourth Dimension and Howe to Get There". Example 5, “Spring configuration” illustrates how you could do it.

Example 5. Spring configuration <property name="name" value="Rudy Rucker"/> <property name="courses"> <list> <property name="topic" value="The Fourth Dimension and How to Get There"/>

Everything you have seen so far is still plain vanilla Spring. Nothing fancy. Same syntax, same POJO approach. But the next step is a Spring ME only step. In order to have BeanFactory capable of dealing with this configuration, we need to generate that BeanFactory. You generate the BeanFactory by calling a Maven plugin. This is what you type on the commandline. mvn spring-me:generate

3

Spring ME

Assuming you haven't configured the Maven plugin in your pom.xml yet, you would have to pass three additional arguments. You need to pass the name of the Spring configuration file, the package name and the class name of the BeanFactory you want to generate. ... and this is basically it. The Maven plugin has now generated a source file in target/generatedsources/spring-me, and added this source folder to the list of source folders considered for compilation. The BeanFactory that got generated does not implement the BeanFactory interface. That is, it only implements one operation. The one that allows you to pass in a name, and returns the configured instance. Other operations could be added in the future, but this BeanFactory interface fitted our needs just fine. Example 6, “Example usage” shows how to use the BeanFactory generated.

Example 6. Example usage BeanFactory factory = new BeanFactory(); Teacher rudy = (Teacher) factory.getBean("someTeacher"); assertEquals("Rudy Rucker", rudy.getName()); assertNotNull(rudy.getCourses()); assertEquals(1, rudy.getCourses().size()); assertNotNull(rudy.getCourses().get(0).getTopic());

4

What else is supported? The example given in the previous section is fairly limited. Spring ME may support only a subset of what 'classic' Spring has to offer, but it is significantly more than what is listed in that section. In order to understand its scope, it is important to know that Spring ME is build on top of classic Spring. Yup, you read that right. The analysis done at build time is partly based on Spring's own BeanDefinition abstractions. So, it reads an XML application context using the implementation of Spring itself. Once the bean definitions have been made available, it is turned into Spring ME's own meta model, and augmented with information extracted from source code and class files. Being built on top of Spring ME has the advantage that some things just happen to work. As an example: Spring ME supports context files imports, allowing you to build a single application context out of several others. There is nothing in Spring ME itself that had to be done to make this work, other than building on the existing Spring API. So, with that out of the way, this is a quick rundown of what Spring ME supports: • • • • • • • •

Property-based injection; Constructor-based injection; Injection of primitives, such as integers, booleans, etc. Injection of anonymous beans; Injection of beans based on references; Injection of lists; Init and destroy methods; Lazy initialization and eager initialization;

... and last but not least: Spring ME is capable of leveraging all goodness provided by the Spring IDE: it just works like a charm. Initially, when we started work on Spring ME, we carefully isolated our

4

Spring ME

own meta model from Spring's configuration mechanism, in order to retain the ability to have our own configuration mechanism as well. However, Spring IDE support already makes it fairly unlikely that there will ever be another way of configuring it.

5

What does the future behold? Looking at the list of features given in the previous section, you probably have noticed things that were missing. For instance, Spring ME does not support FactoryBeans yet. Or construction based on other scoping rules. However, most of that can be implemented on top what is available today. So, what about other, more advanced Spring features. Let's briefly visit a few of those. The first thing that comes to mind is AOP support. Spring ME does not have it, and it will never be able to support the runtime weaving capabilities provided by 'classic' Spring. (Java ME does not support the classloader magic that would be required to support it.) However, it might be possible to support compile-time weaving. Another Spring feature that gained significant traction during the last couple of years is annotationbased configuration. Will Spring ME be able to support it? I reckon, it will. Remember, Spring ME creates its own meta-model, based partially on metadata provided by Spring's API, and partially on source- and bytecode analysis. Support for annotations would just require pulling that metadata from another source. The source code generation mechanism would stay the same. Now, the first official release of Spring ME will not support this. The ambition is to stabilize and document the APIs, add more test coverage, and then ship a first release in Q1 2009.

6

Summary and Conclusions Spring ME is a subset of Spring; it allows you to use the Spring paradigm on Java-based platforms that traditionally had to do without. The name not only refers to the fact that it supports Java ME, but it also refers to the fact that the runtime footprint is extremely small: at this stage - apart from the BeanFactory generated - exactly zero bytes. It is important to stress that Spring ME not only targets Java ME. There are other Java based platforms that could benefit from it as well. GWT comes to mind. And even Java SE™ could benefit from it. (I have to admit, I don't like shipping a number of Spring libraries when all I want to do is release a simple commandline tool.) It is not hard to imagine how Spring ME will change the way you build Java ME applications. Spring has significantly influenced the way APIs are structured. Spring ME might be able to do the same to Java ME APIs.

5