You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Fedotov <al...@gmail.com> on 2008/12/25 17:23:30 UTC
Harmony 2009 roadmap Was: Using PriviAction instead of PrivilegedAction
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....@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
>
--
С уважением,
Алексей Федотов,
ЗАО «Телеком Экспресс»
Re: Harmony 2009 roadmap Was: Using PriviAction instead of PrivilegedAction
Posted by Sian January <si...@googlemail.com>.
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 <al...@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
> <al...@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....@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
Re: Harmony 2009 roadmap Was: Using PriviAction instead of PrivilegedAction
Posted by Aleksey Shipilev <al...@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
<al...@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....@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
>>
>
>
>
> --
> С уважением,
> Алексей Федотов,
> ЗАО «Телеком Экспресс»
>
Re: Harmony 2009 roadmap Was: Using PriviAction instead of PrivilegedAction
Posted by Nathan Beyer <nd...@apache.org>.
On Thu, Dec 25, 2008 at 10:23 AM, Alexei Fedotov
<al...@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.
I assure you, there's no discussion of Harmony's direction on the PMC
list - that all takes place on the public development list. Very
little actually happens on the PMC list - mostly procedural stuff
about ICLAs and ACQs.
The community defines the direction of the project and we do that on
the public development list.
-Nathan
> 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....@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
>>
>
>
>
> --
> С уважением,
> Алексей Федотов,
> ЗАО «Телеком Экспресс»
>