2009/8/31 Mark S. Miller <[email protected]>: > > On Mon, Aug 31, 2009 at 1:34 PM, Mike Samuel<[email protected]> > I > just mentioned in another mail, GWT, which might raise similar > problems. >> >> The function Maps.newHashMap is implemented as >> <K, V> >> public static Map<K, V> newHashMap() { >> return new HashMap<K, V>(); >> } >> so if we need to replace code with our own hand-written Joe-E/GWT >> compatible implementations, we can do that. >> >> I think we will have far more trouble reworking object constructors >> and try/finally blocks to get stuff working with Joe-E than removing >> dependencies on google-collections. >> The latter can be done with search/replace. > > I'm not sure what point is being made with the above code. If the > collections in question consist only of trivial wrappers as above > around the collections we're already using, then great. If the change > you're advocating doesn't make it any harder to transition to Joe-E in > the future, I'm happy.
It shouldn't. We can always create our own inlinings, so pull the bits we need in from Joe-E. >>> <rant> >>> As for the Java 1.5 generic type notation, many of you have heard me >>> say this verbally, but for the record: They're more trouble than >>> they're worth. Without type erasure (as in C# generics), I could at >>> least imagine myself arguing both sides. But with type erasure they >>> accomplish exactly the opposite of their claimed purpose: They make >>> code less reliable. In a pure Java 1.4 program, I knew that a >>> ClassCastException could only be thrown where a cast operator appeared >>> in my code. Starting with Java 1.5, the origin of ClassCastExceptions >>> no longer has any obvious correspondence with the notation of the >>> source code. >>> </rant> >>> >>> Joe-E addresses a real safety problem. Java generics fail to address a >>> safety problem that's mostly pointless anyway. Let's not travel >>> further from supporting good safety for the sake of failing to support >>> bad safety more efficiently. >> >> You and I disagree about the value of static type systems. > > Indeed. The mistakes that I make that I would like automated help to > catch are largely the same in statically and dynamically languages. > The work that I do in statically typed languages to satisfy the type > system is largely busy work. It rarely catches a genuine bug that > would have escaped me in a dynamically typed system. >> You're right that a suppressed type warning can cause exceptions to be >> thrown in hard-to-predict places in clients of that code, but that is >> far to say that they're useless. >> Without warning suppression (modulo some bugs in the language spec >> around type parameters and inner classes) they do make code more >> readable, understandable, and indirectly safer. > > One of the Joe-E experiments we tried is to reject code that provoked > such warnings. We found this too severe a restriction. We couldn't > write too large a range of realistic code. If we were able to live > without code that causes parameterized-type-unsafety, much of my > objections would disappear. I'm not sure I understand. We can try and get rid of our few @SuppressWarnings, but we can't get rid of any uses of it in the core libraries. > -- > Cheers, > --MarkM >
