JavaOne 2011 schedule

JavaOne is next week and as usual I will be there.  I'm a bit busier than usual this year, but as always I'm more than happy to get together with anyone.  In fact it's my favorite part of JavaOne, so please do reach out.

Here's my speaking schedule:

Session ID: 23166

Session Title: Meet the Experts: EJB 3.2 Expert Group

Venue / Room: Hilton San Francisco - Imperial Ballroom A

Date and Time: 10/3/11, 21:00 - 21:45

Session ID: 25244

Session Title: EJB with Meta-annotations

Venue / Room: Parc 55 - Powell I/II-

Date and Time: 10/4/11, 17:30 - 18:15

Session ID: 23423

Session Title: The Road to Java EE 7: Is It All About the Cloud?

Venue / Room: Hilton San Francisco - Imperial Ballroom A

Date and Time: 10/5/11, 11:30 - 12:30

Session ID: 25209

Session Title: Fun with EJB 3.1 and OpenEJB

Venue / Room: Hilton San Francisco - Golden Gate 3/4/5

Date and Time: 10/5/11, 13:00 - 14:00

Session ID: 19941

Session Title: CDI Today and Tomorrow

Venue / Room: Hilton San Francisco - Imperial Ballroom A

Date and Time: 10/6/11, 12:30 - 13:30

Session ID: 23680

Session Title: Apache TomEE Java EE 6 Web Profile

Venue / Room: Hilton San Francisco - Golden Gate 3/4/5

Date and Time: 10/6/11, 11:00 - 12:00

Final is my favorite Java keyword

Final is my favorite keyword and modifier in Java.  For fields, love it even more than private.  Think about it, you don't even need private on your field if it's final.  Not with a truly non-mutable data type at least, so collections and things of that nature excluded of course.

In fact I wish final was the default modifier for all my fields, variables, and parameters.  You should have to announce your intention to overwrite an already initialized object reference.  After years, I find it is a rarity.

There is nothing worse that digging through a large 500 line function and not being able to see what is changed and where.  Even more frustrating when you go to extract a method from said too-large codeblock and cannot do so easily because of the sprawled out variable declarations and initializations and the occasional "I like this variable name so I'll reuse the reference" laziness.

The trouble is it looks so terrible when used properly, which should be almost everywhere!  It looks pretty satisfying on fields, but over all parameters and variables it gets to be a little much.  It can actually make it harder to find the non-final object references.  And if you find one, was it intentional or just overlooked? Change it and find out I guess.

That is why one of my biggest wishes for the Java language is that final be the default and there to be a mutable or similar keyword for the handful of times you need it.  It would be an excellent aid to readers of your code, "watch out this thing is going to change." Compilers could even check to see if you have flagged something mutable and aren't actually mutating it.  That should be a compile error for variables and parameters, perhaps not for fields though.

Obviously we can't exactly do that ... not so directly.

We have some advantages now we didn't have when Java was created.  Annotations.  When Java was created there had to be long and deliberate thinking as to what the defaults should be.  Everyone would have to live with them and they'd last forever.  These days, however, a simple annotation or two on a Java source file could serve as a clean way to change such defaults in an obvious and documented way that can make the code in question far easier to read.  It would be syntactic sugar of course and that annotation and the defaults it specifies would compile away just as imports do.

A small bit of sugar with big payoff in ease and readability.

Reflection API gripes

java.lang.Method and java.lang.Constructor are strikingly close in concept. For all intents and purposes Constructors are little more than syntactic sugar. Yet there is no API acknowledgement of many their similarities.

Yes, they share some common interfaces and the same super class, but when you peal away the methods that are not accounted for by interfaces and superclasses, here's what you get:

java.lang.reflect.Constructor

public T newInstance(Object ... initargs)
public Annotation[][] getParameterAnnotations()
public Class[] getExceptionTypes()
public Class[] getParameterTypes()
public String toGenericString()
public Type[] getGenericExceptionTypes()
public Type[] getGenericParameterTypes()
public boolean isVarArgs()

java.lang.reflect.Method

public Object getDefaultValue()
public Object invoke(Object obj, Object... args)
public Class getReturnType()
public boolean isBridge()
public Type getGenericReturnType()
public Annotation[][] getParameterAnnotations()
public Class[] getExceptionTypes()
public Class[] getParameterTypes()
public String toGenericString()
public Type[] getGenericExceptionTypes()
public Type[] getGenericParameterTypes()
public boolean isVarArgs()

Of the methods, few are actually truly unique to that class type. Those would be the following methods

java.lang.reflect.Constructor

public T newInstance(Object ... initargs)

java.lang.reflect.Method

public Object getDefaultValue()
public Object invoke(Object obj, Object... args)
public Class getReturnType()
public boolean isBridge()
public Type getGenericReturnType()

A far smaller number, especially for Constructor. The remaining methods shared, but not accounted for in any superclass or interface, are:

Identical

public Annotation[][] getParameterAnnotations()
public Class[] getExceptionTypes()
public Class[] getParameterTypes()
public String toGenericString()
public Type[] getGenericExceptionTypes()
public Type[] getGenericParameterTypes()
public boolean isVarArgs()

These methods are just begging for an interface. Perhaps ParameterizedMember would be a good name?

Granted most Java development doesn't involve the reflection api, but those of us that do use it would really appreciate being thrown a bone. Especially with the growing amount of code and APIs that involve annotations. An interface similar to AnnotatedElement that can contain this critical getParameterAnnotations method would just be wonderful.

I'm quite certain there must have been some kind of debate. Likely one that ended in, "it's not really that important." Would love to hear from anyone involved.

I personally can't think of any downside to allowing us developers who deal with the guts of supporting annotation based APIs to get a little polymorphism in this are of the reflection API.

A bottle of my favorite rum to whomever can get this into Java 7.