Summary
Removing features can be a useful part of keeping a language simple over time, especially as new features are added to the language. In a recent blog post, Neal Gafter asks whether checked exceptions could be a candidate for removal from Java. If not checked exceptions, then what features would you remove from Java?
Advertisement
Just how complex can Java become before new language features start to negatively impact developer productivity? That question is increasingly part of discussions about the future direction of Java. Lately, a corollary discussion started to emerge as well: If new features would make Java too complex a language, then removing some old, rarely used features could bring language complexity back into balance.
More than many other languages, Java has resisted the removal of language features for most of its ten-year history. That happened partly because the need to preserve backwards compatibility of many millions of lines of Java code outweighed the benefits of trimming the language complexity tree. If the evolution of other languages is any guide, however, deprecating language features is in Java's future as well.
The tension between adding new features and managing complexity came to the fore lately in Neal Gafter's blog post, Removing Language Features? In it, Gafter, lead author of the Java Closures Proposal, writes that,
There has been an ongoing debate on the utility of checked exceptions. Many people are critical of Java's checked exceptions, characterizing them as a failed experiment in software engineering. In practice, checked exceptions can result in API complexity, and programs appear to be cluttered with exception handling code just to satisfy the compiler. Some people believe checked exceptions are a good language feature but are misused, even in the JDK. With the "experts" being such poor role models, how can we expect ordinary Java programmers to do better?
Checked exceptions have been one of Java's core language features, and many believe that removing them would cause Java to lose one of its most powerful tools. Elliotte Rusty Harold, for example, had this to say in arguing against removing checked exceptions in Voting for Checked Exceptions:
If you do understand the difference Java’s exception handling is the single best error handling and reporting mechanism ever built into a programming language. It is a strength of the language, not a weakness. To date, I don’t think any other language has come close to matching Java’s robust exception handling, and resistance to distinguishing checked from unchecked exceptions is the reason why.
Would you support removing checked exceptions from Java? If not checked exceptions, then what's your least favorite Java language feature that you'd like to see gone from a future version of the language?
I think the biggest problem with checked exceptions is that something that can be handled in one context may not be something that can handled in another. For example, if a class in an application server can't find it's configuration file, there's not much you can do from that class and there's nothing much that the users of the class can do about it either. It's time to blow up. It's not (really) an unexpected condition and isn't a bug in the code, it's just unresolvable inside of the application.
Java 1.4 improved things a lot by allowing checked exceptions to be wrapped as RuntimeExceptions but perhaps there is a problem with the Java paradigm.
Maybe it would make more sense if the syntax were changed to make any exceptions that was declared to be thrown as checked and any that was not as unchecked. This would be mostly compatible with current Java but any code that called a method that declared an unchecked exceptions would stop compiling.
The upside of checked exceptions is that it's a concrete way of telling the user of your API that they need to deal with a condition and that you mean it. If they decide to just rethrow and don't delcare, that's their option. You lose nothing over all exceptions being unchecked.
I think most of the bad feelings about checked exceptions come from the overuse of them in early JDK libraries and the lack of a standard way rethrow checked exceptions as unchecked. It may be too late though. Public opinion seems to have damned the checked exception.
"Java’s exception handling is the single best error handling and reporting mechanism ever built into a programming language."
Actually Java's exception handling "mechanism" is pretty much the same as everybody else's and didn't originate from Java. Checked exceptions, which are merely a compile-time check, aren't part of that "mechanism" any more than parsing the keyword "try" is.
Autoboxing ints -> Integer. Since it recently came up here as causing problems. And I've encountered them :-)
As for Checked Exception, I use em, rarely. One thing that huge discussion pointed out to me is that wrapping one checked exception with another, e.g. for purposes of "layering", is likely wrong. If one layer throws a checked DatabaseException, and your Domain layer can't handle it, there's little advantage to wrapping that in a checked DomainException. Several posts made the point that this breaks OO and is just confusing and/or meaningless noise. Either rethrow the exception as is ( declaring throws IOException seems quite reasonable), or make your generic DomainException unchecked.
With CheckedExceptions, I'd like to keep them but with some restructuring of the class heirarchy. For example ClassNotFoundException, IllegalAccessException, InstantiationException, NoSuchMethodException, NoSuchFieldException, and InvocationTargetException could all share a common ReflectionException parent. I don't think a change like this would break any existing code.
SQLException could usefully have a set of subclasses, such as SQLDeadlockException (often recoverable by simply retrying) and SQLParseException.
ALternatively, instead of dropping checked exceptions altogether, perhaps the compiler could just generate a warning. It would also have to allow you to have a try/catch clause for undeclared checked exceptions.
I would drop primitives (int, bool, etc). Make everything an object. Don’t we have good enough optimizing VMs by now that will use the optimal internal representation under the hood automatically anyway?
As far as checked exceptions: I think they can still be useful. The problem is the overuse of checked exceptions by the crowd that thinks that runtime errors are somehow sinful and much worse than logic errors that happen silently.
> Ideally Java needs to remove few concepts/syntax: > > The following constructs should be outlawed: > > - double assignment int a = b = c;
Agreed. I don't see this often, though.
> - postfix/prefix ++/-- a++; --b;
Is it the different meanings that you don't like? Which one would you still allow or would both be removed?
> The following constructs should be replaced by something > more easily readable/scalable/parsable: > > - String concatenation with fake operator overloading > "asd"+a+"\n"
I've never found this hard to read. I prefer it to some others I've seen.
> - The ? operator cond?a:b
I've come to love this. But it is a little inscrutable, especially for newbies.
> I would drop primitives (int, bool, etc). Make everything > an object. Don’t we have good enough optimizing VMs by now > that will use the optimal internal representation under > the hood automatically anyway? > > As far as checked exceptions: I think they can still be > useful. The problem is the overuse of checked exceptions > by the crowd that thinks that runtime errors are somehow > sinful and much worse than logic errors that happen > silently.
What about the idea I propose above? It seems to me that the problem with checked exceptions is that you have to decide whether they are recoverable when the exception class is declared. How can a Sun engineer in 1996 or whatever know if a FileNotFoundException is recoverable in the method I am writing today? Wrapping in a RuntimeException helps a lot but it's really a clumsy afterthought.
Wouldn't making the checked-ness of the exception a part of the declaration of the method make more sense? Maybe there's something about this that wouldn't work.
>> - double assignment int a = b = c; > Agreed. I don't see this often, though.
I only saw it in case of errors. :)
>> - The ? operator cond?a:b >I've come to love this. But it is a little inscrutable, especially for newbies.
I use it a lot, very elegant and concise, but it is a special case for the compiler and grammar (forces a potentially infinite lookahead).
It should be rewritten as prefix operator, so that it is easier to parse and read. You can choose your prefferred version:
?cond(a:b) choice(cond,a,b)
>> - String concatenation with fake operator overloading >> "asd"+a+"\n" >I've never found this hard to read. I prefer it to some others I've seen.
It is not hard to read, on the contrary it is very intuitive. The problem is that it is a special case of operator overloading of the '+' operator. And a special case of implicit object allocation in Java.
This has several problems:
- performance/memory occupation: it creates lots of small objects (temporary String objects) - the operator overloading can be difficult to predict
Integer a=5; String b = "hello";
If you want to build a String, by concatenating two objects:
String r = ""+a+b; // ugly, inefficient and error prone
And by the way, the '+' operator is commutative for numbers and non commutative for Strings.
The efficiency could be improved by the compiler by implicitly using String[Buffer|Builder] or some optimization.
The operator overloading of '+' and String is a bit of a mess. Sadly there is no easy solution.
> The following constructs should be outlawed: > > - double assignment int a = b = c; > - postfix/prefix ++/-- a++; --b;
Now that Java has become a language in its own right, I agree that some things that were borrowed from C/C++ to ease the transition can be discarded. Scanning through the language spec, I've found a few things that seem to exist only for backward compatibility with C/C++: - switch statements that can only work on integer values. - non-shortcircuit boolean operators. (& vs. &&) - array primitives. With generic container types built into the standard library, I think we can do away with arrays as a primitive.
I think that the "final" keyword could be deprecated. As far as I'm concerned, it's just a flag to the compiler, which is equivalent to premature optimization in my book. As for its semantic significance on methods, I consider it arrogant for a class designer to determine, a priori, what I can override and what I cannot.
"volatile" is another compiler flag that could probably be discarded. In a multi-threaded application, a developer could assume that all relevant fields are volatile and just let the runtime system figure out how to optimize access.
"transient" doesn't need to be a syntax keyword anymore. Now that we have annotations, the serialization services could easily use an annotation instead.
Does anyone purposefully use the "strictfp" keyword in one instance and purposefully not use it in another?
The distinction between "protected" members and default package-local members could be discarded. Default access should be "protected", IMHO.
Regarding checked exceptions, I find them no more onerous than static typing. Perhaps there could be some syntax improvements that make them less obtrusive, in the same way that generics made all the narrowing typecast messiness a lot less common.
> > As far as checked exceptions: I think they can still be > > useful. The problem is the overuse of checked > exceptions > > by the crowd that thinks that runtime errors are > somehow > > sinful and much worse than logic errors that happen > > silently. > > What about the idea I propose above? It seems to me that > the problem with checked exceptions is that you have to > decide whether they are recoverable when the exception > class is declared. How can a Sun engineer in 1996 or > whatever know if a FileNotFoundException is recoverable in > the method I am writing today? Wrapping in a > RuntimeException helps a lot but it's really a clumsy > afterthought. > > Wouldn't making the checked-ness of the exception a part > of the declaration of the method make more sense? Maybe > there's something about this that wouldn't work.
I am sorry, but I don’t quite understand what exactly is you are proposing and forgive me for not trying too hard. Frankly I think some of these efforts are like putting lipstick on a pig. I sometimes really wonder what the alternate reality would have been if Sun had pushed internal project Self instead of Oak. I believe we would have more interesting discussions than talking about what can be removed from Java.
> It is not hard to read, on the contrary it is very > intuitive. > The problem is that it is a special case of operator > overloading of the '+' operator. And a special case of > implicit object allocation in Java. > > This has several problems: > > - performance/memory occupation: it creates lots of small > objects (temporary String objects) > - the operator overloading can be difficult to predict
Not on any modern JVM that I am familiar with. This was how it worked in Sun's 1.2 and below.
> The efficiency could be improved by the compiler by > implicitly using String[Buffer|Builder] or some > optimization.
That's exactly what it does. Buffer in 1.3 and 1.4. Builder in 1.5 and beyond. Actually it will also concatenate literals at compile time.
publicclass Test
{
String literal = "a" + "b" + "c";
publicstaticvoid main(String[] args)
{
String test = args[0] + args[1] + args[2];
}
}
I've seen people explicitly concat literals with a StringBuffer in the name of performance and the result is they force something to happen at runtime instead of at compile time. In addition, for concatenating non-literals, if you used + in 1.5, and then compile with 1.5 or 1.6 you automatically get upgraded to StringBuilder. If you used StringBuffer explicitly, you'd have to go through and change them to get the benefit of removing synchronization which is, depending on what the code does, often not really significant but still a bonus.
> And by the way, the '+' operator is commutative for > numbers and non commutative for Strings.
I can see why people might think this is unaesthetic but what problem does it cause from a practical stance (in Java)?
> I am sorry, but I don’t quite understand what exactly is > you are proposing and forgive me for not trying too hard. > Frankly I think some of these efforts are like putting > lipstick on a pig.
Who are you to tell me whether my pig should wear lipstick? :^)
> I sometimes really wonder what the > alternate reality would have been if Sun had pushed > internal project Self instead of Oak. I believe we would > have more interesting discussions than talking about what > can be removed from Java.
If you want interesting discussions get on the Scala mail list. They are still shaping that language.
I'm actually not really suggesting that this should be done in Java I'm more thinking about what is good about checked exceptions and if we were to create a new language with them, would it be done the same way.
I've actually not really made myself clear. What I would propose is that the concept of checked or unchecked would be removed from the exception hierarchy. There would just be exceptions.
Then when I am writing my code, if I determine that there is a scenario that the caller needs to be prepared to deal with on any given call, I declare it in the throws clause.
Then when a developer uses my method, the compiler checks whether they have some sort of handling just like it does now. The caller can just rethrow without declaring the exception and it becomes unchecked from that point on. Perhaps a shorted syntax could be added for that. Oh off the top of my head:
rethrow { s = getString(); }
Maybe I'm going too far. In any event, this is how I tend to write code right now. If I have to catch a checked exception that isn't really recoverable, I just wrap it as a RuntimeException. If I catch an unchecked exception that the caller should deal with, I might wrap it in a checked Exception (I don't do this often.)
In a nutshell, checked exceptions are a great way to communicate what needs to be handled in a way that cannot be ignored. But this is really a function of the method, not the Exception class. So the mistake of checked exceptions is the scope of the checked-ness. It's declared in the wrong place.
Flat View: This topic has 63 replies
on 5 pages
[
12345
|
»
]
Previous Topic
