Over complication?

I was reading one of the links that I get as RSS sent from Ragawald today about JSR-308 (What hath java wrought). This JSR describes some additional annotation on types that would extend the java type system allowing the compiler to do some more static checking work for me. There was a further breakdown explanation that was linked off the "What hath java wrought" article that is also worth reading for a good background on what this JSR could translate into. The additional write up is on Wide Awake Developers titled When Should You Jump? JSR 308. That's When.

Dynamic vs. Static

SO - I took a little dive down The Rabbit Hole, as I am apt to do, and followed a bunch of links on JSR-308. To be perfectly honest I am greatly disturbed by the information that I found. There has been a great deal of discussion about Dynamic languages, static languages and languages that are mostly static taking on some of the dynamic language goodnesses (or vise versa). Both sides (static and dynamic) have some relativly cogent arguments about why their thing-a-ma-gigger should be the one that means the most to the most programmers. Personally, as I have stated in the past, I am a "use the best tool for the job" type of person. Not only that, but I tend to try to bring in the stylistic flavor of other languages into the language I am using at the time, often mixing styles and metaphores as I go. Both arguments are powerful and at the same time equally pointless in the face of just being simple and getting done what you need to get done.

So, in terms of the JSR specifically, let me say that I am disappointed because the JSR I don't think is bringing anything of intrinsic value to the java language. This may be because I am looking for inherntly simple things or it may just be that I am personally a simpleton but lets assume that I give / gave myself the benefit of the doubt in this case. The title of the JSR-308 says the following:

"JSR 308, “Annotations on Java Types”, enriches the Java annotation system"

which I will admit on the surface seems simple, but it SOOOOO very much implies so much more. This JSR would allow the common coder to add annotations on java types and even further would allow the common coder to supply an annotation to a generic type as well. Some people would consider this to be progress... I am personally not so sure. Take the following example shamlessly pilfered from the "Wide Awake Developers" site:

void marshal(@Readonly Object jaxbElement, @Mutable Writer writer) @Readonly { ... }

Can someone please explain to me what this line would mean to some other class in my code? Better yet can someone please explain what are the potential outcomes of having a line like this in my code in an effort to "improve" my overall codebase?

If I had to guess someone can probably explain to me that the @Readonly is telling me that jaxbElement will not change in the method context. They can tell me that @Mutable is telling me that the 'writer' variable will change in the method context and that the second @Readonly is telling me that the method itself can only be called by something else that is also marked as @Readonly. Holy CRAP is that an amazing amount to remember about a single method.

Now I can hear a bunch of people sputtering that this feature would eventually find its way into being managed by the IDE's we may all use and love. I personally say that even if it does, that the value introduced by these new annotations is/will be lost on most people.

K.I.S.S.

One of the first things that I learned in programming and IT in general is that one should always keep a level head and try to look for the simple explanations and simple ways of doing something first. Keep It Simple Stupid is what I was always told. I came to understand that for the most part this old adage holds true. Granted that there are times where it is not always possible to do, maybe it is a particularly hard algorithm that needs implementing or other such item - but even in those cases attempting to be as straight forward as possible will help the person that follows you up in attempting to maintain and support the code. The addition of these new type annotations I do not think is in the vein of KISS. I think that this new JSR is about attempting to solve an ever smaller set of 'potential' coding issues (bad nulls, modifying variables you didn't intend and the like). The value proposition I just don't feel is there.

Specifically I think that this JSR is heading in the wrong direction. While most newer languages these days are heading in the direction of being more dynamic, more human readable and human understandable - this annotation JSR moves java in the other direction. We all know programming is hard but do we really need to make it even more so with something like this? This JSR raises the barrier to understanding what the code is doing in my opinion, lowering the overall understanding of java programmers of how their system works. Keep in mind that we have some other already complex things to solve... things like understanding multithreading and keywords like volatile better, maybe even adding some better multicore-multithreading support into the language... instead and to my dismay we as a community are out there attempting to solve a little niche of a problem. Granted the types of problems that this can solve are plenty hard to find and debug - but for an experienced programmer they are a small amount of an overall codebase.

SOOOO... How does one interpret...

Think about the interpretation of the example line I provided. I once said programming and being intuitive was all about memory / context - the idea of being able to hold in active memory about 7 +- 2 things, if I have to hold onto MORE then 7 items just to interpret what a singular statement is attempting to do and not even a statement per se. but a method declaration - I believe that I have bastardized the language. Why work to make it so hard for someone to just "Grok" what is being done that it is not worth the time it may take to learn to use the new feature. I would venture to say that it may be so hard to use this potential new feature 'correctly' that most people will just skip it altogether, being intent on what they know and understand. It will take the avg. person so long to make good use of the new feature that the language may be long dead before someone really makes it part of the main stream of development in java.

Should people start to think about learning a new language? I am not sure if that is the message I would want to convey (the blogs I linked in the first part of this message think so). I would rather convey that there is power in numbers and power in voices - if you like me think that this is a rather SORRY direction for the language to be heading in over all... SPEAK UP and say so. Send sun messages, get involved in the JSR project and get this sort of thing derailed before it starts. Other wise, the language you are working in right now my go the way of M code, or Cobol.