Weiqi Gao wrote: > Are we done with discussing properties? Well, it might be interesting if anyone had proposals that were more than skin deep syntactic sugar.
I haven't seen anything that really improves substantively over what one would have by some sprucing up of JavaBeans APIs and some BeanInfo-driving annotations. > Can we move on to > > + closures: BGGA, CICE, FSM, anyone? > BGGA is fine by me. I think it will hurt /almost/ as much as it helps, but let the hurting -- and helping -- begin :-) It will keep life interesting. > + generics: The Wall of Erasure? Reifications? > I thought the recent Posse episode was most curious here. They couldn't speak specifically to the implications of erasure. I wonder how many people are actually greatly impacted by erasure. I use and produce a fair number of generic APIs and have to say erasure does not hurt me most of the time. I'd certainly rather have the ability to mix and match old and new code than reification if it is an either/or choice. If there was a way to allow runtime access to generic types of instances /without /unnecessarily breaking the ability to mix and match old code (e.g. getting at the generic types might simply return 'null' when old code created the instance and gave no types), I'd be all for it, though. > + XML literals > Just say no! Next it will be literals for CSS, and my favorite non-Java niche grammar du jour. XML isn't that holy or special. > + Regular expression literals > These would be kind of nice, but are not a huge deal either. > + Multi-line strings > Yawn. The + trick works fine in my book. > + Removing wait(), notify(), notifyAll() from java.lang.Object > Yeah, right. What strange "I want to break most software of size ever written in Java" language are you living on? > + Putting Groovy into the JDK > > + Putting Google Guice into the JDK > Why? The JDK is intrinsically slow moving due to the standards process, platform porting (you have to wait years for a new JDK on the Mac or on AIX), etc. Keeping things outside the JDK keeps them faster and gives more freedom. > + Removing AWT Widgets from the JDK > Again, you just want to break software for no reason, right? Putting these in a separate lazily loaded jar, marking these as deprecated, hiding them in the default Javadoc view, etc, would be good. Removing them outright has no upside and serves only to break software. > + Removing the HTML 3 parser/renderer from the JDK > Sure, if replacing it with an HTML 4 one :-) > + Adding all 694 Apache Commons jars into the JDK, I'm tired of > getting them one by one by one by one by one.... > > + Heck, why don't we put Ant into the JDK? Maven? > No! People complain about the core Java API set being bloated and now you want to include your arbitrary set of bloat? Where things are already separate and can remain so without harm, they should be. > + And ANTLR. And don't forget to rewrite javac to use ANTLR > I can't speak to the wonders of ANTLR, but I'd generally think javac's implementation details should be hidden to allow for future flexibility of implementation. -- Jess Holle --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
