There are palpable and real issues that are forcing (or guiding) people to create a myriad of application frameworks or treat the JVM as a target run-time platform (either via Scripting like the Groovy folks or by directly compiling to it like the Scala folks.)*
* If you think such endeavors are not needed for today's IT business, you have been living too long under a website rock. Chicxulub II might be heading your way... or not.
In the meantime, it is crunch time for me: after years of procrastination, I'm going for the Sun Certified Java Programmer (SCJP) exam this coming Wednesday (followed by the SCEA exam in a month or so). The matter of fact is that I haven't had a chance to review as much as I would want to. I've been living under the yoke of Java 1.4 for too long, oblivious to the supposed bliss of Java 1.5 (supposed bliss... more on that later.)
I'm quite familiar with Generic Programming and assertions, coming from what I consider to be a hard-core, down-to-the-bolt Ada and C++ collegiate background (oh, the nostalgia.) But the devil is in the details, and I can't underestimate the nitty gritty details and peculiarities of this new Java kludges that has befallen upon us.
Yep, kludges. I don't like Java annotations and Generics that much. They make me feel kinda icky.
Yes, I'm not that hot for Java Generics.
I can hear pundits saying "are you crazy" or something to that nature. But bear with me. For generics, it's a mild dislike. The fact that the compile performs type erasure thus turning List
That is, any method accessible through type T has to come from Object for that type of usage. This is not the same as in Ada or C++.
In C++ (and similarly in Ada):
class Dude
{
public:
template <class T> void hangout(T buddy)
{
buddy.haveBeer(); // workie
}
}
In Java:
public class Dude
{
public <T> void hangout(T buddy)
{
buddy.haveBeer(); // no workie
}
}
In fact, it won't compile at all:
$ javac Dude.java
Dude.java:23: cannot find symbol
symbol : method haveBeer()
location: class java.lang.Object
buddy.haveBeer();
^
1 error
In Java, the bloody thing equates the generic type to a plain java.lang.Object. Unlike in C++ or Ada, you can't treat the generic type as an interface contract. You can only use it to declare a generic algorithmic template limited to a java.lang.Object or a specific class or interface. It is an improvement from previous versions of Java, but that's as far as it goes.
It is pretty evident that true generics and the Java implementation are two different beasts. In Java, the only thing you can see in a generic type are methods defined by Object (or a class/interface if you explicitly name it). True generics, on the other hand, provide a type signature or contract, similar to (but not the same as) interfaces. The former is used for eliminating type casting in a safe manner. The later is to define interfaces and contracts.
It would be absolutely nice if Java were to implement generics as in C++ and Ada. And no, this desire is not driven just by cosmetics and academic pedantries. There are practical ones. However, given the constrains imposed in how to implement generics in the Java language, this will have to do.
Anyways, people still code in Java without closing database connections, so I think we have bigger things to worry. Which leads me to the next.
Now, onto Annotations.
Maybe I'm a Neanderthal. Maybe I live in the stone age. But whatever. I can still not understand why this is a good idea (right off page 21, Common Annotations for the Java Platform[tm], Final Release):
@Resources ({
@Resource(name=”myDB” type=javax.sql.DataSource),
@Resource(name=”myMQ” type=javax.jms.ConnectionFactory)
})
public class CalculatorBean
{
I mean, seriously, what the hell????
Annotations used like that are nothing more that configuration details hard-coded in your source code. This is a facility that is open to abuse, plain and simple.
I will grant the benefit of the doubt in that I'm maybe too old school. I have no problems dealing with multiple XML files to configure this or that, or to inject stuff in Spring or whatever. Maybe I don't see the grand scheme of things. Maybe I still have a lot to learn about annotations.
But as hard as I've tried, I do not see any way to inject from an external configuration source such a value on an annotation.
We have come a long way from separating environment configuration from code. Not only is the actual database IP address and port part of the environment. The JNDI name that it binds to is also part of the environment, at the container level. I'd much rather have such things defined in a external source and injected at bootstrap time.
And this is the thing: as ugly as XML configuration files are, they do the job. You can make frameworks to hide them, but there is a right way and a wrong way to go about it. Annotating configuration details on the source code is the wrong way to go about it. In a large system, and specially with the type of developers we get nowadays (the types that never close database connections), this is just asking for trouble.
I do love what annotations have done in some areas such as declaring EJBs, security roles and transaction levels. But hard-coding JNDI resource names in source code, I'm sorry, that's a path I do not want to follow. That path only leads to where it smells funny.
I can hear people saying that this is the way it should be done, it was implemented in agreement by the Java Community Process and all that. But hey, so were EJB 1.0 through 2.0. So was the idea that distributed transactions were the way to go to build everything down to that small, internal IT operations website that was to be used only by a dozen of people that connected to one single database.
Or maybe I'm wrong and I'm living in a parallel universe or something...
Posts
