You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Davanum Srinivas <da...@gmail.com> on 2005/05/19 17:14:33 UTC
JIRA and SVN
JIRA: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740
SVN: http://svn.apache.org/repos/asf/incubator/harmony/
thanks,
dims
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: JIRA and SVN
Posted by Christian Willy Asmussen - Young Padovan <kr...@arca.ime.usp.br>.
Does the svn repo send e-mail somewhere uppon commits?
[s]
Krico
Davanum Srinivas wrote:
>JIRA: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740
>SVN: http://svn.apache.org/repos/asf/incubator/harmony/
>
>thanks,
>dims
>
>
Re: JIRA and SVN
Posted by Daithi O Crualaoich <it...@gmail.com>.
Yup... see...
http://swingwt.sourceforge.net/
Daithi
On 5/24/05, Renaud BECHADE <re...@numerix.com> wrote:
>
> I think there are Swing wrappers for SWT, which can wrap win$ / GTK /
> MacOS-X-Carbon.
> (No guaranty so far as code completeness is concerned, so please trust it
> and die...)
>
> RB
>
> -----Original Message-----
> From: Bryce Leo [mailto:likwidoxigen@gmail.com]
> Sent: Tuesday, May 24, 2005 6:34 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: JIRA and SVN
>
> Any opinions on dumbing down the swing interface as to get a
> functional copy. As in, couldn't we find a way to let java use the
> gtk+ toolkit to build gui's though a "swing" implementation where they
> could have the functionality but only one look and feel. Or perhaps we
> could go the route of python and use the wxWidgets framework.
> Opinions?
>
>
Re: JIRA and SVN
Posted by Gerry Steele <ge...@gmail.com>.
I agree.
I'm afraid the TCK has many hundreds of Swing tests. (javax_swing in JCK
test tree). Not all require robotic interaction; they may be tests of the
data structures or exceptions and suchlike in the Swing libraries. Therefore
it is yet another area where Harmony will need quality libraries to meet the
j2se spec.
Whilst it might be tempting to find a workaround, i can't see it being a
worthwile solution. It'll just create more issues down the line I think.
-gerry
On 5/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>
> On May 23, 2005, at 5:33 PM, Bryce Leo wrote:
>
> > Any opinions on dumbing down the swing interface as to get a
> > functional copy. As in, couldn't we find a way to let java use the
> > gtk+ toolkit to build gui's though a "swing" implementation where they
> > could have the functionality but only one look and feel. Or perhaps we
> > could go the route of python and use the wxWidgets framework.
> > Opinions?
>
> It's gotta be the same experience for a user as if using Sun's
> implementation.
>
> geir
>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Gerry Steele
x74521/+353-1-8199 521
http://blogs.sun.com/roller/page/gerrys
[gerry.steele@sun.com OR gerry.steele@gmail.com]
Re: JIRA and SVN
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 23, 2005, at 5:33 PM, Bryce Leo wrote:
> Any opinions on dumbing down the swing interface as to get a
> functional copy. As in, couldn't we find a way to let java use the
> gtk+ toolkit to build gui's though a "swing" implementation where they
> could have the functionality but only one look and feel. Or perhaps we
> could go the route of python and use the wxWidgets framework.
> Opinions?
It's gotta be the same experience for a user as if using Sun's
implementation.
geir
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: JIRA and SVN
Posted by Renaud BECHADE <re...@numerix.com>.
I think there are Swing wrappers for SWT, which can wrap win$ / GTK /
MacOS-X-Carbon.
(No guaranty so far as code completeness is concerned, so please trust it
and die...)
RB
-----Original Message-----
From: Bryce Leo [mailto:likwidoxigen@gmail.com]
Sent: Tuesday, May 24, 2005 6:34 AM
To: harmony-dev@incubator.apache.org
Subject: Re: JIRA and SVN
Any opinions on dumbing down the swing interface as to get a
functional copy. As in, couldn't we find a way to let java use the
gtk+ toolkit to build gui's though a "swing" implementation where they
could have the functionality but only one look and feel. Or perhaps we
could go the route of python and use the wxWidgets framework.
Opinions?
Re: Sun lashes out at open source J2SE
Posted by Stefano Mazzocchi <st...@apache.org>.
Geir Magnusson Jr. wrote:
> Eh.
>
> Lets just keep to our purpose and message of compatibility and
> openness. I'm familiar with getting misquoted, or pieces taken out of
> context, and I hope this is the case here.
Yeah.
I understand where James Gosling is coming from: he is concerned about
'forking' and I understand that. But he has to undertand that forking
the codebase and forking the functionality are two different things. The
artistic license, for example, allows you to fork the code *ONLY* if you
change all the APIs issues. I think somebody has to go down to his
office and let him know at least that, I think he has a little
stereotypical view of open source and thinks that we are all tinfoil hats.
But you see why a lot of people got burned in talking to Sun: you can't
show them the value of a community if their top management thinks that
no real software architect would ever work with a bunch of slashdot freaks.
Pretty blind, actually. Especially because Apache created more code and
value for the Java platform than anybody else. Oh well.
He does not understand our "clear need" to have a truly open code,
because he does *NOT* understand that we don't want the right to fork
the java platform (we can't call it java if we do, so what's the
point!), but we want the right to build a community around it. Sun
licenses don't give us that, therefore the need for Harmony.
But at the end, who cares: the JCP license allows us to do it, and our
not-for-profit status allows us to have access to the TCK for free.
We will not need words to show James Gosling that, ultimately, Harmony
is not going to be disruptive, but rather beneficial. And the reason for
this is that we value compatibility even more than he does: because a
lot of our salaries depend on it!
Let's get to work.
--
Stefano.
Re: Sun lashes out at open source J2SE
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 24, 2005, at 6:57 AM, Steve Heath wrote:
> Isn't the message here: Gosling misunderstands the point of Harmony?
> Anyone reading to the bottom of the article will be put right.
>
> Just a quick question tho'. The article mentions portability and
> distribution licensing. Isn't another part of the point that an OSS
> virtual machine (with the backing of a big foundation like apache)
> will be able to take advantage of the 'many eyes' principle, for bug
> reports/fixes and performance enhancements?
Sure - that's a benefit too. There's the "many hands" principle too,
as we collaborate and share the work.
geir
>
> On 5/24/05, Mladen Turk <mt...@apache.org> wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> Eh.
>>>
>>> Lets just keep to our purpose and message of compatibility and
>>> openness.
>>>
>>
>> When we move from 'enthusiasm' to the 'project' more and more
>> 'doubts' will be seen :)
>>
>> Let's just play our song and let others have all the doubts they
>> wish.
>>
>> Regards,
>> Mladen.
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Sun lashes out at open source J2SE
Posted by Steve Heath <st...@gmail.com>.
Isn't the message here: Gosling misunderstands the point of Harmony?
Anyone reading to the bottom of the article will be put right.
Just a quick question tho'. The article mentions portability and
distribution licensing. Isn't another part of the point that an OSS
virtual machine (with the backing of a big foundation like apache)
will be able to take advantage of the 'many eyes' principle, for bug
reports/fixes and performance enhancements?
On 5/24/05, Mladen Turk <mt...@apache.org> wrote:
> Geir Magnusson Jr. wrote:
> > Eh.
> >
> > Lets just keep to our purpose and message of compatibility and
> > openness.
>
> When we move from 'enthusiasm' to the 'project' more and more
> 'doubts' will be seen :)
>
> Let's just play our song and let others have all the doubts they wish.
>
> Regards,
> Mladen.
>
Re: Sun lashes out at open source J2SE
Posted by Mladen Turk <mt...@apache.org>.
Geir Magnusson Jr. wrote:
> Eh.
>
> Lets just keep to our purpose and message of compatibility and
> openness.
When we move from 'enthusiasm' to the 'project' more and more
'doubts' will be seen :)
Let's just play our song and let others have all the doubts they wish.
Regards,
Mladen.
Re: Sun lashes out at open source J2SE
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Eh.
Lets just keep to our purpose and message of compatibility and
openness. I'm familiar with getting misquoted, or pieces taken out
of context, and I hope this is the case here.
geir
On May 23, 2005, at 5:51 PM, Brad Cox wrote:
> http://www.infomaticsonline.co.uk/2135503
>
>
> Sun lashes out at open source J2SE
>
>
> Apache plans dubbed 'destructive'
>
> Sun Microsystems has expressed "serious doubts" about the
> usefulness of the latest Apache Foundation project to create an
> open source implementation of the Java 2 Standard Edition (J2SE).
>
> In an interview with *vnunet.com* <http://www.vnunet.com>, James
> Gosling, Java creator and Sun vice president in charge of the
> programming language, explained that he did not understand why the
> open source consortium was undertaking the project.
>
> "I would never do that," he said about Apache's Project Harmony.
> "There are so many more interesting things to do with my life."
>
> The Apache Foundation announced the project *earlier this month*
> <http://www.infomaticsonline.co.uk/2127323>. The organisation aims
> to collect a group of developers and create an open source
> implementation of the J2SE, which is needed to run Java code on a
> desktop computer.
>
> Sun requires J2SE implementations to pass rigorous testing
> requirements before they can call themselves Java compliant. While
> this ensures compatibility between the different J2SEs, it also
> means that the functionalities of the final product are identical
> to Sun's existing offering.
>
> Sun put the detailed requirements in place to prevent "forking", a
> fragmentation of the language that would force software developers
> to certify their code for each fork.
>
> A similar development with Linux allowed Red Hat and SuSE to become
> the de facto standards. Major software vendors, such as Oracle and
> Computer Associates, now certify their software only for these
> Linux distributions.
>
> Sun welcomes contributions from outside the company to the source
> code, and has a Java Community Process in place to foster
> discussion within the developer community and encourage input on
> the future direction of the language.
>
> The inability to fork Java is the only major difference between the
> software licence that Sun uses for Java and the GPL-like licence
> that the Apache Foundation will use, according to Gosling.
>
> "[Apache] says a lot of words about why they want to do it. Exactly
> why is it critical to have a delta between our source licence and
> the source licence that they think is appropriate?" he said.
>
> "I understand why they would like it to be different. From our
> point of view that would actually be more destructive than helpful.
> It boils down to forking: they believe that the ability to fork is
> an absolutely critical right."
>
> Gosling claimed that Java developers of enterprise software support
> Sun in its refusal to open the source code of Java. But they are
> eclipsed by more vocal open source advocates.
>
> "If we could get the enterprise software architects to be as vocal
> as the Slashdot crowd, it would be a really interesting
> discussion," he said.
>
> Sun will not contribute to the project, Gosling said, revoking a
> comment that another Sun vice president made on his blog earlier.
>
> "We hardly have the energy to work on our [J2SE implementation].
> We'll be glad to get co-operative and helpful, but there is only so
> much energy that is free and donatable," Gosling told *vnunet.com*
> <http://www.vnunet.com>.
>
> In response to Gosling's remarks, Geir Magnusson, an independent
> software developer with the Foundation, told /vnunet.com/ that
> Apache does not aim to fork Java.
>
> An open source J2SE implementation could allow the software to
> spread to new devices, according to Magnusson, who pointed out that
> Sun's J2SE only supports Solaris, Linux and Windows.
>
> "This is about producing a J2SE implementation that can be taken
> and ported and used in more places," he said.
>
> "If I am building a device that uses Java and I could get a
> complete J2SE implementation from Apache, then we would have a new
> place for Java.
>
> "It would be nice if every Linux distribution came with Java. Java
> should be like a dial-tone."
>
> Magnusson added that current J2SE providers, such as IBM, BEA and
> Sun, all have to build and test their own software. An open source
> implementation would allow them to share that work.
>
> He is not surprised by Sun's lack of enthusiasm about his latest
> project, however. Magnusson has spoken with the company about
> Harmony and has invited it to participate. "Sun is a little
> sceptical that we are able to do it," he said.
>
> Sun has provided Magnusson with a slot at the upcoming Java One
> conference from 27-30 June in San Francisco.
>
> The development of the open source J2SE software is expected to
> take several years.
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Sun lashes out at open source J2SE
Posted by Brad Cox <br...@gmail.com>.
http://www.infomaticsonline.co.uk/2135503
Sun lashes out at open source J2SE
Apache plans dubbed 'destructive'
Sun Microsystems has expressed "serious doubts" about the usefulness of
the latest Apache Foundation project to create an open source
implementation of the Java 2 Standard Edition (J2SE).
In an interview with *vnunet.com* <http://www.vnunet.com>, James
Gosling, Java creator and Sun vice president in charge of the
programming language, explained that he did not understand why the open
source consortium was undertaking the project.
"I would never do that," he said about Apache's Project Harmony. "There
are so many more interesting things to do with my life."
The Apache Foundation announced the project *earlier this month*
<http://www.infomaticsonline.co.uk/2127323>. The organisation aims to
collect a group of developers and create an open source implementation
of the J2SE, which is needed to run Java code on a desktop computer.
Sun requires J2SE implementations to pass rigorous testing requirements
before they can call themselves Java compliant. While this ensures
compatibility between the different J2SEs, it also means that the
functionalities of the final product are identical to Sun's existing
offering.
Sun put the detailed requirements in place to prevent "forking", a
fragmentation of the language that would force software developers to
certify their code for each fork.
A similar development with Linux allowed Red Hat and SuSE to become the
de facto standards. Major software vendors, such as Oracle and Computer
Associates, now certify their software only for these Linux distributions.
Sun welcomes contributions from outside the company to the source code,
and has a Java Community Process in place to foster discussion within
the developer community and encourage input on the future direction of
the language.
The inability to fork Java is the only major difference between the
software licence that Sun uses for Java and the GPL-like licence that
the Apache Foundation will use, according to Gosling.
"[Apache] says a lot of words about why they want to do it. Exactly why
is it critical to have a delta between our source licence and the source
licence that they think is appropriate?" he said.
"I understand why they would like it to be different. From our point of
view that would actually be more destructive than helpful. It boils down
to forking: they believe that the ability to fork is an absolutely
critical right."
Gosling claimed that Java developers of enterprise software support Sun
in its refusal to open the source code of Java. But they are eclipsed by
more vocal open source advocates.
"If we could get the enterprise software architects to be as vocal as
the Slashdot crowd, it would be a really interesting discussion," he said.
Sun will not contribute to the project, Gosling said, revoking a comment
that another Sun vice president made on his blog earlier.
"We hardly have the energy to work on our [J2SE implementation]. We'll
be glad to get co-operative and helpful, but there is only so much
energy that is free and donatable," Gosling told *vnunet.com*
<http://www.vnunet.com>.
In response to Gosling's remarks, Geir Magnusson, an independent
software developer with the Foundation, told /vnunet.com/ that Apache
does not aim to fork Java.
An open source J2SE implementation could allow the software to spread to
new devices, according to Magnusson, who pointed out that Sun's J2SE
only supports Solaris, Linux and Windows.
"This is about producing a J2SE implementation that can be taken and
ported and used in more places," he said.
"If I am building a device that uses Java and I could get a complete
J2SE implementation from Apache, then we would have a new place for Java.
"It would be nice if every Linux distribution came with Java. Java
should be like a dial-tone."
Magnusson added that current J2SE providers, such as IBM, BEA and Sun,
all have to build and test their own software. An open source
implementation would allow them to share that work.
He is not surprised by Sun's lack of enthusiasm about his latest
project, however. Magnusson has spoken with the company about Harmony
and has invited it to participate. "Sun is a little sceptical that we
are able to do it," he said.
Sun has provided Magnusson with a slot at the upcoming Java One
conference from 27-30 June in San Francisco.
The development of the open source J2SE software is expected to take
several years.
Re: JIRA and SVN
Posted by Bryce Leo <li...@gmail.com>.
Any opinions on dumbing down the swing interface as to get a
functional copy. As in, couldn't we find a way to let java use the
gtk+ toolkit to build gui's though a "swing" implementation where they
could have the functionality but only one look and feel. Or perhaps we
could go the route of python and use the wxWidgets framework.
Opinions?
Re: JIRA and SVN
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 21, 2005, at 12:11 AM, acoliver@apache.org wrote:
> As I understand it there is no TCK coverage for Swing
I'm not so sure w/ the TCK for J2SE 5.
> (which will probably make that a long trip frankly) and well AWT is
> what AWT is. It is unlikely that we'll achieve a satisfactory
> swing implementation for some time (though there are approaches
> that I've seen for automating unit tests for it).
One fantasy is that Sun might be so good as to donate an
implementation, so that we can be sure that we have something that is
compatible for our users.
Think happy thoughts on this one...
> Secondly, Java applications and applets more or less suck. There
> are exceptions, I agree, I know, etc. However, the approaches to
> GUI in the product called "Java" are simply not competitive (and
> I've no real solid knowlege of SWT, but I've programmed enough with
> other toolkits to know what I'm missing). So for an achievable
> simplicity initial focus should be on #1 and #3. Obviously we'll
> need to cover the rest eventually.
Yep
geir
>
> -Andy
>
> Tom Tromey wrote:
>
>>>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
>>>>>>>
>> Geir> In the meantime, any comments on architectures of some of
>> the VMs?
>> Geir> I'm interest in having a balanced amount of upfront design that
>> Geir> prevents us from preventing participation from unexpected
>> places in
>> Geir> the future...
>> This is too vague -- we don't know much about the unexpected. Plus,
>> in most cases, the "core" part of the VM is simply not very
>> important.
>> There just isn't much code there -- JamVM is 20KLOC, anybody could
>> comfortably rewrite this.
>> Instead I think Harmony should look at 2, and possibly 3, use cases:
>> 1. Server use, e.g., some J2EE thing.
>> 2. Desktop / applet use.
>> 3. Embedded use (maybe).
>> For 1, the execution engine and GC is really crucial. This is an
>> area
>> where hotspot-like dynamic recompilation implementations shine, IMO.
>> For 2, again IMO, a gcj-like shared library approach is probably more
>> useful. This is especially true if you expect to run more than one
>> program using a given library, since in this case you are talking
>> about controlling memory costs of the user environment as a whole.
>> For 3 ... "embedded" covers a lot of ground, but I wanted to
>> emphasize
>> size-critical applications. In this arena you sometimes see folks
>> who
>> care more about size than performance. This affects choice of
>> execution engine.
>> I think it is possible to work well in all 3 environments with a
>> single VM source base (though perhaps with different compilations of
>> it).
>> I think one way to do this would be an LLVM-based approach. This
>> would require LLVM improvements, but let's be very clear about
>> this --
>> *any* approach we take to get to #1 and #2 is going to require a lot
>> of compiler hacking. First, JITs have to be upgraded over time.
>> Second, even with JikesRVM I think we're talking about at least
>> writing new ports and an infrastructure for debuggers.
>> One nice thing about the LLVM approach is that, hopefully, we could
>> leverage other people's work. This is one reason gcj has been as
>> widely ported as it is; the core gcj developers hardly ever do any
>> architecture-specific work but instead we just inherit it from GCC.
>> Tom
>> .
>>
>
>
> --
> Andrew C. Oliver
> SuperLink Software, Inc.
>
> Java to Excel using POI
> http://www.superlinksoftware.com/services/poi
> Commercial support including features added/implemented, bugs fixed.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: JIRA and SVN
Posted by ac...@apache.org.
As I understand it there is no TCK coverage for Swing (which will
probably make that a long trip frankly) and well AWT is what AWT is. It
is unlikely that we'll achieve a satisfactory swing implementation for
some time (though there are approaches that I've seen for automating
unit tests for it). Secondly, Java applications and applets more or
less suck. There are exceptions, I agree, I know, etc. However, the
approaches to GUI in the product called "Java" are simply not
competitive (and I've no real solid knowlege of SWT, but I've programmed
enough with other toolkits to know what I'm missing). So for an
achievable simplicity initial focus should be on #1 and #3. Obviously
we'll need to cover the rest eventually.
-Andy
Tom Tromey wrote:
>>>>>>"Geir" == Geir Magnusson <ge...@apache.org> writes:
>
>
> Geir> In the meantime, any comments on architectures of some of the VMs?
> Geir> I'm interest in having a balanced amount of upfront design that
> Geir> prevents us from preventing participation from unexpected places in
> Geir> the future...
>
> This is too vague -- we don't know much about the unexpected. Plus,
> in most cases, the "core" part of the VM is simply not very important.
> There just isn't much code there -- JamVM is 20KLOC, anybody could
> comfortably rewrite this.
>
>
> Instead I think Harmony should look at 2, and possibly 3, use cases:
>
> 1. Server use, e.g., some J2EE thing.
>
> 2. Desktop / applet use.
>
> 3. Embedded use (maybe).
>
>
> For 1, the execution engine and GC is really crucial. This is an area
> where hotspot-like dynamic recompilation implementations shine, IMO.
>
> For 2, again IMO, a gcj-like shared library approach is probably more
> useful. This is especially true if you expect to run more than one
> program using a given library, since in this case you are talking
> about controlling memory costs of the user environment as a whole.
>
> For 3 ... "embedded" covers a lot of ground, but I wanted to emphasize
> size-critical applications. In this arena you sometimes see folks who
> care more about size than performance. This affects choice of
> execution engine.
>
>
> I think it is possible to work well in all 3 environments with a
> single VM source base (though perhaps with different compilations of
> it).
>
> I think one way to do this would be an LLVM-based approach. This
> would require LLVM improvements, but let's be very clear about this --
> *any* approach we take to get to #1 and #2 is going to require a lot
> of compiler hacking. First, JITs have to be upgraded over time.
> Second, even with JikesRVM I think we're talking about at least
> writing new ports and an infrastructure for debuggers.
>
> One nice thing about the LLVM approach is that, hopefully, we could
> leverage other people's work. This is one reason gcj has been as
> widely ported as it is; the core gcj developers hardly ever do any
> architecture-specific work but instead we just inherit it from GCC.
>
> Tom
> .
>
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
Jam VM as Seed : request for license grant (Was Re: JIRA and SVN)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 21, 2005, at 6:49 PM, Robert Lougher wrote:
>
> The major problem with JamVM as regards Harmony is that it is
> currently licensed under the GPL. I originally had some specific
> reasons for doing this, however, I am open to suggestions about
> different licensing models, e.g. dual-licensing, adoption of LGPL or a
> linking exception as in GNU Classpath. Assuming the license issue
> could be sorted out, and if (and it's a big if) JamVM was adopted as
> one of the seed VMs my next concern would be what happens next. Would
> it be a fork? Would I continue to work on JamVM as now? Of course,
> change is not necessarily a bad thing.
Robert,
I'd like to cut to the chase and ask the following... I was going to
do in private, and happy to discuss concerns in private, but since
you brought up here, I'm going to take the risk and ask :
Would you consider granting a copyright license for the JamVM
codebase to the Apache Software Foundation under the Apache License?
This means that you simply have given us license to the code under
the Apache License (which means we can do with it as we choose), and
you retain the copyright to do with as you choose. We of course
will not call it JamVM, and anything we do could be included in JamVM
if you so chose.
Ideally, we want you to participate here. However, as we'd like to
use this as a seed for a VM kernel, modularizing and implementing
parts in probably very strange ways, and we'd want it to be able to
change as needed w/o affecting the existing users of JamVM.
I'm averse to calling it a "fork" as that denotes some sort of
"taking away" or "duplication" or such - rather, I'd like to think of
this as a contribution to seed what I think will be a very different
result.
Any interest? :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Relicensing and/or donating code (was: JIRA and SVN)
Posted by Leo Simons <ma...@leosimons.com>.
On 22-05-2005 00:49, "Robert Lougher" <ro...@gmail.com> wrote:
> The major problem with JamVM as regards Harmony is that it is
> currently licensed under the GPL. I originally had some specific
> reasons for doing this, however, I am open to suggestions about
> different licensing models, e.g. dual-licensing, adoption of LGPL or a
> linking exception as in GNU Classpath. Assuming the license issue
> could be sorted out,
By far the easiest and safest option for you if you would like Harmony and
JamVM to be "legally compatible" is probably to dual-license under both the
GPL and one of
-> Apache License 2.0
-> MIT/X11 License (basically revised BSD license)
-> Mozilla Public License, CPL, or similar
If that is acceptable to you from a moral/philosophical/... point of view.
As for choosing "which one", IMHO (IANAL!) the main advantage of MIT is that
its real simple and short, the main advantage of AL over MIT is a little bit
of patent protection. The other big advantage of MIT license is that the FSF
feels it is compatible with the GPL whereas the same cannot be said for the
ASL, but if you're dual-licensing under the GPL as well that becomes a moot
point.
Then again, I don't reallly know why one would actually license under both
MIT license and GPL license: anyone could take your code, change 5 lines,
put those under the GPL, and the entire combined work would be under the
GPL, so you might as well just license under MIT license only. I think.
Then again, I have no idea why people whould choose MPL or CPL, but they do
that as well; IANAL.
> and if (and it's a big if) JamVM was adopted as
> one of the seed VMs my next concern would be what happens next. Would
> it be a fork? Would I continue to work on JamVM as now? Of course,
> change is not necessarily a bad thing.
Well, another alternative you can consider is donating JamVM to the ASF.
That would mean a code grant
(http://www.apache.org/licenses/software-grant.txt). It would mean that
JamVM would become an integral part of harmony, you become one of Harmony's
committers (at least I'd hope so! But the two aren't necessarily coupled),
and the entire work is from that point on licensed under the AL, brought
into the ASF version control repositories, etc etc. Of course, bringing a
big piece of code into a project requires the project's PPMC to decide it
wants that to happen, its not something the donating party decides on its
own :-)
I'd say that's a lot bigger a change than merely changing the license or
starting to dual-license. Depends on what y'all want to do :-D
Of course it would then still be possible to keep developing JamVM on its
own as well under a license of your choice (ie the ASF version would then
become a fork of some sort) but I'd advise against that kind of deal since
it leads to duplication of effort.
Gnight!
Leo
Re: Harmony and JamVM (Re: JIRA and SVN)
Posted by Steve Blackburn <St...@anu.edu.au>.
JamVM sounds very interesting. A fast lightweight interpreter has at
least two attractions:
a) portability (this is true regardless of the implementation language,
the point is that an interpreter does not require a new compiler backend
to be written for each architecture)
b) compactness
If the lightweight interpreter were a pluggable component, or if we
could use JamVM as a prototype for a pluggable lightweight interpreter,
I think that would be a real asset.
Rob, what do you think? Could the JamVM interpreter be extracted as a
pluggable module? Could the JamVM interpreter be used as a protype for
a new componentized implementation (will your insights and lessons
translate well into a new implementation, or are they mostly
JamVM-specific?)
Is the GC exact or conservative?
In other words, how can Harmony make the most of JamVM's most valuable
ideas?
Cheers,
--Steve
Re: Harmony and JamVM (Re: JIRA and SVN)
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
For those of you who have not played with a JVM before and want to get a
feel for how to implement them I would highly suggest you have a look at
the JamVM codebase.This is a really nice codebase to read and it is
relatively simple to understand - at least as far as JVMs go. Congrats
Robert!
---
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
Harmony and JamVM (Re: JIRA and SVN)
Posted by Robert Lougher <ro...@gmail.com>.
I meant to change the subject line. Oh well. You'll find the rest of
my response under Re: JIRA and SVN.
Rob.
On 5/21/05, Robert Lougher <ro...@gmail.com> wrote:
> Hi List,
>
> Now that I've been explicitly asked, I'll forego my current observer
> status and give some input :) First off, I'm not comfortable pushing
> JamVM, but I'll give a summary for people who are unfamiliar with it.
>
...
Re: JIRA and SVN
Posted by Robert Lougher <ro...@gmail.com>.
Hi List,
Now that I've been explicitly asked, I'll forego my current observer
status and give some input :) First off, I'm not comfortable pushing
JamVM, but I'll give a summary for people who are unfamiliar with it.
As has already been alluded to, JamVM's main claim is its small size
(currently, its stripped executable weighs in at ~135K on PowerPC and
100K on Intel). This makes it suitable for use on platforms ranging
from embedded ARM processors, up to desktop machines and SMP systems
(it has appropriate memory barriers for PowerPC and Intel), and it
could also be used as a bootstrap VM. Its small size is a result of
conscious design decisions and effort. It may not be the most
sophisticated VM out there, but it has proved to be complete, stable
and fast enough for many of the GNU Classpath developers to adopt it
as their development VM. The interpreter in particular, is
"state-of-the-art", supporting direct-threading, stack-caching,
prefetching and common super-instructions. See
http://www.csc.uvic.ca/~csc586a/slides/StackCaching-4.pdf and
http://www.csc.uvic.ca/~csc586a/Ass1.pdf for an advanced academic
course on virtual machines using JamVM.
JamVM has currently been built and tested on Linux for the ARM,
PowerPC and IA32 architectures, and on Mac OS X/Darwin for PowerPC.
Porting to a new architecture/platform involves writing a couple of
assembler macros for atomic operations (used in the thin-locking
implementation) and for memory barriers. A separate function must
also be implemented which handles the construction of a native C call
stack frame and perform parameter passing for invoking native JNI
methods. This could, however, be simplified in the future by
providing the option to use libffi instead. JamVM also includes the
option to use an internal native interface which is much more
efficient than JNI.
The current latest version of JamVM is 1.3.0 (see
http://jamvm.sf.net). This works "out-of-the-box" with GNU
Classpath-0.15 (the latest snapshot) and CVS head. I'm currently
finishing off JamVM 1.3.1, this is a maintenance release which
includes a couple of minor bug-fixes and some performance
optimisations for object and array allocation. It will also include
the patches enabling JamVM to boot the GNU Classpath generics branch
(the branch for Java 1.5 features). See
http://lists.gnu.org/archive/html/classpath/2005-04/msg00005.html.
The major problem with JamVM as regards Harmony is that it is
currently licensed under the GPL. I originally had some specific
reasons for doing this, however, I am open to suggestions about
different licensing models, e.g. dual-licensing, adoption of LGPL or a
linking exception as in GNU Classpath. Assuming the license issue
could be sorted out, and if (and it's a big if) JamVM was adopted as
one of the seed VMs my next concern would be what happens next. Would
it be a fork? Would I continue to work on JamVM as now? Of course,
change is not necessarily a bad thing.
Hope this helps,
Rob.
On 5/21/05, Raffaele Castagno <ra...@gmail.com> wrote:
> 2005/5/21, Davanum Srinivas <da...@gmail.com>:
> >
> > David,
> >
> > please feel free to ping Rob. It would be great!
> >
> > thanks,
> > dims
> >
> > On 5/21/05, David Griffiths <da...@gmail.com> wrote:
> > > On 20 May 2005 17:54:11 -0600, Tom Tromey <tr...@redhat.com> wrote:
> > > >
> > > >
> > > > This is too vague -- we don't know much about the unexpected. Plus,
> > > > in most cases, the "core" part of the VM is simply not very important.
> > > > There just isn't much code there -- JamVM is 20KLOC, anybody could
> > > > comfortably rewrite this.
> > >
> > >
> > > Hmmm, well I used to work with the author of JamVM (Rob Lougher) and
> > he's
> > > one of the brightest guys I know. I think you'll find that the low LOC
> > > figure is testament to his ability to write lean code rather than an
> > > indication of how easy it is to knock off a JVM on a wet Sunday
> > afternoon.
> > >
> > > BTW has anyone asked Rob about donating JamVM to Harmony? As the
> > (currently)
> > > sole owner he should have no problem with switching licenses.
> > >
> > > Cheers,
> > >
> > > Dave
> > >
> > >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
>
>
>
> --
> If you want a GMail account, send me an E-Mail.
>
>
Re: JIRA and SVN
Posted by Raffaele Castagno <ra...@gmail.com>.
2005/5/21, Davanum Srinivas <da...@gmail.com>:
>
> David,
>
> please feel free to ping Rob. It would be great!
>
> thanks,
> dims
>
> On 5/21/05, David Griffiths <da...@gmail.com> wrote:
> > On 20 May 2005 17:54:11 -0600, Tom Tromey <tr...@redhat.com> wrote:
> > >
> > >
> > > This is too vague -- we don't know much about the unexpected. Plus,
> > > in most cases, the "core" part of the VM is simply not very important.
> > > There just isn't much code there -- JamVM is 20KLOC, anybody could
> > > comfortably rewrite this.
> >
> >
> > Hmmm, well I used to work with the author of JamVM (Rob Lougher) and
> he's
> > one of the brightest guys I know. I think you'll find that the low LOC
> > figure is testament to his ability to write lean code rather than an
> > indication of how easy it is to knock off a JVM on a wet Sunday
> afternoon.
> >
> > BTW has anyone asked Rob about donating JamVM to Harmony? As the
> (currently)
> > sole owner he should have no problem with switching licenses.
> >
> > Cheers,
> >
> > Dave
> >
> >
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
--
If you want a GMail account, send me an E-Mail.
Re: how long till start?
Posted by Raffaele Castagno <ra...@gmail.com>.
Project has been approved already, and is officially started:
http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740
http://svn.apache.org/repos/asf/incubator/harmony/
Anyway, it's still in the "planning&designing" phase.
Feel free to partecipate...
Raffaele (as a simple observer...)
2005/5/21, crispyalien <cr...@gmail.com>:
>
> Hi, Does anybody know when will this project start officialy? Does it
> need to be aproved? whe will happend that?
>
> regards,
> Valentin
>
--
If you want a GMail account, send me an E-Mail.
how long till start?
Posted by crispyalien <cr...@gmail.com>.
Hi, Does anybody know when will this project start officialy? Does it
need to be aproved? whe will happend that?
regards,
Valentin
Re: JIRA and SVN
Posted by Davanum Srinivas <da...@gmail.com>.
David,
please feel free to ping Rob. It would be great!
thanks,
dims
On 5/21/05, David Griffiths <da...@gmail.com> wrote:
> On 20 May 2005 17:54:11 -0600, Tom Tromey <tr...@redhat.com> wrote:
> >
> >
> > This is too vague -- we don't know much about the unexpected. Plus,
> > in most cases, the "core" part of the VM is simply not very important.
> > There just isn't much code there -- JamVM is 20KLOC, anybody could
> > comfortably rewrite this.
>
>
> Hmmm, well I used to work with the author of JamVM (Rob Lougher) and he's
> one of the brightest guys I know. I think you'll find that the low LOC
> figure is testament to his ability to write lean code rather than an
> indication of how easy it is to knock off a JVM on a wet Sunday afternoon.
>
> BTW has anyone asked Rob about donating JamVM to Harmony? As the (currently)
> sole owner he should have no problem with switching licenses.
>
> Cheers,
>
> Dave
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: JIRA and SVN
Posted by David Griffiths <da...@gmail.com>.
On 20 May 2005 17:54:11 -0600, Tom Tromey <tr...@redhat.com> wrote:
>
>
> This is too vague -- we don't know much about the unexpected. Plus,
> in most cases, the "core" part of the VM is simply not very important.
> There just isn't much code there -- JamVM is 20KLOC, anybody could
> comfortably rewrite this.
Hmmm, well I used to work with the author of JamVM (Rob Lougher) and he's
one of the brightest guys I know. I think you'll find that the low LOC
figure is testament to his ability to write lean code rather than an
indication of how easy it is to knock off a JVM on a wet Sunday afternoon.
BTW has anyone asked Rob about donating JamVM to Harmony? As the (currently)
sole owner he should have no problem with switching licenses.
Cheers,
Dave
Re: JIRA and SVN
Posted by usman bashir <gr...@gmail.com>.
These are good thikning and i have few things more to add up.
first i think it will be better that we select a base architecture that is
completely based upon harmony rather then acquiring from other sides. then
what we can do ,we can took one two or even three VMS and incoperate them
with different target environments (i mean embeded, dektop,server) it will
help us to also seee the performance issues but also allow us to work in
parrallel in different areas.
and now the question is how it could be done, one thing i m sure that we
have guys from different enviornments like some from embeded culture and
some from tradationals so we should split the work according their nature.
altough it seem more vauge but i think we try to get few things on these
lines.
On 20 May 2005 17:54:11 -0600, Tom Tromey <tr...@redhat.com> wrote:
>
> >>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
>
> Geir> In the meantime, any comments on architectures of some of the VMs?
> Geir> I'm interest in having a balanced amount of upfront design that
> Geir> prevents us from preventing participation from unexpected places in
> Geir> the future...
>
> This is too vague -- we don't know much about the unexpected. Plus,
> in most cases, the "core" part of the VM is simply not very important.
> There just isn't much code there -- JamVM is 20KLOC, anybody could
> comfortably rewrite this.
>
>
> Instead I think Harmony should look at 2, and possibly 3, use cases:
>
> 1. Server use, e.g., some J2EE thing.
>
> 2. Desktop / applet use.
>
> 3. Embedded use (maybe).
>
>
> For 1, the execution engine and GC is really crucial. This is an area
> where hotspot-like dynamic recompilation implementations shine, IMO.
>
> For 2, again IMO, a gcj-like shared library approach is probably more
> useful. This is especially true if you expect to run more than one
> program using a given library, since in this case you are talking
> about controlling memory costs of the user environment as a whole.
>
> For 3 ... "embedded" covers a lot of ground, but I wanted to emphasize
> size-critical applications. In this arena you sometimes see folks who
> care more about size than performance. This affects choice of
> execution engine.
>
>
> I think it is possible to work well in all 3 environments with a
> single VM source base (though perhaps with different compilations of
> it).
>
> I think one way to do this would be an LLVM-based approach. This
> would require LLVM improvements, but let's be very clear about this --
> *any* approach we take to get to #1 and #2 is going to require a lot
> of compiler hacking. First, JITs have to be upgraded over time.
> Second, even with JikesRVM I think we're talking about at least
> writing new ports and an infrastructure for debuggers.
>
> One nice thing about the LLVM approach is that, hopefully, we could
> leverage other people's work. This is one reason gcj has been as
> widely ported as it is; the core gcj developers hardly ever do any
> architecture-specific work but instead we just inherit it from GCC.
>
> Tom
>
--
Usman Bashir
Certified IBM XML Solution Developer
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore
Re: JIRA and SVN
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
Geir> In the meantime, any comments on architectures of some of the VMs?
Geir> I'm interest in having a balanced amount of upfront design that
Geir> prevents us from preventing participation from unexpected places in
Geir> the future...
This is too vague -- we don't know much about the unexpected. Plus,
in most cases, the "core" part of the VM is simply not very important.
There just isn't much code there -- JamVM is 20KLOC, anybody could
comfortably rewrite this.
Instead I think Harmony should look at 2, and possibly 3, use cases:
1. Server use, e.g., some J2EE thing.
2. Desktop / applet use.
3. Embedded use (maybe).
For 1, the execution engine and GC is really crucial. This is an area
where hotspot-like dynamic recompilation implementations shine, IMO.
For 2, again IMO, a gcj-like shared library approach is probably more
useful. This is especially true if you expect to run more than one
program using a given library, since in this case you are talking
about controlling memory costs of the user environment as a whole.
For 3 ... "embedded" covers a lot of ground, but I wanted to emphasize
size-critical applications. In this arena you sometimes see folks who
care more about size than performance. This affects choice of
execution engine.
I think it is possible to work well in all 3 environments with a
single VM source base (though perhaps with different compilations of
it).
I think one way to do this would be an LLVM-based approach. This
would require LLVM improvements, but let's be very clear about this --
*any* approach we take to get to #1 and #2 is going to require a lot
of compiler hacking. First, JITs have to be upgraded over time.
Second, even with JikesRVM I think we're talking about at least
writing new ports and an infrastructure for debuggers.
One nice thing about the LLVM approach is that, hopefully, we could
leverage other people's work. This is one reason gcj has been as
widely ported as it is; the core gcj developers hardly ever do any
architecture-specific work but instead we just inherit it from GCC.
Tom
Re: JIRA and SVN
Posted by Bryce Leo <li...@gmail.com>.
> - JCVM is maybe the VM as I would have written it : it's pure C, quite easy,
> and yet focus on bringing good speed. The interp loop is well optimized but
> not very defensive : that means that a hole in the bytecode loader verifier
> could lead to a forged bytecode exploit. It doesn't do JIT, and instead
> generate C from .class and then call GCC and dynload the binary : that
> requires a lot of libraries and might not be the approach Harmony want.
> Also, I'm a bit worried about C code portability : does it compile and run
> on Win32 using MS compiler for example ?
I agree completely on that. After we strip away what we don't want, it
looks like we'd be left with a relatively small, but capable framework
to build upon. This is also to our benefit because newer programmers
(which we clearly have a good number of, which is great to see) would
be able to get up to speed relatively quickly.
I believe that the more complex JikesRVM has some great concepts and
that we could work with that through incorporating their ideas in the
Harmony code. I mention the complexity because we have some new and
relatively new programmers, and certainly a few new to VM's (as I
would be one of them) and that the simpler code base would help out
greatly in how quickly contributions could come in. This may or may
not be an issue, if it's not then that's fine but I feel that a larger
developer base is going to be needed even if it sacrifices the initial
starting point for the project.
> compared to a good JIT written in pure C however. As a framework, it seems
> to contain several compilers, maybe focusing on one main implementation
> would be better.
Strangely I think that the multiple compiler theory of Jikes is a
great idea, it allows work to be divided up smoothly and seems to
allow for a reasonable level of plugablity so if a group wanted to
work on a re-implementation it wouldn't be terribly difficult.
> So my choice would be to go for either a stripped JCVM and add JIT to it (it
> should already work with interpreted, so the JIT can be written in Java or
> C) or for a stripped Jikes that - while keeping the framework architecture
I think that this is a valid approach and gives a solid base while
leaving flexibility for growth.
--
~Bryce Leo
--Veritas Vos Liberabis--
Re: JIRA and SVN
Posted by Nicolas Cannasse <nc...@motion-twin.com>.
> Thanks Dims.
>
> I'd again urge to not commit anything until we hash out some
> policies. This is an important issue.
>
> In the meantime, any comments on architectures of some of the VMs?
> I'm interest in having a balanced amount of upfront design that
> prevents us from preventing participation from unexpected places in
> the future...
>
> geir
I quickly reviewed some of the proposed VMs source code :
- mudge is what I would call a 'trivial' VM : it works, but is more focused
on code elegancy and architecture that on performances. That's mean it's
small and easy to understand. But do a lot of C/C++ calls for each opcode
(i.e. the stack is a C++ class) that might not be inlined. It's interesting
as a small embedded JVM for scripting purposes.
- JCVM is maybe the VM as I would have written it : it's pure C, quite easy,
and yet focus on bringing good speed. The interp loop is well optimized but
not very defensive : that means that a hole in the bytecode loader verifier
could lead to a forged bytecode exploit. It doesn't do JIT, and instead
generate C from .class and then call GCC and dynload the binary : that
requires a lot of libraries and might not be the approach Harmony want.
Also, I'm a bit worried about C code portability : does it compile and run
on Win32 using MS compiler for example ?
- JikesRVM is a big framework. I like the idea of self-hosting the JIT, for
inlining reasons well explained here. Not sure about how it can speed up
compared to a good JIT written in pure C however. As a framework, it seems
to contain several compilers, maybe focusing on one main implementation
would be better.
So my choice would be to go for either a stripped JCVM and add JIT to it (it
should already work with interpreted, so the JIT can be written in Java or
C) or for a stripped Jikes that - while keeping the framework architecture
to enable replacement implementation - focus on one main implementation.
It's important choice since even if you are not caring about performances
right now, this will be in the end the thing that will say if the project is
either successful (speed can compete with Sun JVM) or failure (nice
implementation, but a "toy JVM").
Nicolas Cannasse
Re: JIRA and SVN
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Thanks Dims.
I'd again urge to not commit anything until we hash out some
policies. This is an important issue.
In the meantime, any comments on architectures of some of the VMs?
I'm interest in having a balanced amount of upfront design that
prevents us from preventing participation from unexpected places in
the future...
geir
On May 19, 2005, at 11:14 AM, Davanum Srinivas wrote:
> JIRA: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10740
> SVN: http://svn.apache.org/repos/asf/incubator/harmony/
>
> thanks,
> dims
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org