Kevin Bourrillion, one of the creators of Guice, has written an excellent post on the subject of typesafety.
There's a seachange going on right now in the Java world that is taking Java, in some sense, in /exactly the opposite direction/ that people championing dynamic languages might expect. With language innovations like generics and annotations, we can now express so much more in a typesafe way, and get so many more benefits from static code analysis.
In pre-JDK5 days, we worked around the lack of support for a declarative mode of expression by embracing XML for all kinds of tasks, and convincing ourselves that this was a good thing: we were supposedly making our system more configurable
. But, of course, we've now realized that XML is just code - or rather, that /code is just text/. And we've realized that by making too many things configurable
, we merely make our system easier to break, and more difficult to change in meaningful ways. Our obsession with configuration
crippled our refactoring tools.
The challenge now is to marry dynamic behavior with this new, typesafe, mode of expression, proving that systems that can be understood through static analysis need not be /too static/; that we need not pay for precision with tight coupling and verbosity.
Interesting post.
The challenge is in fact to come up with an accurate way of modelling in XML, so that dynamic types and behaviour can be introduced into application development environments in a type-safe fashion.
This isn't just a Java problem, it applies to all modern application development environments.
perhaps this should evolve out of the modelling standards, such as XMI... this would help realise the dream of MDA.
Interesting post.
The challenge is in fact to come up with an accurate way of modelling types in XML, so that dynamic types and behaviour can be introduced into application development environments in a type-safe fashion.
This isn't just a Java problem, it applies to all modern application development environments.
perhaps this meta-model should evolve out of the modelling standards, such as XMI... this would help realise the dream of MDA.
@Lee The MDA dream is already here, and WebBeans is going to put a JSR on it. With Annotations, and especially your own project Annotations, you can stereotype, inject behavior driven by architecture decision (MDA operations), and all this directly in your Java Code and a Typesafe way. You can look at MDA is dead it shows what I mean. And for info, I'm so happy, Spring XML nightmare did not live on...
As usual, you hit the nail on the head. I once worked on a web app (circa 1999) that used a home-grown XML to define procedures for getting the dynamic data (also in XML form) of each page. Then we used XSLT to render the page. There were lots of grand plans for that non-technical people would be able use to build these XML page definitions and extend the interface. Instead, our design just made it harder for actual developers to build pages, and the never materialized.
What a mess!
I hope to see more typesafe features in Java 7. Why not typesafe accesors for reflection objects? For example, MyClass::setName(String) would return a Method object representing the setName(String) method. This would useful in combination with annotations.
A mapping reference like @OneToMany(mappedBy )
would be expressed as @OneToMany( mappedBy Person::getName() )
doing a more typesafe signature
Putting aside the performance and optimization challenges that still lie ahead for the project, I feel that Groovy is the ideal approach to accomplish this goal. With Groovy, you get the typesafe features (annotations and generics) and oust of all the bonehead crap in the Java syntax that just wastes time and leads to cursing.
Well, I find Scala is expressive as Groovy and typesafe as Java. I hope Scala appears soon in the main stream.
@Andres Like you, I'm really missing type safety on Getter-Setter (
So, I wrote Type safe Reflections about and wrote a patch for OpenJDK to support type safe reflections using . I found out that can be very useful for strongly typing JPA NamedQueries, too many strings there, or Component scopes and types. Have a look.
That would be wonderful, but I suspect it is unlikely in Java 7. :-(
Wouldn't you be better off just avoiding reflection?
You want to pass around something that has a getName(String) method; thats what interfaces are for.