It is what it is

There are multiple frameworks for transforming a JSON expression to a Java object tree, but the Java Platform does not come out of the box with some javax.json package (I heard there are plans for that).

Today I will show that you can easily transform a JSON expression to a simple Java object tree (map, arrays, primitive wrappers and string) with Java 6 and no additional framework.

Obviously, it may not be the best way to proceed, specially when it comes to speed, security or java mapping. However this solution is appropriate if those are not a concern and you don’t want to add a dependency to an external library for parsing JSON expressions.

The solution relies on the javax.script package and its Javascript binding. Indeed what’s best than Javascript to parse JavaScript Object Notation ?

The scripting API provides evaluation of any Javascript which is nice, unfortunately native Javascript objects are not usable from Java, but the magic of Javascript will come to the rescue!

Javascript is a dynamic language which allows to modify its meta object protocol (MOP) to add new functions on native Javascript objects, through the concept of prototypes. We can modify each of the base Javascript type’s prototypes to add a toJava function that will return a Java version of the object:

Now you probably get the idea, each toJava function returns the Java counterpart of the Javascript object. Initially I wanted to iterate the object tree, but extending the types thanks to the prototype is a much better solution.

We also need to add the missing Java part that loads this JS and uses it to create our Java objects. This is trivial to do thanks to the scripting API, here is how to load the Javascript and setup the engine:

Now we need to use the engine to convert JSON expressions:

Here there is a little trick: you can remark the usage of AtomicReference and it may look inappropriate since we are not dealing with concurrent programming. The trick is that if we return a String from the engine to Java, the engine will wrap it as a Javascript string and we want to avoid that. The AtomicReference makes the value opaque to Javascript and the Java code will unwrap it.

Those three pieces together makes a lightweight solution to transform JSON expressions to Java objects. There are certainly corner case not handled in this code, but it’s a solid basis to start with, I saved the code in a GitHub gist there.

We have been working hard to get this release done with a great set of new features!!!

First and foremost, I’m very proud of the level support we have now reached for Eclipse. As you may know, Juzu relies much on Annotation Processing Tools (APT) since the beginning to bring exclusive features. Making Juzu work with Eclipse incremental compiler was very challenging because APT simply works differently. Among those features, the type safe template parameters with Eclipse is showed in this screencast

The dev mode feature has been improved a lot, specially now the error reporting is more accurate and sexy, this screencast will teach you everything about switching an application to dev mode in Liferay

Juzu comes as a package to download on this page. Alternatively you can also use the maven archetype to bootstrap an application

Finally, the Dependency Injection has been improved in order to allow the injection of external providers, in particular this is useful if you are using Juzu in the GateIn server and you want to inject GateIn services in a Juzu application, this is now trivial to do and is explained in the wiki.

For the future we plan to develop new features and improve step by step the project, on top of my mind the integration with Bean Validation would be a good thing to do. If you are interested to follow the Juzu project development you can join our Juzu group.

Juzu is an open source web framework I started to work on recently, for several reasons, the most important one is that there is no decent framework for developing portlet application in a simple and productive manner. There are other good and valid reasons.

Juzu deploys on the GateIn Portal and on the Liferay Portal. Perhaps it also deploys on other portals, there aren’t any good reason why Juzu would not work on other portal (except bugs).

Juzu integrates with dependency injection frameworks such as Weld (CDI) and Spring, theoretically it should work with any injection framework providing a good support of the JSR-330 specification (however it requires some custom integration work, as JSR-330 is really lightweight…)

Juzu is a work in progress, however it is advanced enough to deliver the infamous Booking application.

If you are interested in Juzu (using or helping), you can start to read this page.

CRaSH 1.0.0-beta22 release features an IZPack installer that will let you configure a CRaSH runtime throughout a serie of screens, here is a short video showing an installation:

You can download them from the usual page.

We released last week the first milestone of GateIn 3.2, it was a long time since the 3.1 release and both Red Hat and eXo teams were quite busy working on the product and project side of GateIn.

