Saturday, August 11, 2012

Java Language in 2015

Consider these APIs, frameworks and patterns:

1) JNDI (Java Naming and Directory)
2) JMX  (Java Management Extension)
3) JPA (Java Persistence Framework)
4) Spring
5) DI (Dependency Injection) and Inversion of Control (IoC)

They all deal with objects (don't laugh...), with instances, as opposed to dealing with the classes these instances originate from.

Yes, it's curious that Object Oriented languages care so much natively about classes, but are very mean instead as instances are concerned, and in fact so many frameworks have been born to address this problem, since the language itself offers little support. Object Oriented language should be renamed Class Oriented language, I would reserve the the former denomination for a language that doesn't exist yet.

1) JNDI gives instances a name, a global name, so that they aren't anonimous instances anymore. While some objects are temporary, they live as long as a method executes, some other may live as long as the JVM lives. Besides, if you want them to become acquainted with one another, they should have a name.
 
2) JMX is about allowing knowledge and modification of the state of some well known objects from outside the JVM. Oddly, JMX has its own naming scheme and registry, and that's absurd: we would like to have just one mechanism to name instances.

3) Spring. It started as just a framework to initialize some instances from a configuration stored in a file and wire these instances together. It implements the DI and IoC patterns.

So, on the one hand there is some proximity with JMX, since, while the former (JMX) allows to modify the state of instances at runtime, the latter (Spring) allows to setup the initial configuration when instances are created. 

On the other hand, there is some proximity with JPA, since also JPA is able to reinitialize some instances from a stored state.

Also, Spring sports its own naming scheme and registry.

4) JPA allows to save and restore the state of some objects from a database.

5) IoC is when an instance is not created directly by the application code. The method signature 'public static void main (String []) argv' is the primordial IoC framework.  DI is when a reference to an instance is not acquired directly by writing in a program a reference assignment.


Bringing in it all together

What if.

We had just one mechanism (JNDI made simple?) to assign some well known object a name. But maybe not only a name, but also, why not, humans may enjoy a description and an icon.

We had just one mechanism (JPA?) to restore the state of instances from a known state, previously saved.

We had the possibility to modify from outside the JVM the state of known instances (JMX totally rewritten in POJO terms?)? This state could then be saved to the persistence store and it would again be there on a new bootstrap.

We could annotate a missing dependency (from an instance, not from a class!) and resolve it at runtime through a named well known object? Of course this is what Java Enterprise always had but with tons of unnecessary machinery. This shouldn't be Enterprise programming.

All this shoudn't be achievable through frameworks often not working very well with one another, it should be there at the heart of an Object Oriented platform.

PS: I've taken a look at DI and CDI. DI is fine for me. It should lie at the heart of the Java Platform. I'm more suspectful towards CDI. For example scope management smells like a workaround for bad programming practices. Event dispatching is more insteresting.








No comments:

Post a Comment