2009/4/20 Tim Ellison <[email protected]>: > Alexei Fedotov wrote: >> Under resource constraints we may even think of dropping Java 5 in favor of >> Java 6. This would save Java 6 supporters their merge efforts and nullify >> merge bugs. > > Maybe. I hadn't thought of going that far - at least, not without a > reasonable overlap period that allows people to migrate from 5.0 to 6.0 > stream. > > Given we don't make a big deal of publishing the 6.0 stream code today, > I think it would be unreasonable to abandon the 5.0 stream abruptly. We > may well get to that point over time. > >> Why have not we done that before? AFAIK, one wanted to pass TCK for Java 5, >> and that was an important step to ship Harmony release, which in turn was >> important to officially participate in benchmarks. I don't think this plan >> would fail due to 5% more failures we got due to Java version >> incompatibilities. There are stronger risks, e.g. TCK absence. > > I agree, and that is why I'm proposing a different approach for the 6.0 > stream. Rather than shoot for 100% completeness to the Java SE 6.0 API > and request that TCK, I suggest we select a number of Harmony modules > and publish a useful 'select' runtime. With our architecture it is then > trivial to expand out with the additional modules to reach the full SE > in time. >
Good thoughts. A minimal core of the runtime at 6.0 level is easier to achieve - it brings less effort than delivering the whole Java6. And then the other modules could be added in on demand when they are ready. I believe it is also a good experiment on modulization. Besides that, one of our GSOC project is the OSGi on Harmony, maybe we can think about building this core runtime on OSGi. > Regards, > Tim > >> On Fri, Apr 17, 2009 at 6:12 PM, Tim Ellison <[email protected]> wrote: >> >>> Sian January wrote: >>>> I agree that we need to be more timely about the next milestone. >>>> >>>> It would also be good to focus a bit more on Java 6 since Java 5 is >>>> starting to become old. Maybe we could do a Java 6 M1 (or subset as >>>> you describe) to coincide with Java 5 M10? >>> I'm not too bothered about the 'age' of Java 5. IMHO there are not too >>> may apps that have a hard dependency on Java 6 APIs yet; but we have got >>> some technology in that branch that, at the moment, does not see the >>> light of day and that is a shame. >>> >>>> On another note, I would also like to see us get up to 100% pass rate >>>> for the class library tests and then keep this going - i.e. if a >>>> commit causes any tests to fail then it should be fixed asap or backed >>>> out. I think this would have helped us avoid some of the issues that >>>> caused such a long stabilisation period for M9. >>> Agreed. Having build/test systems visible in the ASF infrastructure >>> would help. There has been some discussion about getting separable >>> tests, but even if that does not come about we could extend Hudson to do >>> a full build/test cycle too. >>> >>> I expect that we will have problems getting platform coverage from the >>> ASF Hudson systems though. AFAIK they are all Linux x86_64 machines. >>> >>> Regards, >>> Tim >>> >>>> 2009/4/17 Tim Ellison <[email protected]>: >>>>> Immediately after a release is usually the time that I'm thinking about >>>>> lessons learned, the project road map, and future deliveries from >>> Harmony. >>>>> Most noticeable for me was the long stabilization period we undertook >>>>> for M9 compared to earlier releases. This was required, I believe, >>>>> because of the longer open development period [1]. The lesson to take >>>>> away from that is to ensure we keep an eye on our regular release >>>>> schedule and keep the time boxes short enough that stable fixes get out >>>>> to our users, and we minimize the frozen codebase period. >>>>> >>>>> Looking ahead I'd therefore expect 5.0 M10 to be released at the end of >>>>> May (6 weeks after April 8th = May 20). >>>>> >>>>> >>>>> The other thing that bothers me is the lack of expose we give our Java 6 >>>>> branch. While the majority of fixes we commit are applied to both >>>>> branches, we have some good work completed in the Java 6 API branch's >>>>> core classes that is not getting the uptake it deserves. >>>>> >>>>> The non-core Java 6 classes get very little attention at the moment. >>>>> With Harmony's strong modular architecture we can easily construct a >>>>> headless runtime that delivers those core classes without the missing >>>>> functionality. >>>>> >>>>> I'd like to suggest that we experiment with the flexible components in >>>>> Harmony to deliver a headless runtime based on the Java 6 APIs. >>>>> >>>>> Thoughts? >>>>> >>>>> [1] Depending on exactly how you count it, we were open from 17 Nov - 27 >>>>> Feb, which is a massive 14.5 weeks! >>>>> >>>>> Regards, >>>>> Tim >>>>> >>>> >>>> >> >> >> > -- Tony Wu China Software Development Lab, IBM