Among the noticeable changes, you will find now a support for Jetty 6.1/Tomcat 7/JBoss AS 6 web containers, a improved Maven build compatible with Maven 3, a few UI improvements and many bug fixes. You can read more about it there.

I’m proud now to work with Bolek that will replace Thomas Heute as GateIn technical lead. Bolek was involved in the effort since the JBoss Portal projects and earned his credits by providing an Hibernate implementation of the now dead Slide project (JCR ancestor) and implementing much of the Portlet 1 TCK assertions in our testsuite (that proved to be invaluable when JSR 286 was implemented). He blogged about his new role in the project here.

If you are a fan of GateIn, the CRaSH shell is a must have companion for GateIn. CRaSH is a shell that provides a JCR access and allows to do stuff and hack GateIn. Use it at your own risks of course . Download of the latest beta-21 is here.

Finally it’s time of a few words about GateIn stuff that is another GateIn companion I started a few months ago on GitHub. It’s something more informal than a real project, it’s like a bunch of stuff that could be useful if you’re a GateIn user, at least it’s useful to me, it contains so far

• a CRaSH folder with command for adding users to GateIn
• gen : an XML generator for generating large navigations
• sqlman : a tool based on the great JBoss Byteman project that measures the access to resources, very valuable for monitoring database activity. Note that this tool is generic and does not depend on GateIn itself. We could extract it and find a better name (containing “spy”)

Nothing fancy, in it, mostly bug fixes (in particular for SCP CRASH-23 and CRASH-24).

I updated also the Google Code page to add links to GitHub where the project is now hosted and the online docs now have the PDF and the Javadoc.

Finally the project CI is now Jenkins hosted by my friends at Cloudbees. A special thanks to Arnaud for helping me setting this up.

The release is available on Google Code as usual.

I’ve been using Annotation Processing Tools (APT) for a few months now, and I like it. It opens new capabilities for the Java platform, I exploited them to create an APT virus, called APTVir.

APTVir is a single class and a single file that replicate when it is available on the classpath n the compiled code. It relies on APT to execute itself and copy itself in the output produced by the compiler.

Instead of long explanations, I created a screencast that explains it and the code is available as a GitHub repository.

In GateIn project we sometime have to deal with the setup of a JBoss cluster. While JBoss clustering is quite easy to configure there are things you need to configure such as a shared database. In addition when doing tests you need to start from a fresh database. I will give you a tip I’m using when I’m setting up a GateIn cluster that can help you to save time for setting up a database.

By default GateIn uses the famous embedded database HSQLDB and it is very convenient because

1. Deployed with GateIn, no need for extra setup
2. Sufficient for doing development
3. Fast
4. Easy to erase the database and start from fresh

So far the annotation API in Reflext was using the runtime API to provide annotation access. What I call the runtime API is what most of developers are used to when dealing with annotations.

When using the java.lang.reflect runtime, this works perfectly as the runtime provides obviously runtime annotation. Nothing special here. However at compile time, this runtime access is emulated by the compiler. The real API to access an annotation is the java.lang.model.element.AnnotationMirror interface that is a totally detyped access to an annotation. But the APT tries to be nice and provides an emulation of runtime annotation that works well until

• the introspected annotation is being compiled and it is not yet available under its class form
• the annotation is already compiled (coming likely from JDK or a dependency) but it has a Class parameter and that class is being compiled. In that situation the Class object is not yet available, consequently it fails.

For that matter there is now in Reflext an API that provides a detyped access to an annotation that works equally with runtime and compile time implementations (runtime annotation access is still possible of course) .Using such API is obviously less intuitive than using the annotation directly but when you don’t have the guarantee that you are the annotation type is already compiled it’s the only way to go.

We have just released CRaSH 1.0.0 Beta 8 on Google Code forge, in that release we have worked on two usability aspects of the shell:

• The capability for a command to prompt a value with or without echo of the value entered by the user. It is mainly used by the connect command to prompt the password when it is not entered via the -p option.
• The second feature is the up/down arrow associated to recalling previously entered commands.