Tim, An open and accountable selection scenario you have described raises more questions than just "there are contributors which are particularly interested in this set of modules" scenario. You wrote,
> Harmony Select is a proposal to take the modules that are at/near 6.0 > completeness and deliver them as a useful runtime. I read here that you classify RMI, PRINT, ACCESSIBILITY, APPLET and several other modules to be far from java 6.0 completeness. If our java 6 release content definition relies on this disqualification of these modules, it is nice to have the related reason documented. People who wanted these modules in Java 6 release would see what should be done with these modules, so they became selected ones and qualified as "java 6 complete". Documenting these completeness issues would educate community (and me) a lot and make Harmony directions more transparent for willing participants. For example, I'm not aware of any Java 6 specific specification changes of "headless" RMI module. AFAIK non-headless Swing has most Java-6 related changes in DnD mechanics, and we lack that mechanics for both Java 5 and Java 6. Both modules were qualified to be sufficiently complete for Java 5, don't they? Thanks. On Tue, Apr 28, 2009 at 4:31 PM, Tim Ellison <[email protected]> wrote: > Egor Pasko wrote: >> On the 0x5A0 day of Apache Harmony Tim Ellison wrote: >>> Last week, in the lessons learned thread, we talked about having a >>> reduced footprint runtime delivery based upon our Java 6 branch [1]. >>> >>> The goal would be to get exposure of the Java 6 code in a form that is >>> still useful to a wide class of (headless) programs. Using Harmony's >>> modular architecture we can quite easily deliver on the Java 6 modules >>> that are further developed at the moment, with plans to back-fill the >>> other modules as they become available. >>> >>> Here's a strawman proposal about what I think should be in the "Harmony >>> Select" build: >>> >>> Included >>> ANNOTATION ARCHIVE AUTH >>> BEANS CONCURRENT CRYPTO >>> JNDI INSTRUMENT LANG-MANAGEMENT >>> LOGGING LUNI MATH >>> NIO NIO_CHAR PACK200 >>> PREFS REGEX SECURITY >>> SQL TEXT XML >>> X-NET >>> >>> >>> Which means the following modules would be left out: >>> ACCESSIBILITY APPLET AWT >>> IMAGEIO ORB PRINT >>> RMI SOUND SWING >>> X_MGT >>> >>> >>> I chose the above lists somewhat arbitrarily based upon the Java 5 build >>> content. I haven't listed some modules we might want to include that >>> are Java 6 specific (e.g. JAXB). >>> >>> Discuss :-) >>> - Can you imagine paring down the 'Included' list any further? >>> - What is missing from the list that must be there to make it useful? >> >> Is this to minimize download size? Or the first step towards a >> packaging system? What is the estimate download size in your proposal? > > For me, it is a way to deliver our Java 6 stream in a way that is as > useful to people as possible. > > We know that there are a number of modules that are not Java 6 API > ready, and at current course and speed will take a long time to get > there. On the other hand, there are a number of modules that are > already at Java 6 API level, are being diligently maintained by people, > and not delivered to anyone. That's a shame. > > Harmony Select is a proposal to take the modules that are at/near 6.0 > completeness and deliver them as a useful runtime. > > Of course, the download size will be smaller (I see our Java 5 API JRE > comes in at ~60Mb, and if I delete the 'left out' list above it comes > down to ~49Mb). > > There is a vision, we discussed a while ago, for delivering the > additional modules dynamically - but there is a poor man's story too > which just says drop in the additional required modules. > >> What is the target audience? Trying to imagine someone saying "with a >> 5 MB download I am so happy to have headless java" ... and .. I should >> say I do not know many people who would say that. Let's assume this is >> just me, a side effect of being happy today :) > > Well we can run a number of useful headless apps with the list of > modules included above. So it should be useful to anyone who does not > need the UI classes, but wants Java 6 APIs. > > Regards, > Tim > -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://www.telecom-express.ru/ http://people.apache.org/~aaf/ http://harmony.apache.org/ http://code.google.com/p/openmeetings/
