Java, I Would Like To See…
Everybody knows I really love Java, and I’m a real fan of the new(ish) generic type features in Java, but as I mentioned last time, I have some problems with the way they handle reflection. Well I have some other problems with Java as well, problems major enough to make me a little angry, but not big enough to make me even consider switching. This post will just outline some of the things I would like to see implemented in future Java implementations.
I understand the high Java council has probably encountered and considered these suggestions in the past. They may have plans to implement them at some juncture, or they may have decided that they are bad ideas. I’d like to preface this post by saying that I really do love Java, and this is NOT a post about any Java weaknesses. Just some things I occasionally wish I had…
One of the beautiful things about Java is that the language is so elegantly extensible that these features are easy to implement in Java without changing anything whatsoever. The issue is that these work-around solutions can sometimes be unnecessarily verbose.
What would be really nice would be for Java to allow programmers to modify the syntax of Java to provide shortcuts to workarounds like these. I think this would significantly improve developmental flow, and wouldn’t need to be more complicated than running a regex-matching engine at compile-time to replace some things with some computed values. Something like that doesn’t necessarily need to be a Java-native feature but could even manifest itself as an Eclipse plugin.
I certainly understand the potential pitfalls of such a method, with regards to standardization and collaboration in large groups, but it’s something to consider at least for its novelty value.
Parameterized Type Reflection
This is what I wrote about last time, and I provided a work-around using the factory pattern. Of course, while the factory pattern is a generally accepted means of object-instantiation, it is not entirely natural to programmers who generally use constructors more often.
The problem occurs due to the fact that when an object is parameterized using Java’s generics, the information about how it was parameterized is erased at run-time. While in general, this is usually not a problem, it has twice vexed me when developing interesting libraries (genetic programming and MVC).
Another issue you see in real practice, which is a kind-of annoying result of this run-time parameterized type erasure comes from casting.
When you want to cast something like:
List< String > stringList = (List< String >) other;
You get a warning of “Type safety: Unchecked cast from Object to List<String>.” This is a really annoying obvious result of not having this information at run-time, since there’s no way to throw a class-cast exception if you don’t know what class is there! And I don’t know about you, but I never let warnings creep up in my code for too long, so I end up with all kinds of @SuppressWarnings(“unchecked”) all over my code, NASTY!
I am told that C# does a better job with this, but come on Java, can you give me a really good reason why you aren’t doing this?
See my last post for my workaround to this issue. As far as a proposed syntax goes for improving this feature, I would just like to see some type of methods in Java.lang.class for accessing the parameterized types.
Typesafe Tuples!
Tuples are a concept that creeps up in a number of programming languages. I first learned about them in a class about oCaml, but they are in Python and I’m sure a huge number of other languages. The basic idea is that you can refer to a pair (or triplet or n-tuple) of values, each with its own independent type.
Tuples allow you to return more than one object without having to wrap the result in some other class. I can see why Java might have resisted doing so, since you lose a little bit of information about what each value means when you use Tuples. Using a class with named fields, on the other hand, lets you know exactly what you’re getting.
But sometimes, it’s just inconvenient to have to create a new class every time you want the utility of returning more than one piece of information. Type-safe tuples are really easy to implement on your own, but if you’re even too lazy to do there, there’s a library for it.
This solution can just be pretty verbose. There is a paper with some proposed syntax here. You’ll need ACM portal access to view the document. The specific syntax does not really matter to me, but something convenient would be nice.
Customized Auto-(un)boxing
One nice feature that recently crept up in Java was the auto-(un)boxing feature for converting from primitive types to their boxed object types. For instance, the following code is now legal and behaves as expected in java:
int n = new Integer(5); Integer x = 4;
This is a pretty convenient feature in object-oriented programming, but I would like to see it optionally applied to classes that you create. Here’s what I mean, with regards specifically to my MVC library.
I have a class called Path. One of the constructors of path takes a String as a parameter. For convenience though, most methods in my library that can take a Path as a parameter, will have an alternate method that takes a String, which is simply parsed and converted into a Path. Right now, I have to write two methods every time I want to refer to a Path, one which takes Path and one which takes a String. However, this results in a lot of duplicate code, documentation, and is generally wasteful in terms of effort.
What I would like to see, is some kind-of default conversion for situations like this. Tell Java that anytime I’m expecting a Path and I get a String instead, do some logic to convert the String into a Path. It’s as simple as that.