I guess my point is that we should remember what the world was like back then. :)
I agree that the runtime APIs are dated. Their design is around 15 years old now. I do think that backwards compatibility is a holy grail because of the benefits it provides, but it can be implemented in other ways than 'never remove any api ever'. If we had had VM & language level modules in, say, 1999, with on demand loading, then we could have evolved the apis far more gracefully than we have done. Still. Better late than never. We've still got a few more decades before the JVM is obsolete. :) - j On Aug 6, 2009, at 1:48 AM, Peter Becker wrote: > > Josh, > > Sorry if it sounded like I think JDK developers aren't too clever on > average. But fact is that the JDK is often used as an argument why > something should or should not be done, and I believe that is a bad > idea > in most cases. Casper's claim was a case of that IMO -- saying that > since the JDK authors got exceptions wrong they are too hard doesn't > make much sense to me. These were new beast and thus more likely to be > used in a sub-optimal fashion. > > Having looked at code I wrote much less time ago I would not judge a > programmer's skill on old code anyway. I do blame Sun for letting the > JDK get that old, though. Backwards compatibility might be a nice > thing > to have, but it is not a holy grail. Maybe some of that came through > in > my mail :-) > > Peter > > > Joshua Marinacci wrote: >> 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 <[email protected]> wrote: >>>> >>>> >>>>> On Aug 4, 11:30 am, Casper Bang <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
