Josh, While I agree with you, I think sun can't ignore the fact that they need a java that will last 10+ (or more specifically the VM). I personally plan to punt Java as much as possible in favor of languages like JavaFX, Groovy and Scala. With the new modularity, I see this becoming an even easier/better solution than it is currently, and I'm glad sun is focusing on it.
When folks are arguing over which language features need to be in java, I can't help but think "Why Bother? Just use Scala" (as was coined by Alex Cruise). My only wish is for a standard closure-like collections library that all the other languages for the JVM can design to, and therefore become interoperable via the "java core" collections. This way, even if java the language becomes somewhat stale, the JVM is still vibrant and active and multi-lingual! - Josh On Wed, Mar 4, 2009 at 3:56 PM, Joshua Marinacci <[email protected]> wrote: > Is that really the number one missing feature in Java? :) > Here's my take on Java 7 and what's going in (and isn't). [keep in mind, > while I'm a Sun employee this is still just my opinion]. > > 7 is Java's SnowLeopard. Java 7 isn't about flashy new features. It's > about cleaning up infrastructure and laying the groundwork for the next 10+ > years of the Java platform. That's why modules is so important and closures > isn't. Closures are definitely important, but it's something we can add > once we have new groundwork. Things like modules, the G1 collector, dynamic > method dispatch, and the applet/webstart changes are the big things that > prepare the platform for the future. Once that's all in place we can focus > more on the new apis and new language features. Coin is for addressing the > low hanging fruit that won't impede the big infrastructure work that is the > real focus of Java 7. > > - Josh > > > On Mar 4, 2009, at 11:04 AM, Josh Suereth wrote: > > > http://commons.apache.org/lang/apidocs/org/apache/commons/lang/StringUtils.html#join(java.util.Collection,%20char)<http://commons.apache.org/lang/apidocs/org/apache/commons/lang/StringUtils.html#join%28java.util.Collection,%20char%29> > > I think this is something like what Reinier wants to see in String. > > On Wed, Mar 4, 2009 at 1:46 PM, Joshua Marinacci <[email protected]> wrote: > >> >> what does String.join do? >> On Mar 4, 2009, at 7:30 AM, Reinier Zwitserloot wrote: >> >> > >> > Yeah, breaking changes - no chance, at least not for java7. >> > >> > But, there are plenty of API things that would be great to have, and >> > are forwards, backwards, migration, upwards, downwards, sideways, and >> > any other direction - compatible. >> > >> > For example, String.join. I mean, really, now. How can java make a >> > straight-faced claim of 'batteries included' without it? >> > >> > Last I heard, there's going to be a project-coin-like project for API >> > additions. Can't find the source (probably Joe Darcy's weblog at >> > http://blogs.sun.com/darcy/ but I can't find it after a quick scan of >> > project coin-related entries). >> > >> > I assume it won't be launched until at least Project Coin's submission >> > deadline passes (April 1st), but that doesn't give much time for API >> > additions. Then again, something as simple as String.join is coded up >> > and explained fully in a proposal in like an hour. >> > >> > >> > >> > On Mar 4, 9:53 am, Josh Suereth <[email protected]> wrote: >> >> Perhaps just making Cloneable and Serializable annotations, while >> >> deprecating the interfaces? >> >> >> >> Although the interfaces will probably not be removed before 1.8 or >> >> (dare I say it) 2.0, it would at least encourage using annotations >> >> the >> >> way they are meant to be used, and interfaces as, well, interfaces! >> >> >> >> Sent from my iPhone >> >> >> >> On Mar 4, 2009, at 3:12 AM, Joshua Marinacci <[email protected]> >> >> wrote: >> >> >> >> >> >> >> >>> On Mar 3, 2009, at 10:48 PM, Mark Derricutt wrote: >> >> >> >>>> Hey all, >> >> >> >>>> Project Coin is all about small language changes for Java 7, whats >> >>>> the >> >>>> changes of getting a project setup for "small interface/object >> >>>> changes" (although these could be breaking..) to fix some >> >>>> reallllllllllly annoying marker interfaces, i.e.: >> >> >> >>> You are unlikely to ever get a breaking change into core java. On >> >>> the >> >>> other hand, having modules in the language and JRE opens up some new >> >>> possibilities. >> >> >> >>>> * Add clone() to the Cloneable interface, and make Object's >> >>>> implementation abstract (or remove it compleately!) - make all >> >>>> classes >> >>>> in the JDK that implement clone(), implement Clonable (if they >> >>>> don't >> >>>> already) >> >> >> >>>> Is this a crazy idea (quite likely its absurd, but so is Cloneable >> >>>> NOT >> >>>> having clone() as a method. Any other stupid things like that >> >>>> could >> >>>> be cleaned up (even if they might break a few things along the >> >>>> way?) >> >> >> >>>> ...and then Buffy staked Edward. The End. >> > > >> >> >> >> > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
