Last friday and saturday LogicaCMG organised an internal RADRace. The man who made the assignment was nobody other than Ivan Verborgh, the man who makes the assignments for the international RADRace.
The assignment was to make a webbased application with which people could apply for a license plate. It had to contain at least:
- Multi-lingual screens
- A webservice for checking credit card codes
- Role based authorisation, different functions for different roles
- Wizard like registration process
- And of course lots of business rules
Last year we (Reza Ahmadi and I) entered using Oracle Designer and Oracle Forms (after realising we didn’t have enough knowledge of Oracle ADF) and had the pleasure to win.
This year we (Gideon Liem and I) entered using Oracle JDeveloper 10.1.2 and the Oracle ADF framework. We had prepared a kick-start application that contained a new look-and-feel (Using custom renderers in UIX) and some authentication method.
From there we built almost the complete application. In the end the following stack of technologies were used:
- Oracle Database 10g (as the big Datastore, we can use another database?)
- Oracle OC4J stand-alone (as the application server)
- A small SMTP server, called JES
- Oracle ADF Business Components (as the persistence layer)
- Oracle’s implementation of JSR-227 (as the binding layer, between the persistence and the view layer)
- Oracle ADF UIX (as the view layer layer)
- Apache Axis (as the webservice engine)
- Apache jUDDI (as the webservice registry)
- UDDI4j from Sourceforge (communication with the registry)
- Apache WSIF (communication with the webservice)
- Apache POI (generating Excel reports)
One of the things that were most difficult for us was the refactoring of the data. Ivan had prepared the challenge in a way that we got the data as two big denormalised tables. Part of the challenge was to normalise the data so you could use it for your application. It took us the morning of the first day and the first hour of the afternoon to get the database right.
After that the framework kicked in: generation of the persistence layer is really a breeze. When you just had the rule of thumb to code your screens on your tables (don’t think in Objects if you got tables… it makes sence to see the whole picture and combine the two). UIX pages are the view layer we used in projects the last year and we have become quite proficient with them. The binding layer makes it possible to get your model and just drag them tables into the screen and have them work. Most of the time we could do what building an application is about: building the business logic that matters… All else should be simple, easy and quickly done.
Rest us to say we had the pleasure to finish first in the contest. Unfortunatly our competitors that used JHeadstart had to drop out for the second day (for personal reasons), we would have really liked to compare their result with ours.
Runners up were: in second place a microsoft team using Microsoft .NET 2.0 (they also had a good working application) and in third place a Java based team that used LogicaCMG’s own open-source framework: ePlatform.
Photo’s
All the teams and the jury
We, Gideon (right; in white, red & blue) & Robert (left; in grey)
Design is essential
Evaluation by the jury
Success!
Links
Oracle Technology site, you can find the database, application server and JDeveloper here.
Apache, great products here
Sourceforge, also here
bloggingabout.net, another blog sponsered by LogicaCMG that contains a post from the microsoft competitors
ePlatform (on sourceforge), the ePlatform site
One of the major new features of Java 5.0 is generics. The main purpose of generics is to provide you with a way to make type safe collections, for example, you can specify that your List contains only String objects. The obvious advantages are that the compiler can check at compile time that nothing else than String objects are stored in the List and that you can eliminate a lot of type casts from your source code.
// Old style, not type safe
List names = new ArrayList();
names.add("Jesper");
names.add(new Integer(123)); // not what you meant, but no error or warning
// Java 5.0, using generics
List<String> names = new ArrayList<String>();
names.add("Jesper");
names.add(new Integer(123)); // compiler error
That seems simple enough, but if you study generics in more detail, you will discover that there are some strange limitations that don’t look obvious at first sight.
For example, here is one limitation of generics I would like to highlight: You cannot create an array whose component type is a concrete parameterized type. An example to explain what this means:
// An array of a list of strings. This is illegal, but why?
List<String>[] data = new ArrayList<String>[10];
At first sight, this looks perfectly reasonable. But if you try to compile this, you get an error message, and it isn’t very helpful either:
Jesper.java:6: generic array creation
List<String>[] data = new ArrayList<String>[10];
^
1 error
The compiler just tells you that you can’t do this, but it doesn’t give a hint why. To understand why this is illegal, we have to know a few things about arrays and generics in Java.
First of all, arrays are covariant, which means that an array of supertype references is a supertype of an array of subtype references. For example, Object[] is a supertype of String[], and a string array can be accessed through a reference variable of type Object[].
Object[] example = new String[10]; // ok
example[0] = "Hello World!";
Arrays also carry runtime type information about their component type. At runtime, when you assign a value to an array element, an array store check is performed to check that you’re not storing a value in the array that’s not compatible with its component type. If the check fails, an ArrayStoreException is thrown.
Object[] example = new String[10];
example[0] = new Long(123); // compiles, but throws ArrayStoreException at runtime
That still doesn’t explain why arrays of concrete parameterized types are illegal. There’s one more thing we have to understand, and that is the process of type erasure.
When you compile Java source code in which generic types are used, the compiler does the extra type checks and then translates the code into plain old Java code without generics. If you would decompile the byte code, you would see that the generics have disappeared. So for example List<String> and List<Integer> would both look like the plain old List in the byte code - the information about the generics has been lost by the process of type erasure. The following example illustrates this:
List<String> names = new ArrayList<String>();
List<Integer> values = new ArrayList<Integer>();
System.out.println("Runtime type of 'names': " + names.getClass().getName());
System.out.println("Runtime type of 'values': " + values.getClass().getName());
The output of this piece of code is:
Runtime type of 'names': java.util.ArrayList
Runtime type of 'values': java.util.ArrayList
As you see, both look like plain old ArrayList at runtime. I won’t go into the details here of how and why the compiler handles generics using type erasure.
So here comes the catch. The combination of how arrays work (covariance and runtime type information about the component type) and type erasure for generic types creates a problem when you want to create an array of a concrete parameterized type.
Because of type erasure, there is no exact type information available for the generic type at runtime, so that the array store check doesn’t work, and an unacceptable situation occurs. Here’s an example.
List<String>[] data = new ArrayList<String>[10]; // illegal, but assume that this would be ok
Object[] objArr = data;
objArr[0] = new ArrayList<Integer>(); // should fail, but would succeed
List<String> firstList = data[0]; // would fail with ClassCastException, but there's no cast!
Because of type erasure, List<String> looks like a plain List and ArrayList<Integer> looks like a plain ArrayList at runtime. The array store check would succeed, because ArrayList is a subtype of List. Ofcourse we now end up in an unacceptable situation - the first element of the array now contains an ArrayList<Integer>, which shouldn’t be possible.
To avoid this problem, the Java language engineers at Sun simply decided to make arrays of concrete parameterized types illegal.
Isn’t it ugly that a construct that looks perfectly reasonable (you can make an array of any type, so why not of a concrete parameterized type?) is made illegal essentially because of the way the compiler treats generics? In other words, the language has a hole now because of the implementation details of the compiler.
This is just one of the quirks that you find when you look at generics in depth. You can find a lot of detailed information about generics in Angelika Langer’s Java Generics FAQ.
We all know that Microsoft doesn’t like Java. But did you know that Microsoft in their license agreement even warns users that Java technology is potentially deadly?
Yakov Fain discovered this when he was reading a Microsoft end-user license agreement:
The software product may contain support for programs written in Java. Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines , or weapon systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage.
See also the article on TheServerSide, one of the major J2EE community websites.
