Ext Direct Java based implementation

As far as we know, DirectJNgine is fairly feature complete. For example, it runs all examples provided by ExtJs in examples/direct, as well as our own additional examples and a host of automated tests.

But, of course, we have to wait for feedback from the community to make sure that it fits the community needs, and that it implements the mandatory Ext Direct feature set.

Main features

- Supports all types of request: JSON requests, batched JSON requests, form posts, form posts with file uploads and even polling provider based requests.
- Fully tested: more than 75 fully automated tests as of version 0.7.1 (beta).
- Provides a detailed User's Guide (more than 20 pages).
- Runs all of ExtJs examples in examples/direct.
- Provides additional examples.
- A WAR is enclosed showing all examples and running all automated tests.

If you are curious about how it works, there is a short excerpt from the User's Guide:

Now, how is everyday life with DirectJNgine?
Let’s assume that you want your Javascript code to call a sayHello Java method, which will receive a person name and return a greeting message. That is as easy as writing the following Java code:

Basically, you write your Java code without much concern for whether it will be called by some Javascript code living in a remote server or not. The secret? Using the @DirectMethod annotation DirectJNgine...

Of course, there are things to configure, best practices to follow, etc. But adding a new method will just feel like this.
For further detail, read the User's Guide, please.

What will be there in version 1.0?

For the 1.0 release we will provide all that's there in the 0.7.1, and then we plan to:

- Add support for custom data conversion from Javascript to JSON to Java and back.
- Enhance the documentation a bit.
- Increment the number of automated tests well beyond one hundred.
- Fix small issues.

We are especially interested in finding all missing pieces there might be with respect to the mandatory feature set.

And, of course, we are open to feedback and criticism, and will consider other features for which there is a strong demand from the community.

Beyond 1.0...

We would love to add better exception reporting...

We might have to optimize logging: we do some heavy duty logging when logging level is set to DEBUG or TRACE, a must when you are dealing with remote communications and data conversion from Javascript to JSON to Java and back.

We would like a "safe client call" mode: just try calling MyAction.myMethod( 1, undefined, 2), and you will probably be in for a surprise.
Or try returning Long.MAX_VALUE from a Java method, and check what number Javascript receives. Avoiding dangerous calls or at least emitting warnings would be nice...

It would be nice to handle individual requests in batched requests in separate threads, now that we have those nice multicore CPUs...

And there is the polymorphism issue, when passing objects from Java to JS and then back to Java...

That said, this is just food for thought, and we having committed yet to post-1.0 features.

Feedback and criticism

We are releasing this library in the hope that it is useful to the programming community.
We understand that this is the first public beta release of the library, which has been tested in a very restricted environment. Unfortunately, that can only guarantee that there is not way for it to be fully feature complete or bug free.

We are committed to making DirectJNgine a useful library. Therefore, it is only natural that we will be happy to receive feedback and criticism.

Last, but not least, we hope you enjoy using DirectJNgine as much as we did developing it.

Oops. Yes, those using JDKs older than 1.5 are stuck.
We need to address this issue.

I don't like much adding preprocessing steps to compilation, and I think that will be a must with the Apache Commons Attributes library -haven't used it though, maybe there are alternatives...

Anyway, DirectJNgine annotations are really simple, and we can do without their parameters 99% of the time. I don't think I will add complex annotations later. No need for a full fledged substitute for 1.5 annotations.

So, what about using a naming convention instead?

- Methods starting with "djn_" will be considered as annotated with @DirectMethod
For "djn_xyz" the method name will be "xyz."

- Those starting with "djnform_" will be considered as a form post method (@DirectPostMethod).
For "djnform_xyz" the method name will be "xyz."

- Those starting with "djnpoll_" will be considered as @DirectPollMethod.
For "djnpoll_xyz", the event name will be "xyz".

This solution is simple, easy to understand and easy to implement. I think this solves the issue.

If it is acceptable to everybody, I will consider it for inclusion in the next public release (0.7.3, due on Wednesday 15).