harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: Harmony 2009 roadmap Was: Using PriviAction instead of PrivilegedAction
Date Fri, 26 Dec 2008 21:48:46 GMT
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
>>
>
>
>
> --
> С уважением,
> Алексей Федотов,
> ЗАО «Телеком Экспресс»
>
Mime
View raw message