by Steven J. Owens (unless otherwise attributed)
Yes, most of this is syntactic sugar.
But then again so is a lot of most of what you find in any programming language.
My main reason for each of the features in this wish list is to get rid of the trained-monkey programming and focus on the problem solving. Some of these fall under the "Didn't we invent programming to solve this sort of problem?" category, while others would make it easier to express programs more clearly.
Since I first wrote this, we now have autoboxing and generics, which makes this particular rant a little less relevant, but those are still less-than-great solutions.
Why the heck should I have to wrap integers in Integers and map arrays into Vectors when I want to use them with other objects, then pull them out when I want to use them with normal primitive operators?
I would just always use the wrapper classes, but using OO nomenclature for things like addition and multiplication is a pain in the ass. I seem to remember reading somewhere that the reason Java's creators gave for not including Operator Overloading (as well as multiple inheritance) was that most of the time people only used it to complicate matters. Well, maybe a good alternative would be to add some sort of limited support for operator overloading, maybe only in offical java APIs or extensions. Then override the operators for the primitive wrappers and I can just always use the wrapper classes and ignore the primitives (and count on the compiler and/or Hotspot to optimize properly).
We have implicit constructors, why not implicit accessors? The compiler should just add standard JavaBean style get/set methods for instance variables. Translate "instance.blah=3;" to "instance.setBlah(3);", translate "instance.blah" to "instance.getBlah()".
Sure, implementing a new class for a return value isn't rocket science, or I could return an array or a vector or a hashtable. But it's a pain in the ass to implement a special little return value class for every situation, not to mention adding a zillion little files to your code and your jar.
As an alternative to multiple return values, some sort of generic error-handling approach would be nice. The biggest reason for wanting to return multiple values seems usually to be able to return both a response and some sort of indicator about the respose, i.e. an error flag. Exceptions are expensive to use and I keep hearing "Exceptions are for exceptional situations". So I shouldn't use them when I'm simply returning a valid (if not necessarily useful) error condition. Some sort of middle ground would be useful.
In a related vein, I've heard that it's poor style to return null to indicate an error, but if so, then what's the appropriate way to handle the situation? And why do so many classes in the java API return null?
I've heard/read rumors that one of Java's creators has publically stated that he wished they'd included multiple return values, but I haven't come across a verifiable reference.
Found it: "There have been a number of things -- like, for example, multiple return values -- that these days I kind of wish I had added. That was one where I really liked the feature and most other people just sort of went, "Huh?" " The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James GoslingAlright, I admit this feature isn't clearly articulated, yet. On some consideration, the whole subject area of Interfaces, Abstract Classes, Inner Classes seems kind of incomplete or vague. Maybe the need for this feature could be served by a combination of inner classes and implicit delegation (see below). Meanwhile, here's my struggle to articulate the idea:
I can't count the number of times I've opened up a class file produced by some tool or developed in some "helpful" IDE, or cracked open the API docs for some class, and cursed the fact that methods are listed alphabetically instead of logically. Of course, if you're trying to locate the description of a specific method you already know about, having them listed alphabetically is slightly more useful. Assuming you don't have a halfway-modern web browser that supports searching a given page.
However, much more often I'm looking at a class for the first time and trying to figure out where everything is. It'd be really, really nice to have some formal way of specifying groups of methods and instance variables in a class for different purposes. One way of doing this would be to use interfaces - lots and lots of interfaces. In fact it would be really cool, in my opinion, if you had to always compose classes of private interfaces (even if you had a "miscellaneous" interface for each class).
Of course this would multiply the amount of monkey-work you have to do to set up each class. So instead of having to define a separate set of method signatures, why not just have some sort of way to define a set of methods and instance variables as interfaces?
Turn it around for a moment. One rule of thumb I've picked up is to start by thinking about classes in terms of the roles they play - and the associated interfaces. In theory you should be able to sort that out clearly later on, but the fact seems to be that people don't bother to do so. The fact that many classes don't have clearly-enough defined interfaces might be a hint that either the class libraries need to mature a bit, or that the interface concept is a bit too weak, or at least too poorly understood.
I see advice all the time to "use delegation/composition instead of inheritance". It's good advice; it's usually easier to break a problem down and solve parts of it with existing classes than it is to come up with a class that solves all of the problems. Instead of implementing your own version of Hashtable with added features, just add a Hashtable instance variable to your class.
But the problem with this is that once you use composition or delegation, you now have to implement a ton of methods that mostly boil down to calling the exact same method signature on the delegate. Once again, a lot of monkey work that doesn't need to be there.
Of course, one issue is that you don't necessarily want to expose all of delegate to the prying eyes of the outside world. Usually if you want the delegate to interact with the outside world, you only want it to do so in a limited role. However, much of this would be addressed by using Implicit Interfaces (see above). The delegation mechanism could specify which interface (implicit or explicit) to delegate.
There's an interesting article exploring some of the issues of this at:
Adding Delegation to JavaEvery time I need to do an SQL query through JDBC, I need a dozen lines or more of scaffolding. It seems especially awkward to work around, to come up with a good, object-oriented design. Pretty much the standard approach that I have seen and use is to put all that scaffolding cruft in some class, map the results to data objects, and otherwise ignore the cruft.
I know this isn't necessarily an easy problem. But if the pattern is that prevalent, maybe it there ought to be an easier way to handle it.
The java data types and java.sql data types don't map cleanly from one to the other. There are some confusing name differences as well. Leaving all of that aside, there is more than enough gotcha-prone tediousness involved in mapping from one to the other. Considering how often you have to do this in any non-trivial application, it ought to be easier. Again, not necessarily an easy problem, but it certainly doesn't have to be this hard. How about we start with this:
every java.sql type ought to have constructors and mapToFoo methods that take or return the corresponding appropriate java types.
In a lot of odd nooks and crannies, the java API is annoyingly inconsistent or incomplete. This is a partial list of some of them that I've noticed. Some of the problems (Hashtable accessors vs. Vector accessors) have been improving, bit by bit. Some have been fixed in the last few go-rounds of the JDK, hopefully even more will be fixed as time goes by.