harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: [discuss] Harmony Select 6 definition
Date Wed, 29 Apr 2009 08:11:18 GMT
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?


On Tue, Apr 28, 2009 at 4:31 PM, Tim Ellison <t.p.ellison@gmail.com> 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 / Алексей Федотов,

View raw message