Java.next
I hope you have taken the time to digest the input from my friends - Stefano, Dalibor, Geir, Tromey, mjw to name a few.
Let me layout a scenario / use case: In the future, I (either an individual or a company) should be able to pick pieces from various projects to "assemble" a JVM/JDK for my custom use or for my customers, exactly like the folks doing linux distro's assemble pieces that fit together. The Classpath project has shown how well the classlib can be center of a multi-vm eco system. We should make more choices available for all parts of the JDK/JVM, so that people can mix and match what they need.
Already there are a lot of choices. Kaffe or Harmony' DRLVM or JamVM or SableVM as the base VM, Bouncy Castle or GNU Crypto for the crypto bits, Eclipse JDT compiler as javac equivalent, *unmodified* latest Xerces and Xalan. MX4J for the JMX stuff. Not to forget the beginnings of a AWT/SWING implementation in Harmony and an almost full implementation of the same in classpath. etc. The community is testing its bits using Mauve in addition to their own test suites and Gump is helping a bit in testing coverage as well. If you followed some of the discussions on harmony-dev, we started by talking about breaking stuff down to make the bricks for the building blocks.
Why am i pointing to all these items? Because, i'd like SUN to participate in some if not all the current efforts. I'd like SUN folks to build bridges between their code and code from others in the ecosystem. Having a long term vision of say a OSGi based ecosystem where components can be custom assembled is a grand and worthwhile goal, but i'd like to propose small steps to make the grand vision happen as well. For example, Since the plan is to roll the dice with Hotspot VM. One possible bridge is for the Hotspot team to review the Classpath VM Interface and/or the Harmony VM Interface and come up with a way for Hotspot VM to work with the Harmony Class Library or Classpath. Code is important, no doubt. But it is equivally important for say the Hotspot VM team to start working closely with other efforts in the area. It will pay off in the long run for everyone. When you open source Javac, don't forget to open up the code APT as well :) I know a few projects who can benefit from that.
Oh, regarding the license? *Please* don't use CDDL, MIT/X will do just fine. Though i'd push for ASL 2.0. I think opening up the JCP and access to the TCK is as important as the license for the code. More on that later.
Thanks for asking us for the feedback. Glad to chime in with my 2 cents.