Since the past weeks, I've started to look at a small but key Java language update.

Say you have to define a service, an EJB for instance. Why should you need to do all those boiler plate code (or annotation tapestry) to get it running as a web service ? and not simply click in your favorite JavaEE server ? Well the problem is that at this time, you can not do that because : you don't have access to parameter names from the java reflection API. This lack impacts support for alternative languages such as targetted by the Da Vinci VM project.

Nammed parameters is a paradigm that exists in valuable programming languages such ObjectiveC (any iphone geeks out there ?) or some recent script languages but also on distributed invocation technologies (webservices is the major example).

There has been some discussions in the prevous JDK cycles to integrate nammed parameters, but the impact on the Java call sequence and the risk of creating an unclear toolset was to high. This could endanger interroperability and lower the Java momentum.

After studying the existing proposals, I manage to find what was wrong. They all propose one concept for two different use :

1. the need to be able to get existing parameter names "as is"
2. be able to specify know parameter names in a reliable way for new classes to use them

Actualy, parameter names are available in a non reliable way on existing classes. This depends mostly on the compiler option given during the packaging process. Hence, these data can not be trusted and should be consider as transient. But anyway, when present, those data can be quite usefull for introspection.

In order to bring reliable nammed parameters, there is a need to tag the named parameters (variable) to indicate that the name they hold is constant thru time and should be considered as part of the method contract (although not used as part of the method signature).

Some person has proposed to use an annotation. Although I like the idea, I think that there is an other possibility that is more precise and clear to most user : a modifier.

I propose to use the oldtime modifier "static" on variable to introduce the following paradigm :
If you put static on a method variable (a parameter is the main usage so far), then the compiler should ensure to keep the variable name stored in the bytecode whatever optimisation level is indicated thru a compiling option.

Furthermore, two new methods would be added on the java.lange.reflect.Method class:

1. String[] getParameterNames() :  Attempts to retrieve the names of the parameters as indicated at the bytecode level. Those parameter names should not be trusted thru times (no contract at all) and are provided only for transient usage. This returns an array of the paramter names if available (best effort).
   
2. String[] getStaticParameterNames() :  Retreive the names of static parameter of the method. Static parameters are parameter which contract includes the parameter names. It returns an array of the size matching the number of parameters for this method. Any non static parameter will null. Static parameters will return by-guaranty their names.

With such a facility, remote invocation such as webservice can rely on the second method. But are free to downgrade to then to the first method when calling legacy code.

The last change, a new common annotation would be define to specify that all the method parameters names should be kept at once (something like @Retention(value=SOURCE) public @interface ConserveParameterNames { ... } ). Indication of this annotation has the consequence to put static on all the parameter names. Retention policy would be kept at source only, because it is duplicating the static parameter paradigm without introducing any valuable runtime information.

With this small change, you can for instance annotate the @WebMethod with a @ConserveParameterNames to remove the use of putting @WebParam on each an every parameters.

This proposition neither endanger calling principle of a Java method, nor introduce complex paradigms difficult to handle. But, it does have the potential to dramatically simplifies lot of today code area : those were agility is the key.

Todays IT Architectures, security is the key stone. Something at first not noticeable, but that has drastic impact if weakened or removed. A good security, means at a high level you need at least to :

1. identify users
2. keep user's actions and data under control
3. ensure security of data transmission between ends

Todays application servers offer a secure container where to implant enterprise applications. The problem is that in lot of context, the security management is not handled at the server (corporate) level for "technical" reasons, but at the application (business unit) level.

This is a potential security issue, let's see how we can overcome this using the Glassfish V2 features ... 

Read more...

Ok, I do really need to be  more active on this blog. Too much pending articles and code examples waiting to be published.

In my next article will be around security integration issues. Since about a couple of  year, I have been working on security (mainly authentication and authorization) topics on the Java SE RI (Glassfish). Some time back I contributed a JDBCRealm, that was improved by Sun's team, but since then I am working on a new plugable realm mechanism that tries to find an easy way enterprise application can gain control on their security domain without getting rid of the protection and security offered by the container. Sound challenging ? Well, stay tuned !

Read more...