harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: Harmony 2009 roadmap Was: Using PriviAction instead of PrivilegedAction
Date Mon, 05 Jan 2009 13:12:09 GMT
I think it would be great to update the high-level raodmap on the
website (http://harmony.apache.org/roadmap.html) because the way it
stands at the moment there are 2007 targets that haven't been met,
which looks like there isn't much ongoing work in the project.

If we can agree some targets for 2009 I would be happy to update the page.

I like all of Aleksey's proposals (except that I'm not sure we've
fully resolved the legal/copyright issues for [1] have we?).  We could
also consider things like code quality, test coverage, application
compatability, more jdk tools and support for other platforms.

However, I do think it would be good to make sure we have contributors
who are potentially interested in working on each item.



2008/12/26 Aleksey Shipilev <aleksey.shipilev@gmail.com>:
> Good topic.
>
> My opinion is based on four presumptions:
>
>  a. The planning for the community is possible :)
>
>  b. There always people come and go, but Harmony community is
> degrading faster than growing back. This is observed either by mail
> list traffic or by feature/commit history.
>
>  c. Class libraries are essential parts of Java ecosystem, but
> nevertheless there only 3 of them in mature state (Harmony, Classpath,
> OpenJDK).
>
>  d. JVMs are essential parts of Java ecosystem, but there lots of them
> available, and all players now use anything but not DRLVM.
>
> Point (b) tells me that there will be only a little development work
> done by Harmony community itself, so Harmony should reuse the
> customers' forces to succeed. The model for 2009, IMO, is to lend the
> parts of Harmony to other projects and use the other projects'
> capacities for making progress on these parts. The role of Harmony
> then would be the meeting point of different improvements which can be
> reused by all players. Back in 2005 it was thought as collateral usage
> model, but now it's more like essential for Harmony to survive.
>
> So what parts can be lent? We can clearly distinguish two parts: DRLVM
> and class libraries.
>
> I have serious doubts that DRLVM can be developed without strong
> community behind it. Nevertheless, if my doubt is wrong, point (d)
> comes to mind and rises the question on whether it's worth to spend
> resources on it's support: why develop yet another JVM with no clear
> understanding who will use it?
>
> I do realize that many newcomers are contributing to DRLVM, but I
> doubt they could tackle the big hard problems, like fixing the bugs
> detected on some-time-it-will-arrive JCK.
>
> There are more bright sides on class libraries: they're precious
> assets, as there are little of them! Lots of people is walking around
> and using Harmony classlib: Google Android, JikesRVM, etc. So I think
> Harmony should exploit this opportunity to catch the momentum.
>
> I see several big tasks in sense of that:
>
>  1. Process and accept patches to Classlib from Android and JikesRVM
> to make Harmony attractive as owner of the original code.
>
>  2. Optimize and foster optimizations of Classlib on other VMs,
> reusing existing projects' testing systems. Piggybacking on JikesRVM's
> cattrack [3] is a good example.
>
>  3. Complete missing functionality in Classlib. I realize the last
> 0.3% are very tough, but this would allow us to claim fruity 100%
> coverage.
>
>  4. Concentrate on Java 6 Classlib implementation, leaving Java 5
> backport available. OpenJDK already supports Java 6 [1]. Classpath is
> still 1.2 [2].
>
> We could even do all that on some production JVM, without doing
> extensive debug of DRLVM if there're critical bugs.
>
> I understand that there are still small group of people who have a
> part of their soul embedded into Harmony VM. I believe the proud and
> honest task for them is to support new class library functionality, so
> we still can bundle our fully-functional releases.
>
> What do you think?
>
> Thanks,
> Aleksey.
>
> [1] http://openjdk.java.net/
> [2] http://www.gnu.org/software/classpath/
> [3] http://jikesrvm.anu.edu.au/cattrack
> On Thu, Dec 25, 2008 at 7:23 PM, Alexei Fedotov
> <alexei.fedotov@gmail.com> wrote:
>> Merry Christmas folks,
>>
>> The discussion on PriviAction re-factoring makes me feel lost. Even if
>> you guys spend days discussing Harmony directions on PMC list, this is
>> not quite transparent for me and Kevin. Well, I like improving my
>> code. But even more than that I like when someone make use of my code.
>> During crisis times are we looking for customers who may take
>> advantage of our product?
>>
>> For example, Eclipse might be bundled with our archive.jar with
>> delayed parsing of per-entry manifest attributes, thus improving
>> Eclipse start up time on the top of Sun's VM. Of course, delayed
>> parsing should be developed first. Those of you, guys, who continue
>> using java, may share your real life examples. As for me, I don't use
>> java except for launching OpenProj. But nothing prevents us from
>> taking advantage of Salikh's infrastructure for unit testing [1] in
>> our C++ project.  I'm trying to convince my colleagues to adopt my
>> logger as well.
>>
>> Having clear goals like 100% API completeness or redistributable class
>> library for Google Android is also nice. I'm looking forward for your
>> ideas on our directions.
>>
>> [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/tests/unit/framework/
>>
>> On Wed, Dec 24, 2008 at 2:10 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> I didn't see a good answer to Alexei's question...
>>>
>>> Alexei Fedotov wrote:
>>>> Pavel,
>>>> Kevin didn't mention performance, did he?
>>>>
>>>> I believe it is always a trade off between modularity and speed. The
>>>> performance measurement might be a part of Kevin's arguments if his
>>>> intentions are to improve the performance. That is why I asked him to
>>>> elaborate both approaches uncovering intentions.
>>>>
>>>> If our internal security interfaces are much quicker on real
>>>> applications I would wonder why our public interfaces are so slow.
>>>
>>> What problem is the PriviAction solving?  I see the class comment [1] says:
>>>
>>> "Helper class to avoid multiple anonymous inner class for
>>> java.security.AccessController#doPrivileged(PrivilegedAction) calls."
>>>
>>> Is that really a problem?  For readability or performance?
>>>
>>> [1]
>>> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/util/PriviAction.java?revision=486600
>>>
>>> Regards,
>>> Tim
>>>
>>
>>
>>
>> --
>> С уважением,
>> Алексей Федотов,
>> ЗАО «Телеком Экспресс»
>>
>



-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Mime
View raw message