harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [discuss] Harmony Select 6 definition
Date Wed, 29 Apr 2009 05:45:52 GMT
On the 0x5A1 day of Apache Harmony Tim Ellison 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.

Great! This clarifies a lot to me, delivering the completed Java 6
part does really make sense.

-- 
Egor Pasko


Mime
View raw message