For being written in the early 90s I think the std libs are pretty good. By comparison the C world was still using things like creat (ENDLESS_CONSTANTS_YOU_CANT_REMEMBER_HERE). The bar on standard libs has been raised in the last 15+ years *because* the Java runtime was so good.
A lot of the stuff you are complaining about things that we all recognize would be changed if we were doing it all over again from scratch, but can't change due to backwards compatibility concerns. ex: Thread.stop() was deprecated pretty quickly. On Aug 5, 2009, at 1:38 AM, Peter Becker wrote: > > Casper Bang wrote: >> Yes, evidently even JRE library authors weren't blessed with enough >> skills to use exceptions the right way which begs the question, is it >> really worth the trouble? >> > The JRE library authors... > - derived a stack from a vector > - mangled util classes with pretty much all the rest > - couldn't figure out how to model object identity properly > - took nearly 10 years to figure out String.isEmpty() is common enough > to warrant a convenience method > - never heard of a bag > - don't know if things should have a length or a size > - thought Thread.stop() would be a good idea > - reused FileNotFoundException and OutOfMemoryError when convenient > - avoided exception hierarchies like hell > - hardly ever documented nullability > - still don't grok the power of lazy evaluation > - seem to think a Design Pattern is an appropriate solution to a > problem > - ... > > The JRE libraries are on average mediocre, if not worse. They set a > bad > example for all Java programmers. > > It's not all bad, but there is some pretty bad stuff in there. Not > using > checked exceptions in a sensible fashion is one of the lesser problems > and possibly one of the most excusable ones -- after all there was no > real precedent for their use. > > Checked exceptions are a way of documenting what your code may or may > not do -- both for humans and tools. Done properly they can work very > well IMO, and the fact that they break things at compile time is a > positive thing for me. And of course you can't overload them -- after > all they are in many regards like a return type. Even if the JVM would > keep them around they would still not be part of a method's signature > and thus not allow overloading. > > Peter > >> If you have a nice public API people are calling, how are you going >> to >> maintain/extend this with a new checked exception type? The minute >> you >> touch a method signature, you are breaking each and every existing >> callee - and you can't simply overload the signature because >> internally the JVM has no concept of checked exceptions. It just >> seems >> like checked exceptions excel at derailing me from my standard path >> of >> thinking, this is perhaps most visible when dealing with reflection >> and I/O. It can also be spotted when commenting out a call to a >> method >> that throws a checked exception, where the compiler requires you to >> also comment out all exception handling code. >> >> Meanwhile, tools and IDE's are more than capable of warning >> developers >> against unhandled exceptions (deviations from the standard path which >> are really just glorified goto's). >> >> /Casper >> >> On 4 Aug., 18:39, Alexey <inline_f...@yahoo.com> wrote: >> >>> On Aug 4, 11:30 am, Casper Bang <casper.b...@gmail.com> wrote: >>> >>> >>>>> Well, C# has many great features. However, it is a pitty that C# >>>>> has >>>>> not checked exceptions. >>>>> >>>> To restate Fabrizio Giudici from earlier, it's funny how one mans >>>> feature is another mans bug. While they can occasionally be useful, >>>> the debate is over. Checked exceptions offers more drawbacks than >>>> benefits, especially in how they pollute the signature and leak >>>> abstractions. No other language introduced them before or after >>>> Java >>>> for the same reason. >>>> >>> It seems to me most people have a problem with the way checked >>> exceptions have been used, rather than the concept itself. After >>> all, >>> in Java, we can use both checked and unchecked exceptions, but >>> perhaps >>> the debate about when to use which didn't take place early enough in >>> the language's development. I feel that when properly used, checked >>> exceptions actually prevent leaky abstraction situations and >>> unchecked >>> exceptions can lead to them. >>> >>> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
