harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [discuss] Harmony Select 6 definition
Date Wed, 29 Apr 2009 12:05:17 GMT
Alexei Fedotov wrote:
> 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.

It's simply pragmatics.

>From what I can see there is nobody actively working on those modules,
and in my proposal the runtime without those modules would still be
useful.  If somebody pops up and starts to enhance / test / maintain
other modules then I think they would also be candidates for inclusion.

Some modules are required for a useful runtime.  So, for example, REGEX
doesn't get much attention either.  There are bugs outstanding but
nobody actively fixing the code or improving it.  However, excluding
REGEX would diminish the runtime significantly IMHO so I put it in the
include list.

Harmony Select is a way to deliver the areas that are getting some
attention, and a way to guide our efforts.

> 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".

Yes, for sure.  People who care about a module should contribute to it
and improve it for all our builds.

> 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?

Yes, I agree - and we have been building the Java 5 code forever.  We
waited until we were near complete before publishing stable, capable,
milestones.  For Java 6 modules we have some modules ready to 'go live'
and this is an opportunity for them to do so.

Regards,
Tim


> 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
>>
> 
> 
> 

Mime
View raw message