Timeframes... Humm... Initially I would like to start with a set of jdk7 repositories, go as far as we can with that, hopefully show some major improvements in overall build time, then set it aside for potential inclusion into jdk7u2 (that would require lots of verifications that the end results are the same), and then move it into jdk8 work and setting up for module building.
-kto On Apr 29, 2011, at 9:30 PM, Georges Saab wrote: > Hey Kelly, > > One thing that might be useful is to understand the kind of timeframe you > are thinking about for this project? > > /GES > > On 29 apr 2011, at 16.05, Kelly O'Hair wrote: > >> >> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote: >> >>> On 26/04/11 15:54, Kelly O'Hair wrote: >>>> >>>> >>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote: >>>> >>>>>>> >>>>>>> * Allow for use of more portable build tools (compilers etc.) where >>>>>>> possible >>>>> Can I add support for alternative JVM's ? >>>> >>>> Seems a bit out of scope to me. >>>> >>> Sorry, it was a bit of a flippant one liner, I owe you more details. >>> >>> There are three usecases I see that require the OpenJDK build process to be >>> modified to accommodate: >>> >>> The first is bootstrapping a build. I'd like to be able to build OpenJDK >>> on a new platform without the need for a previous SDK build to be present. >>> In this usecase it's possible that an simple interpreter based JVM would be >>> sufficient (ie Zero) (or even maybe a cross compiling mode) >> >>> >>> The second is getting OpenJDK to build on a platform where a hotspot JVM >>> doesn't exist and may never exist. As you guess I'm thinking of IBM >>> platforms specifically. I'm don't expect to port Hotspot to AIX so I need >>> to be able to make the OpenJDK build work with J9. >>> >>> The third (a variant of the 2nd) is where another JVM vendor wants to get >>> OpenJDK working with their JVM - regardless of the availability of a >>> Hotspot JVM on the target platform. >>> >>> To be clear. I'm not suggesting that this project step up to defining the >>> interfaces between JVM and classes. This is simple pragmatics. The >>> Hotspot JVM is the starting point for the mould and I would expect to make >>> J9 (or any new JVM) fit into it as much as possible. However there will >>> be changes needed. These are mostly simple, like parameterising JVM >>> command line options, to the more complicated like separating out JVM >>> intrinsic classes such as String.java, Object.java, Thread.java etc so >>> that the right versions get build and packaged. >> >> I certainly can understand these needs, but it is still seems beyond the >> initial scope of this project. >> Maybe in a phase 2? >> >> -kto >> >
