[arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

We've been talking about two threads of discussion, one working with  
a C/C++ based VM, one w/ Java.

Here's a Java one for discussion (just want to focus threads...)

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Ben Laurie <be...@algroup.co.uk>]

Santiago Gala wrote:
> El vie, 20-05-2005 a las 11:26 +0900, shudo@computer.org escribió:
> (...)
> 
>>Of course, such a runtime will have
>>another interpreter or a baseline compiler (written in C/C++?) and
>>Java-written JIT can be debugged exhaustively. But such a reflective
>>nature certainly makee debugging harder.
> 
> 
> Even if this is true (and I don't buy it completely), there is a very
> beneficial side-effect: the basic VM core, MM/GC, verifier and JIT make
> exceptionally good test cases for themselves, which would greatly reduce
> the possibility of bugs or memory leaks when the releases arrive to the
> users. At least in the basic data structure and bytecode
> interpretation/compilation parts. And specially so if the bootstrapping
> is done in a few machine architectures before releasing. Also as a side
> effect, performance tuning of the VM will be something intrinsic, as
> slowness will be noticed fast.

Given a halfway decent set of regression tests, these benefits are 
pretty marginal.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Santiago Gala <sg...@hisitech.com>]

El vie, 20-05-2005 a las 11:26 +0900, shudo@computer.org escribió:
(...)
> Of course, such a runtime will have
> another interpreter or a baseline compiler (written in C/C++?) and
> Java-written JIT can be debugged exhaustively. But such a reflective
> nature certainly makee debugging harder.

Even if this is true (and I don't buy it completely), there is a very
beneficial side-effect: the basic VM core, MM/GC, verifier and JIT make
exceptionally good test cases for themselves, which would greatly reduce
the possibility of bugs or memory leaks when the releases arrive to the
users. At least in the basic data structure and bytecode
interpretation/compilation parts. And specially so if the bootstrapping
is done in a few machine architectures before releasing. Also as a side
effect, performance tuning of the VM will be something intrinsic, as
slowness will be noticed fast.

Regards
-- 
Santiago Gala <sg...@hisitech.com>
High Sierra Technology, SLU

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Steve Blackburn <St...@anu.edu.au>]

shudo@computer.org wrote:

>Part of a runtime written in Java has to be interpreted, or compiled
>before executed. Throughput is sacrificed when interpreted and
>interactivity is sacrificed when compiled.
>  
>
The runtime itself can't realistically be interpreted because it would 
just be too slow.  So it is normally compiled.  However, the compilation 
of the core VM (as for the VM written in C) occurs ahead of time (using 
its own JIT and persisting the JITed image, which is the binary users 
execute).  Running an application does not require compilation of the 
VM.  So using Java need not be a cause for reduced interactivity.  Of 
course a JITed VM (writen in Java or C) will always have the challenge 
of avoiding reduced interactivty due to the jitting of user code.

--Steve

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Rodrigo Kumpera <ku...@gmail.com>]

I think jikesrvm can be executed from another JVM, this should make 
debugging easy.



On 5/19/05, shudo@computer.org <sh...@computer.org> wrote:
> 
> > The problem of Java written JVM/JIT isn't one of performance. You can
> > theoretically achieve the same performance (although I'm not 100%
> > convinced, I'm partially there)
> 
> It is reasonable to model the performance of a Java runtime in several
> aspects, especially throughput and interactivity (start-up time).
> JIT (and JVM) written in Java can achieve the same throughput as one
> written in C/C++/etc. But good start-up time / interactivity are more
> difficult to achieve and have to be elaborated.
> 
> Part of a runtime written in Java has to be interpreted, or compiled
> before executed. Throughput is sacrificed when interpreted and
> interactivity is sacrificed when compiled.
> 
> Another possible disadvantage, which might not be discussed, is
> reflective nature of Java-written JVM. This has been appealed as one of
> strong points in this list so far as removing boundary of
> languages. But we have to consider maintenance and debugging of the 
> runtime.
> Java-written JIT is compiled by itself eventually. In the case,
> debugging will become pretty hard. Of course, such a runtime will have
> another interpreter or a baseline compiler (written in C/C++?) and
> Java-written JIT can be debugged exhaustively. But such a reflective
> nature certainly makee debugging harder.
> 
> I myself do not have any experience on development of Java-written JIT
> and then I am not very sure how it makes maintainance and debugging
> harder. There have been a few Java-written JIT, Jikes RVM and OpenJIT
> and we may be able to have input from the developers of them if we hope.
> 
> Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
>

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[sh...@computer.org]

> The problem of Java written JVM/JIT isn't one of performance.  You can
> theoretically achieve the same performance (although I'm not 100%
> convinced, I'm partially there)

It is reasonable to model the performance of a Java runtime in several
aspects, especially throughput and interactivity (start-up time).
JIT (and JVM) written in Java can achieve the same throughput as one
written in C/C++/etc. But good start-up time / interactivity are more
difficult to achieve and have to be elaborated.

Part of a runtime written in Java has to be interpreted, or compiled
before executed. Throughput is sacrificed when interpreted and
interactivity is sacrificed when compiled.

Another possible disadvantage, which might not be discussed, is
reflective nature of Java-written JVM. This has been appealed as one of
strong points in this list so far as removing boundary of
languages. But we have to consider maintenance and debugging of the runtime.
Java-written JIT is compiled by itself eventually. In the case,
debugging will become pretty hard. Of course, such a runtime will have
another interpreter or a baseline compiler (written in C/C++?) and
Java-written JIT can be debugged exhaustively. But such a reflective
nature certainly makee debugging harder.

I myself do not have any experience on development of Java-written JIT
and then I am not very sure how it makes maintainance and debugging
harder. There have been a few Java-written JIT, Jikes RVM and OpenJIT
and we may be able to have input from the developers of them if we hope.

  Kazuyuki Shudo	shudo@computer.org	http://www.shudo.net/

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Steve Blackburn <St...@anu.edu.au>]

acoliver@apache.org wrote:

> The problem of Java written JVM/JIT isn't one of performance.  You can 
> theoretically achieve the same performance (although I'm not 100% 
> convinced, I'm partially there) especially if you're willing to 
> "extend" Java for the purpose of writing Java.
>
> That being said...doing so in a portable and platform independent way 
> is actually HARDER in Java than in C (and by C I mean 
> C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see 
> what I mean :-)

I don't see how it follows.  The Sable paper is a PhD thesis describing 
the design of Sable VM, which is written in C and is portable.  What 
does that say about the relative difficulty of doing it in Java?

Further, it is important to differentiate architectural portability from 
OS portability.

OS portability in a VM like Jikes RVM is very easy since there is a very 
well defined narrow interface to the OS, written in C.

Architectural portability is a different issue altogether.  If your VM 
has a JIT, then you will need a new back end (regardless of whether the 
JIT is written in C or Java).

--Steve

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Mark Brooks <jm...@hotmail.com>]

>That being said...doing so in a portable and platform independent way is 
>actually HARDER in Java than in C (and by C I mean 
>C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see what I 
>mean :-)
>
>-Andy

I'll certainly read the paper, but I find it difficult to believe that it is 
harder to implement portability with Java than with C++, given the latter's 
notorious "holes" in the spec that produce incompatibilities between 
different compilers and libraries using the same code.

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[ac...@apache.org]

> Andy is right:

Wow!

> 
> This is why I would like Harmony to have two VMs, one written in java
> and one written in C-or-friends: this would give us
> 
>  1) the goal of making things modular enough to allow to swap things
> around and allow parallel development
> 
>  2) create some internal (and friendly!) competition on speed and
> compliance :-)
> 
>  3) attract two different pools of talents
> 
>  4) allow compensation (easier to experiment in java than in C, harder
> to port java than C)
> 
> Thoughts?
> 

Yes.

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

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Ben Laurie <be...@algroup.co.uk>]

Weldon Washburn wrote:
> On 5/19/05, Stefano Mazzocchi <st...@apache.org> wrote:
> 
> 
>>This is why I would like Harmony to have two VMs, one written in java
>>and one written in C-or-friends: this would give us
> 
> 
> Well, I suspect if we design the interfaces correctly, we could do the
> above with one JVM instead of two.   Two competing Harmony
> implementations means ultimately one of them must die.  Harmony really
> needs one quickly evolvable code base.

I'm not sure I believe that - it seems entirely plausible to me that 
versions with different targets can happily coexist. This is 
particularly true if we succeed with the modularity aim - look at httpd 
- there are several different ways to do any particular thing, and with 
good reason. Obviously there is some immutable core, but that's 
relatively small.

>  The concept is to write the
> JVM in 100% C/C++ today.   Rationale:  C/C++ is battle tested for
> building OS and compiler systems.  Set a goal of rewritting the JIT in
> Java/C# by 2007.  If IT shops are happy deploying Harmony with the JIT
> written in Java, then set a goal of rewriting 90% of the VM in Java/C#
> by 2009.

You'd still need the bootstrapping non-Java VM for this, wouldn't you?

>> 1) the goal of making things modular enough to allow to swap things
>>around and allow parallel development
> 
> Yes!  Although it will be more challenging to create interfaces that
> will work for both Java and C/C++, I suspect the end result will be
> worthwhile.

Geir and I have been discussing this, I think we should try to put 
together a more concrete proposal.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Weldon Washburn <we...@gmail.com>]

On 5/20/05, Steve Blackburn <St...@anu.edu.au> wrote:
> I envisage that harmony is *seeded* with two VMs.  Under the "seeding"
> model both seeds are destined to die (that is, their *cores* die) once
> new core/s evolve.  I view this as a good thing.

Given a world with three different Harmony VMs, I probably only have
time to work on the one that will survive.

Re: CLASSPATH Licensing Issues (Was "Re: hi")

["Geir Magnusson Jr." <ge...@apache.org>]

On May 22, 2005, at 3:17 PM, Dana P'Simer wrote:

> On Fri, 2005-05-20 at 17:30 +0100, Ben Laurie wrote:
>
>> crispyalien wrote:
>>
>>> Hi, I am new here but I already have a stupid question ... :) ...Wil
>>> harmony use CLASPATH project or not?
>>>
>>
>> Almost certainly. Read the archives.
>>
>
> Hi, I am new here as well.  I have noticed that there seems to be a
> consensous that CLASSPATH is the way to go for the java(x).* classes.

GNU Classpath is our only option right now, and we're going to do  
what we can to use it, yes.

> CLASSPATH is licensed under GPL with a special exception allowing
> linking to independent modules to produce an executable.  Lets call  
> this
> GPL-.  It sounds alot like LGPL but that is not what the website says.
> How can Harmony use CLASSPATH if it will be licensed under the Apache
> License?  Three possible solutions come to mind:
>
>      1. Since it is GPL, Harmony could just depend on it.

Um, well, no :)

Don't forget that nasty viral stuff in the GPL :)

>      2. Harmony forks it and leaves it as GPL+.

I don't know what "GPL+" means, but Harmony will not be forking GNU  
Classpath.  If anything, we'll ensure that donations we get related  
to that area are usable by GNU Classpath if they want to.  We're here  
to work together as we can.  We may not solve the license problem,  
but that isn't why we're here.

>      3. Harmony forks it and relicense it to Apache License.

Impossible.

a) Harmony won't fork GNU Classpath
b) You can't relicense code like that.

>
> Option 1 seems good but would not allow harmony to get changes  
> specific
> to it's goals.  Option 2 has the same licensing problems as option  
> 2 but
> would allow harmony to make changes specific to it's goals.  Also
> Options 1 & 2 suffer from another stumbling block: some developers,
> particularly corperate sponsored developers, might not want to
> contribute to an LGPL'd product.  Option 3 does not seem possible  
> since
> that would require all contributors to the CLASSPATH project to agree.
>
> None of these solutions is optimal.  Another option might be to start
> with CLASSPATH as a base and develop a replacement library under the
> Apache License, a project I would be happy to contribute to.
>

For now, we are going to be working with GNU Classpath, and if I have  
my way ;) it will be through an agreed-upon interface that isn't GPL- 
ed so that GNU Classpath will just be a drop-in class library for us.

In parallel, we are working on resolving the licensing issues, but  
really trying to keep this from holding back technology collaboration.

Thanks

geir

>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

CLASSPATH Licensing Issues (Was "Re: hi")

[Dana P'Simer <da...@dhptech.com>]

On Fri, 2005-05-20 at 17:30 +0100, Ben Laurie wrote:
> crispyalien wrote:
> > Hi, I am new here but I already have a stupid question ... :) ...Wil 
> > harmony use CLASPATH project or not?
> 
> Almost certainly. Read the archives.

Hi, I am new here as well.  I have noticed that there seems to be a
consensous that CLASSPATH is the way to go for the java(x).* classes.
CLASSPATH is licensed under GPL with a special exception allowing
linking to independent modules to produce an executable.  Lets call this
GPL-.  It sounds alot like LGPL but that is not what the website says.
How can Harmony use CLASSPATH if it will be licensed under the Apache
License?  Three possible solutions come to mind:

     1. Since it is GPL, Harmony could just depend on it.
     2. Harmony forks it and leaves it as GPL+.
     3. Harmony forks it and relicense it to Apache License.

Option 1 seems good but would not allow harmony to get changes specific
to it's goals.  Option 2 has the same licensing problems as option 2 but
would allow harmony to make changes specific to it's goals.  Also
Options 1 & 2 suffer from another stumbling block: some developers,
particularly corperate sponsored developers, might not want to
contribute to an LGPL'd product.  Option 3 does not seem possible since
that would require all contributors to the CLASSPATH project to agree.

None of these solutions is optimal.  Another option might be to start
with CLASSPATH as a base and develop a replacement library under the
Apache License, a project I would be happy to contribute to.

Thanks,

Dana H. P'Simer, Jr.

Re: hi

[Ben Laurie <be...@algroup.co.uk>]

crispyalien wrote:
> Hi, I am new here but I already have a stupid question ... :) ...Wil 
> harmony use CLASPATH project or not?

Almost certainly. Read the archives.

> What OSes should be targeted at first? BeOS one of them?

The targetted OSes will be entirely decided by those who write code. If 
you want to make BeOS work, I'm sure we won't stand in your way.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

hi

[crispyalien <cr...@gmail.com>]

Hi, I am new here but I already have a stupid question ... :) ...Wil 
harmony use CLASPATH project or not? What OSes should be targeted at 
first? BeOS one of them?

best regards,
 Valentin

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Craig Blake <cr...@mac.com>]

Symbolic +1

Sounds like the way to go.

Craig

On May 20, 2005, at 12:01 AM, Steve Blackburn wrote:

>
> Weldon Washburn wrote:
>
>
>> On 5/19/05, Stefano Mazzocchi <st...@apache.org> wrote:
>>
>>
>>> This is why I would like Harmony to have two VMs, one written in  
>>> java
>>> and one written in C-or-friends: this would give us
>>>
>>>
>> Well, I suspect if we design the interfaces correctly, we could do  
>> the
>> above with one JVM instead of two.   Two competing Harmony
>> implementations means ultimately one of them must die.
>>
>>
> I envisage that harmony is *seeded* with two VMs.  Under the  
> "seeding" model both seeds are destined to die (that is, their  
> *cores* die) once new core/s evolve.  I view this as a good thing.
>
>
>>  Harmony really
>> needs one quickly evolvable code base.  The concept is to write the
>> JVM in 100% C/C++ today.   Rationale:  C/C++ is battle tested for
>> building OS and compiler systems.
>>
>>
> As for a language "battle tested for building compiler systems", I  
> think Java has well and truly earned that badge (javac? antlr?  
> soot? jikesrvm?...).  I don't know about an OS, but we're not  
> building an OS. We have pushed Java hard in Jikes RVM, and as a  
> long time C/C++ systems programmer who 6 or so years ago started  
> working on a Java-in-Java VM, I for one can say "I never want to go  
> back!" :-)  As an apache project, we should be looking forward, not  
> backward.  Having said all of that, I am all for a development  
> model that allows us to build the core and components in either  
> language.
>
>
>>  Set a goal of rewritting the JIT in
>> Java/C# by 2007.  If IT shops are happy deploying Harmony with the  
>> JIT
>> written in Java, then set a goal of rewriting 90% of the VM in  
>> Java/C#
>> by 2009.
>>
>>
> "IT shops" will judge Harmony by its performance, robustness and  
> completeness.  I happen to believe we are going to meet those goals  
> better if we use Java.  Again, I am all for a model that allows us  
> to use JITs written in C, C++ or Java.
>
>
>> Yes!  Although it will be more challenging to create interfaces that
>> will work for both Java and C/C++, I suspect the end result will be
>> worthwhile.
>>
>>
> As far as GC goes (arguably the most complex interface), we have  
> done this with MMTk & Rotor.
>
>
>> Modularization allows specialization.  Specialization fosters faster
>> evolution.  Harmony is an opportunity to build an infrastructure that
>> can outrun the existing monolithic JVM code bases.  You don't need to
>> know the entire system to work on a given module
>>
>>
> I could not agree more.
>
>
>> .  A short list of JVM
>> modules: JIT, GC, threading/sync, class loader, verifier, OS
>> portablility layer.  Different JITs and GCs might actually decide to
>> sub-modularize if they like.  For example JIT "X" might have a single
>> high-level IR module and separate low-level modules for each
>> instruction set architecture supported.
>>
>>
> I imagine that a "compiler policy" will become a (thin) module  
> which in turn interfaces to sub-modules which are particular  
> compiler instances.  For example an adaptive recompilation policy  
> could interface to the core vm on one side, and multiple compiler  
> choices on the other.
>
> Last Friday, I made the following proposal:
>
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 
> 200505.mbox/%3c428439D6.5080709@anu.edu.au%3e
>
> In the context of the current discussion I'd like to re-advocate  
> that proposal.  It is consistent with what Stefano has suggested.
>
> To summarize:
>
> 1. Leverage existing momentum by seeding the project with two  
> existing VMs
> 2. Leverage existing work by focusing on modularity of major  
> reusable components (including components from outside of the seed  
> VMs).
> 3. Concurrently design new VM cores.
>
> Modularizing the seed VMs will provide the group with a great deal  
> of insight into how new VM cores should be built.  I say "cores"  
> for three reasons: a) the cores will (by defn) be small, so with a  
> modular framework, having multiple cores should be feasible, b)  
> different cores can target different needs, c) we can explore  
> different implementation strategies.
>
> --Steve
>
>
>

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Steve Blackburn <St...@anu.edu.au>]

Weldon Washburn wrote:

>On 5/19/05, Stefano Mazzocchi <st...@apache.org> wrote:
>  
>
>>This is why I would like Harmony to have two VMs, one written in java
>>and one written in C-or-friends: this would give us
>>    
>>
>Well, I suspect if we design the interfaces correctly, we could do the
>above with one JVM instead of two.   Two competing Harmony
>implementations means ultimately one of them must die.
>
I envisage that harmony is *seeded* with two VMs.  Under the "seeding" 
model both seeds are destined to die (that is, their *cores* die) once 
new core/s evolve.  I view this as a good thing.

>  Harmony really
>needs one quickly evolvable code base.  The concept is to write the
>JVM in 100% C/C++ today.   Rationale:  C/C++ is battle tested for
>building OS and compiler systems.
>
As for a language "battle tested for building compiler systems", I think 
Java has well and truly earned that badge (javac? antlr? soot? 
jikesrvm?...).  I don't know about an OS, but we're not building an OS. 
We have pushed Java hard in Jikes RVM, and as a long time C/C++ systems 
programmer who 6 or so years ago started working on a Java-in-Java VM, I 
for one can say "I never want to go back!" :-)  As an apache project, we 
should be looking forward, not backward.  Having said all of that, I am 
all for a development model that allows us to build the core and 
components in either language.

>  Set a goal of rewritting the JIT in
>Java/C# by 2007.  If IT shops are happy deploying Harmony with the JIT
>written in Java, then set a goal of rewriting 90% of the VM in Java/C#
>by 2009.
>  
>
"IT shops" will judge Harmony by its performance, robustness and 
completeness.  I happen to believe we are going to meet those goals 
better if we use Java.  Again, I am all for a model that allows us to 
use JITs written in C, C++ or Java.

>Yes!  Although it will be more challenging to create interfaces that
>will work for both Java and C/C++, I suspect the end result will be
>worthwhile.
>  
>
As far as GC goes (arguably the most complex interface), we have done 
this with MMTk & Rotor.

>Modularization allows specialization.  Specialization fosters faster
>evolution.  Harmony is an opportunity to build an infrastructure that
>can outrun the existing monolithic JVM code bases.  You don't need to
>know the entire system to work on a given module
>
I could not agree more.

>.  A short list of JVM
>modules: JIT, GC, threading/sync, class loader, verifier, OS
>portablility layer.  Different JITs and GCs might actually decide to
>sub-modularize if they like.  For example JIT "X" might have a single
>high-level IR module and separate low-level modules for each
>instruction set architecture supported.
>  
>
I imagine that a "compiler policy" will become a (thin) module which in 
turn interfaces to sub-modules which are particular compiler instances.  
For example an adaptive recompilation policy could interface to the core 
vm on one side, and multiple compiler choices on the other.

Last Friday, I made the following proposal:

http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/%3c428439D6.5080709@anu.edu.au%3e

In the context of the current discussion I'd like to re-advocate that 
proposal.  It is consistent with what Stefano has suggested.

To summarize:

1. Leverage existing momentum by seeding the project with two existing VMs
2. Leverage existing work by focusing on modularity of major reusable 
components (including components from outside of the seed VMs).
3. Concurrently design new VM cores.

Modularizing the seed VMs will provide the group with a great deal of 
insight into how new VM cores should be built.  I say "cores" for three 
reasons: a) the cores will (by defn) be small, so with a modular 
framework, having multiple cores should be feasible, b) different cores 
can target different needs, c) we can explore different implementation 
strategies.

--Steve

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Weldon Washburn <we...@gmail.com>]

On 5/19/05, Stefano Mazzocchi <st...@apache.org> wrote:

> This is why I would like Harmony to have two VMs, one written in java
> and one written in C-or-friends: this would give us

Well, I suspect if we design the interfaces correctly, we could do the
above with one JVM instead of two.   Two competing Harmony
implementations means ultimately one of them must die.  Harmony really
needs one quickly evolvable code base.  The concept is to write the
JVM in 100% C/C++ today.   Rationale:  C/C++ is battle tested for
building OS and compiler systems.  Set a goal of rewritting the JIT in
Java/C# by 2007.  If IT shops are happy deploying Harmony with the JIT
written in Java, then set a goal of rewriting 90% of the VM in Java/C#
by 2009.

> 
>  1) the goal of making things modular enough to allow to swap things
> around and allow parallel development
Yes!  Although it will be more challenging to create interfaces that
will work for both Java and C/C++, I suspect the end result will be
worthwhile.
> 
>  2) create some internal (and friendly!) competition on speed and
> compliance :-) 
Good idea.
> 
>  3) attract two different pools of talents
Modularization allows specialization.  Specialization fosters faster
evolution.  Harmony is an opportunity to build an infrastructure that
can outrun the existing monolithic JVM code bases.  You don't need to
know the entire system to work on a given module.  A short list of JVM
modules: JIT, GC, threading/sync, class loader, verifier, OS
portablility layer.  Different JITs and GCs might actually decide to
sub-modularize if they like.  For example JIT "X" might have a single
high-level IR module and separate low-level modules for each
instruction set architecture supported.
> 
>  4) allow compensation (easier to experiment in java than in C, harder
> to port java than C)
> 
> Thoughts?
> 
> --
> Stefano.
> 
>

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 19, 2005, at 9:29 AM, Stefano Mazzocchi wrote:

> Renaud BECHADE wrote:
>
>>>> That being said...doing so in a portable and platform  
>>>> independent way is
>>>> actually HARDER in Java than in C (and by C I mean
>>>> C/C++/Objective-C...whatever).  Read the Sable paper...  you'll  
>>>> see what
>>>> I mean :-)
>>>>
>>
>>
>> Why should it be so? I guess the platform dependent code emission  
>> code is
>> err ... not platform independent anyway. Also, if the reference  
>> platform is
>> for instance LLVM, or some other, off the shelf, low-level  
>> intermediate
>> representation, then there is no more platform dependence to take  
>> care of at
>> the JVM level (I suppose)...
>>
>
> Andy is right: "writing in Java" *above* the JVM interface means  
> you are
> creating bytecode and all the portability efforts were taken care for
> you by the JVM makers. "writing in Java" *below* the JVM interface  
> means
> that you have to do, at some point, some native code transformations
> yourselfs, for every single different CPU architecture.
>
> Writing a JVM in a compilable higher language means that the compiler
> will do all that for you.
>
> So, interestingly enough, writing a JVM in java could allow java
> developers to work on it more easily (java programmers tend to be
> allergic to C and friends), but would require a lot more work,
> portability wise.
>


I think that's a function of whether or not you ever worked in C and C 
++.  I spent a lot of time with C and C++ and have no problem using  
it when required, although it hasn't been required in what I do for a  
long time.


> It's also true that this kind of portability is perfectly  
> parallelizable
> and it's CPU-dependent, not OS-dependent (well, really it's
> (CPU,OS)-dependent, but the two are almost orthogonal axis) and there
> are not so many CPU architectures remaining out there in the server  
> market.
>
> This might hit us on the mobile/embedded market, though and hit us
> pretty hard.
>
> This is why I would like Harmony to have two VMs, one written in java
> and one written in C-or-friends: this would give us
>
>  1) the goal of making things modular enough to allow to swap things
> around and allow parallel development
>
>  2) create some internal (and friendly!) competition on speed and
> compliance :-)
>
>  3) attract two different pools of talents
>
>  4) allow compensation (easier to experiment in java than in C, harder
> to port java than C)
>
> Thoughts?

I'm certainly open to having two, but don't think that it should be  
in any way a goal.  If there's interest, and people work on it, I  
think that's great - it's good for portability testing.  I'd ask that  
we require working together on the modularity.

I know that in the past, that Jikes was able to clean some production  
VMs in microbenchmarks, but as I understand it, there's now a large  
performance gap.  One of our goals is equivalent performance.

geir

>
> -- 
> Stefano.
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Ahmed Saad <my...@gmail.com>]

hi all.. you know i think we all should work to bring the spirit of harmoney 
to the open source movement in general... for example as a web developer i 
read about a new php mvc-based framework every couple of days with really 
nothing new to introduce to the scene.... so if all *similiar* open source 
projects *harmonized* their efforts... i think we will be in a more 
productive/innovative open source world... nevertheless, projects with 
different philosophies about the same thing should just remain separate 
trying to compete with each other....sorry for my off subject

On 5/20/05, crispyalien <cr...@gmail.com> wrote:
> 
> Hi, I just wanted to say that a free opensource VM with do a lot of
> harmonyzation in Java world. This is more or les the missing pice. There
> are some free java VMs but they will never be used in critical by the
> companys to run there applications if it won't be backed-up by a big
> (and well known for it's qality) company/fundation. I think Appache
> fundation cand be that sponsor. I also believe that Harmony should only
> be about VM+classpath. But I could also see the meaning in having a tool
> development pack. This could be done by some other project. Maybe
> Appache could take the lead here too but this is another story.
> 
> best regards,
> Valentin
> 
> Gary Affonso wrote:
> 
> >On 5/20/05 3:38 AM, "Geir Magnusson Jr." <ge...@apache.org> wrote:
> >
> >
> >
> >>On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
> >>
> >>
> >>
> >>>Another point that is unrelated, but what about the "packaging" of
> >>>the VM?
> >>>Do we plan to release it with say Eclipse + Server (JSF + IDE +
> >>>object DB or
> >>>O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
> >>>
> >>>
> >>No. Why would we do this?
> >>
> >>
> >
> >I could see why someone (at least myself) might tend to think in this
> >direction.
> >
> >This project has been called "Harmony" and, well, there's a lot in the 
> Java
> >world that could stand to be "Harmonized". The various ORM solutions, the
> >IDE's, the webapp frameworks, etc. Hell, a good chunk of the "disharmony"
> >with Java right now is serious rift between Sun, which pushes EJB, and 
> the
> >"lightweight" folks who are seeing a shocking (and, IMO, deserved) amount 
> of
> >success with creating and using an EJB alternative (Spring, Hibernate,
> >etc.).
> >
> >I'm not saying I think this Harmony project should try to and harmonize 
> any
> >of those thing. It's got its job cut out for it to "harmonize" the 
> various
> >efforts around...
> >
> > * a JVM
> > * a compiler
> > * a class library
> >
> >...without thinking about the upper layers of the Java stack. I think the
> >scope of this effort is clear to those who are moderately "in the know".
> >
> >But it's not a big surprise (at least to me) that when moderately "out of
> >the know" people hear "Java Harmony" they might think the effort extends
> >beyond just the core components. Indeed, they'll probably assume that it
> >addresses the aspects of Java that are, to many, are the most acrimonious 
> to
> >begin with (EJB vs Lightweight or NetBeans/Swing vs Eclipse/SWT).
> >
> >If nothing else, I'd suggest this be in a FAQ somewhere so that it's 
> clear
> >that "Harmony" intends to address just a small subset of the java world, 
> not
> >even the one that gets the most "acrimony" in the press and on blogs.
> >
> >- Gary
> >
> >
> >
> >
> 
>

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Gary Affonso <gl...@greywether.com>]

On 5/20/05 12:20 PM, "crispyalien" <cr...@gmail.com> wrote:

> Hi, I just wanted to say that a free opensource VM with do a lot of
> harmonyzation in Java world.

I agree that it will be of great benefit.  It's why I'm on this list, after
all.

I guess my point, though, is that this project doesn't "disharmonize" the
aspects of the Java world that (at least from where I sit) get the most
press.

> This is more or les the missing pice.

Yup, for a complete end-to-end OpenSource Java solution, it is the missing
piece.  But the project isn't call "Missing Piece" it's called "Harmony" and
that's going to cause some confusion.

Just saying people shouldn't be surprised when questions like...

  "will Harmony fix the <insert favorite Java disharmony>"?

...get asked.

> There 
> are some free java VMs but they will never be used in critical by the
> companys to run there applications if it won't be backed-up by a big
> (and well known for it's qality) company/fundation. I think Appache
> fundation cand be that sponsor. I also believe that Harmony should only
> be about VM+classpath.

Me too.  I'm *not* advocating for a change of scope.  Harmony is what it is:
a project to create a standards compliant, OpenSource, Java compiler, JVM, a
class library.  (If one wanted to blaspheme, one might be inclined to point
out that it's essentially the Java equivalent of Mono in terms of scope and
goals.)

Just pointing out that the project's name "Harmony" isn't particularly good
at indicating what that scope is.  Indeed, it can be a bit misleading when
considering the other, high-visibility, areas within Java where "disharmony"
exists.

- Gary

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[crispyalien <cr...@gmail.com>]

Hi, I just wanted to say that a free opensource VM with do a lot of 
harmonyzation in Java world. This is more or les the missing pice. There 
are some free java VMs but they will never be used in critical by the 
companys to run there applications if it won't be backed-up by a big 
(and well known for it's qality) company/fundation. I think Appache 
fundation cand be that sponsor. I also believe that Harmony should only 
be about VM+classpath. But I could also see the meaning in having a tool 
development pack. This could be done by some other project. Maybe 
Appache could take the lead here too but this is another story.

best regards,
  Valentin

Gary Affonso wrote:

>On 5/20/05 3:38 AM, "Geir Magnusson Jr." <ge...@apache.org> wrote:
>
>  
>
>>On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
>>
>>    
>>
>>>Another point that is unrelated, but what about the "packaging" of
>>>the VM?
>>>Do we plan to release it with say Eclipse + Server (JSF + IDE +
>>>object DB or
>>>O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
>>>      
>>>
>>No.  Why would we do this?
>>    
>>
>
>I could see why someone (at least myself) might tend to think in this
>direction.
>
>This project has been called "Harmony" and, well, there's a lot in the Java
>world that could stand to be "Harmonized".  The various ORM solutions, the
>IDE's, the webapp frameworks, etc.  Hell, a good chunk of the "disharmony"
>with Java right now is serious rift between Sun, which pushes EJB, and the
>"lightweight" folks who are seeing a shocking (and, IMO, deserved) amount of
>success with creating and using an EJB alternative (Spring, Hibernate,
>etc.).
>
>I'm not saying I think this Harmony project should try to and harmonize any
>of those thing.   It's got its job cut out for it to "harmonize" the various
>efforts around...
>
>  * a JVM
>  * a compiler
>  * a class library
>
>...without thinking about the upper layers of the Java stack.  I think the
>scope of this effort is clear to those who are moderately "in the know".
>
>But it's not a big surprise (at least to me) that when moderately "out of
>the know" people hear "Java Harmony" they might think the effort extends
>beyond just the core components.  Indeed, they'll probably assume that it
>addresses the aspects of Java that are, to many, are the most acrimonious to
>begin with (EJB vs Lightweight or NetBeans/Swing vs Eclipse/SWT).
>
>If nothing else, I'd suggest this be in a FAQ somewhere so that it's clear
>that "Harmony" intends to address just a small subset of the java world, not
>even the one that gets the most "acrimony" in the press and on blogs.
>
>- Gary
>
>
>  
>

RE: [arch] VM Candidate : JikesRVMhttp://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

＞If nothing else, I'd suggest this be in a FAQ somewhere so that it's clear
＞that "Harmony" intends to address just a small subset of the java world,
not
＞even the one that gets the most "acrimony" in the press and on blogs.

Including a good report on how well these work with the VM /NOW/.
(conceptually everything should work, but practically...)

-----Original Message-----
From: Gary Affonso [mailto:glists@greywether.com]
Sent: Saturday, May 21, 2005 3:45 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVMhttp://jikesrvm.sourceforge.net/

On 5/20/05 3:38 AM, "Geir Magnusson Jr." <ge...@apache.org> wrote:

>
> On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
>
>>
>>
>> Another point that is unrelated, but what about the "packaging" of
>> the VM?
>> Do we plan to release it with say Eclipse + Server (JSF + IDE +
>> object DB or
>> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
>
> No.  Why would we do this?

I could see why someone (at least myself) might tend to think in this
direction.

This project has been called "Harmony" and, well, there's a lot in the Java
world that could stand to be "Harmonized".  The various ORM solutions, the
IDE's, the webapp frameworks, etc.  Hell, a good chunk of the "disharmony"
with Java right now is serious rift between Sun, which pushes EJB, and the
"lightweight" folks who are seeing a shocking (and, IMO, deserved) amount of
success with creating and using an EJB alternative (Spring, Hibernate,
etc.).

I'm not saying I think this Harmony project should try to and harmonize any
of those thing.   It's got its job cut out for it to "harmonize" the various
efforts around...

  * a JVM
  * a compiler
  * a class library

...without thinking about the upper layers of the Java stack.  I think the
scope of this effort is clear to those who are moderately "in the know".

But it's not a big surprise (at least to me) that when moderately "out of
the know" people hear "Java Harmony" they might think the effort extends
beyond just the core components.  Indeed, they'll probably assume that it
addresses the aspects of Java that are, to many, are the most acrimonious to
begin with (EJB vs Lightweight or NetBeans/Swing vs Eclipse/SWT).

If nothing else, I'd suggest this be in a FAQ somewhere so that it's clear
that "Harmony" intends to address just a small subset of the java world, not
even the one that gets the most "acrimony" in the press and on blogs.

- Gary

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Gary Affonso <gl...@greywether.com>]

On 5/20/05 3:38 AM, "Geir Magnusson Jr." <ge...@apache.org> wrote:

> 
> On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
> 
>> 
>> 
>> Another point that is unrelated, but what about the "packaging" of
>> the VM?
>> Do we plan to release it with say Eclipse + Server (JSF + IDE +
>> object DB or
>> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
> 
> No.  Why would we do this?

I could see why someone (at least myself) might tend to think in this
direction.

This project has been called "Harmony" and, well, there's a lot in the Java
world that could stand to be "Harmonized".  The various ORM solutions, the
IDE's, the webapp frameworks, etc.  Hell, a good chunk of the "disharmony"
with Java right now is serious rift between Sun, which pushes EJB, and the
"lightweight" folks who are seeing a shocking (and, IMO, deserved) amount of
success with creating and using an EJB alternative (Spring, Hibernate,
etc.).

I'm not saying I think this Harmony project should try to and harmonize any
of those thing.   It's got its job cut out for it to "harmonize" the various
efforts around...

  * a JVM
  * a compiler
  * a class library

...without thinking about the upper layers of the Java stack.  I think the
scope of this effort is clear to those who are moderately "in the know".

But it's not a big surprise (at least to me) that when moderately "out of
the know" people hear "Java Harmony" they might think the effort extends
beyond just the core components.  Indeed, they'll probably assume that it
addresses the aspects of Java that are, to many, are the most acrimonious to
begin with (EJB vs Lightweight or NetBeans/Swing vs Eclipse/SWT).

If nothing else, I'd suggest this be in a FAQ somewhere so that it's clear
that "Harmony" intends to address just a small subset of the java world, not
even the one that gets the most "acrimony" in the press and on blogs.

- Gary

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 23, 2005, at 9:48 PM, Rodrigo Kumpera wrote:

> A good way to define milestones that are perceptible by the general  
> public
> are FOSS that runs fine on Harmony. Something like a Geronimo or  
> Eclipse
> milestones.

heh - what would say those are?

>  It's a way to deliver something that is valuable before the JCK  
> compliant
> product ships,which will take a couple of years.
>  Rodrigo
>
>  On 5/23/05, Renaud BECHADE <re...@numerix.com> wrote:
>
>>
>>
>>
>> ＞It would be great if people would bundle Harmony with stuff (and  
>> plan
>> ＞to do it w/ Geronimo when that time comes), bit it's way out of  
>> scope
>> ＞for *this* project to get into the business of reditributing  
>> software
>> ＞from outside of the ASF.
>>
>> Hum... I still think there is a minimum distribution effort to be  
>> done
>> (call
>> that marketing if you want) to get people to actually test the VM,  
>> as in
>> the
>> beginning it might be very, very, very unlikely that absolutely  
>> everything
>> runs out of the box as replacement for J2SE 5 or 6... So we will  
>> need to
>> help them try it out.
>> (Basically, to me some nice IDE + app-server + a few dummy  
>> examples, swing
>> &
>> jsf for instance, is the bare minimum to provide as a
>> demo-micro-distribution-to-test-it-in-reasonable-situations; the  
>> IDE only
>> might be non-ASF, as I don't think there is a widely accepted ASF-IDE
>> [well, yes: Eclipse plugins for Tapestry & co. :-); please accept my
>> apologies if there is one, my point is not selling Eclipse in  
>> particular
>> but
>> having an IDE to play with the VM, for instance to test  
>> practically its
>> debugging interface, and show it to others])
>>
>> Just think of it in OS terms as a
>> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases  
>> (a stuff
>> for decision makers). Bundling with 1 or 2 apps we/the ASF did not  
>> write
>> is
>> not to be covered by NIH syndrome in my opinion, but rather a way  
>> to prove
>> it actually works to decision makers. (After all, mono bundles  
>> mono with
>> monodevelop [or rather monodevelop with mono, I think], and Sun  
>> bundles
>> Netbeans with J2SE...)
>>
>> Just the same as if you develop, say, a 'new simulation algorithm for
>> reaction-diffusion discrete systems, which is "discrete, adaptive"  
>> '[1].
>> In
>> order to get credit from ordinary people (who might not be  
>> familiar with
>> its
>> technical beauty, right?), even if the scope of this project is on  
>> soft
>> architecture and math analysis, you might have to provide  
>> scientifically
>> uninteresting display that it works... (Spiraling pattern for  
>> simplified
>> models of myocardium cells electrophysiology: that is, simulation of
>> cardiac
>> arrhythmia in dummy demo-only situation, so here the mystery of  
>> what it is
>> ends here [2])
>> That is, with some 'out of scope' effort you get images for the  
>> layman to
>> be
>> impressed...
>>
>> To come back to more soft-only concerns, IMHO providing  
>> distributors with
>> the minimum tool they need to polish the VM-to-VM discrepancies and
>> external
>> developers the minimum tools they need to test their soft on the  
>> Harmony
>> VM
>> (and get a chance to actually do something - not just: 'it does  
>> not work'
>> -
>> if it does not work the way they planned it) might be a big ROI,
>> comparatively small effort.
>>
>> A VM without the bare minimum support tools might appear a bit  
>> useless to
>> many people (and also impractical to test with an ergonomic, long- 
>> lasting
>> experience of beautiful-looking piece of software). If you take,  
>> say, the
>> FreeBSD case, you don't have much choice for instance for the VM  
>> you use
>> with your favorite IDE, so that ipso facto you stick with the VM  
>> you get
>> in
>> stock (because the other VMs might be good, but if it's a  
>> nightmare to
>> reconfigure it all to use your VM of choice with your favorite  
>> IDE...),
>> just
>> like IE sticks with many win$ users.
>>
>> As a use case, if I want to test a piece of software, well I would  
>> like it
>> to be kind of "download it and play".
>>
>> Regards,
>>
>> RB
>>
>> [1] Sorry I take examples of my own... (Well, the research I once  
>> did)
>> [2] It was so simplified it was meaningless in my opinion, but I  
>> got my
>> credits with it...
>>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
>> Sent: Monday, May 23, 2005 8:58 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [arch] VM Candidate : JikesRVM
>> http://jikesrvm.sourceforge.net/
>>
>>
>> On May 22, 2005, at 9:27 PM, Renaud BECHADE wrote:
>>
>>
>>>
>>>
>>> ＞ No. Why would we do this?
>>> People tend to be lazy. If they have a bundle with one VM, then
>>> they will
>>> use that VM, for most of them, IMHO. I seriously doubt we can have
>>> people
>>> trust an alternative VM if it is not a piece of cake (sort of "with
>>> a one
>>> liner on the console you are started") to develop with it, and as
>>> it is
>>> unlikely it will support everything perfectly at the beginning (to
>>> convince
>>> you let us consider running .NET soft on a Linux/Mono machine, or
>>> XSP code
>>> on a FreeBSD/mono machine - sometimes it crashes badly, or again
>>> freeware
>>> support of Flash swf, all of which can have slightly strange  
>>> behaviors
>>> sometimes, if compared with commercial equivalents, so that a
>>> development
>>> that is not started /from the beginning/ with them might get into
>>> troubles)
>>> there will be some intensive testing to do on real applications,
>>> which might
>>> involve some patches on "must-have" packages such as Eclipse / J2EE
>>> etc.
>>> (including strategies as simple as repackaging with a bit less
>>> modules to
>>> have it actually run because some funny class is not here)
>>>
>>
>>
>> It would be great if people would bundle Harmony with stuff (and plan
>> to do it w/ Geronimo when that time comes), bit it's way out of scope
>> for *this* project to get into the business of reditributing software
>> from outside of the ASF.
>>
>> geir
>>
>>
>>>
>>> RB
>>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
>>> Sent: Friday, May 20, 2005 7:38 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [arch] VM Candidate : JikesRVM http://
>>> jikesrvm.sourceforge.net/ <http://jikesrvm.sourceforge.net/>
>>>
>>>
>>> On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
>>>
>>>
>>>
>>>>
>>>>
>>>> Another point that is unrelated, but what about the "packaging" of
>>>> the VM?
>>>> Do we plan to release it with say Eclipse + Server (JSF + IDE +
>>>> object DB or
>>>> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
>>>>
>>>>
>>>
>>> No. Why would we do this?
>>>
>>> We want our JRE or JDK to be an alternative to the existing JREs and
>>> JDKs w/o having people worry about all the cruft.
>>>
>>> If you had an interest in bundling for some reason, you could of
>>> course take the thing and do that elsewhere (or start a separate
>>> project here if there was enough support and a decent rationale...)
>>>
>>> geir
>>>
>>> --
>>> Geir Magnusson Jr +1-203-665-6437
>>> geirm@apache.org
>>>
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Rodrigo Kumpera <ku...@gmail.com>]

A good way to define milestones that are perceptible by the general public 
are FOSS that runs fine on Harmony. Something like a Geronimo or Eclipse 
milestones.
 It's a way to deliver something that is valuable before the JCK compliant 
product ships,which will take a couple of years.
 Rodrigo

 On 5/23/05, Renaud BECHADE <re...@numerix.com> wrote: 
> 
> 
> 
> ＞It would be great if people would bundle Harmony with stuff (and plan
> ＞to do it w/ Geronimo when that time comes), bit it's way out of scope
> ＞for *this* project to get into the business of reditributing software
> ＞from outside of the ASF.
> 
> Hum... I still think there is a minimum distribution effort to be done 
> (call
> that marketing if you want) to get people to actually test the VM, as in 
> the
> beginning it might be very, very, very unlikely that absolutely everything
> runs out of the box as replacement for J2SE 5 or 6... So we will need to
> help them try it out.
> (Basically, to me some nice IDE + app-server + a few dummy examples, swing 
> &
> jsf for instance, is the bare minimum to provide as a
> demo-micro-distribution-to-test-it-in-reasonable-situations; the IDE only
> might be non-ASF, as I don't think there is a widely accepted ASF-IDE
> [well, yes: Eclipse plugins for Tapestry & co. :-); please accept my
> apologies if there is one, my point is not selling Eclipse in particular 
> but
> having an IDE to play with the VM, for instance to test practically its
> debugging interface, and show it to others])
> 
> Just think of it in OS terms as a
> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff
> for decision makers). Bundling with 1 or 2 apps we/the ASF did not write 
> is
> not to be covered by NIH syndrome in my opinion, but rather a way to prove
> it actually works to decision makers. (After all, mono bundles mono with
> monodevelop [or rather monodevelop with mono, I think], and Sun bundles
> Netbeans with J2SE...)
> 
> Just the same as if you develop, say, a 'new simulation algorithm for
> reaction-diffusion discrete systems, which is "discrete, adaptive" '[1]. 
> In
> order to get credit from ordinary people (who might not be familiar with 
> its
> technical beauty, right?), even if the scope of this project is on soft
> architecture and math analysis, you might have to provide scientifically
> uninteresting display that it works... (Spiraling pattern for simplified
> models of myocardium cells electrophysiology: that is, simulation of 
> cardiac
> arrhythmia in dummy demo-only situation, so here the mystery of what it is
> ends here [2])
> That is, with some 'out of scope' effort you get images for the layman to 
> be
> impressed...
> 
> To come back to more soft-only concerns, IMHO providing distributors with
> the minimum tool they need to polish the VM-to-VM discrepancies and 
> external
> developers the minimum tools they need to test their soft on the Harmony 
> VM
> (and get a chance to actually do something - not just: 'it does not work' 
> -
> if it does not work the way they planned it) might be a big ROI,
> comparatively small effort.
> 
> A VM without the bare minimum support tools might appear a bit useless to
> many people (and also impractical to test with an ergonomic, long-lasting
> experience of beautiful-looking piece of software). If you take, say, the
> FreeBSD case, you don't have much choice for instance for the VM you use
> with your favorite IDE, so that ipso facto you stick with the VM you get 
> in
> stock (because the other VMs might be good, but if it's a nightmare to
> reconfigure it all to use your VM of choice with your favorite IDE...), 
> just
> like IE sticks with many win$ users.
> 
> As a use case, if I want to test a piece of software, well I would like it
> to be kind of "download it and play".
> 
> Regards,
> 
> RB
> 
> [1] Sorry I take examples of my own... (Well, the research I once did)
> [2] It was so simplified it was meaningless in my opinion, but I got my
> credits with it...
> 
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Monday, May 23, 2005 8:58 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [arch] VM Candidate : JikesRVM 
> http://jikesrvm.sourceforge.net/
> 
> 
> On May 22, 2005, at 9:27 PM, Renaud BECHADE wrote:
> 
> >
> >
> > ＞ No. Why would we do this?
> > People tend to be lazy. If they have a bundle with one VM, then
> > they will
> > use that VM, for most of them, IMHO. I seriously doubt we can have
> > people
> > trust an alternative VM if it is not a piece of cake (sort of "with
> > a one
> > liner on the console you are started") to develop with it, and as
> > it is
> > unlikely it will support everything perfectly at the beginning (to
> > convince
> > you let us consider running .NET soft on a Linux/Mono machine, or
> > XSP code
> > on a FreeBSD/mono machine - sometimes it crashes badly, or again
> > freeware
> > support of Flash swf, all of which can have slightly strange behaviors
> > sometimes, if compared with commercial equivalents, so that a
> > development
> > that is not started /from the beginning/ with them might get into
> > troubles)
> > there will be some intensive testing to do on real applications,
> > which might
> > involve some patches on "must-have" packages such as Eclipse / J2EE
> > etc.
> > (including strategies as simple as repackaging with a bit less
> > modules to
> > have it actually run because some funny class is not here)
> 
> 
> It would be great if people would bundle Harmony with stuff (and plan
> to do it w/ Geronimo when that time comes), bit it's way out of scope
> for *this* project to get into the business of reditributing software
> from outside of the ASF.
> 
> geir
> 
> >
> > RB
> >
> > -----Original Message-----
> > From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> > Sent: Friday, May 20, 2005 7:38 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [arch] VM Candidate : JikesRVM http://
> > jikesrvm.sourceforge.net/ <http://jikesrvm.sourceforge.net/>
> >
> >
> > On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
> >
> >
> >>
> >>
> >> Another point that is unrelated, but what about the "packaging" of
> >> the VM?
> >> Do we plan to release it with say Eclipse + Server (JSF + IDE +
> >> object DB or
> >> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
> >>
> >
> > No. Why would we do this?
> >
> > We want our JRE or JDK to be an alternative to the existing JREs and
> > JDKs w/o having people worry about all the cruft.
> >
> > If you had an interest in bundling for some reason, you could of
> > course take the thing and do that elsewhere (or start a separate
> > project here if there was enough support and a decent rationale...)
> >
> > geir
> >
> > --
> > Geir Magnusson Jr +1-203-665-6437
> > geirm@apache.org
> >
> >
> >
> 
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
> 
> 
>

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

＞> ＞I don't understand this argument.  If our J2SE implementation is
＞> ＞feature-comparable to the one from Sun, IBM or BEA, why would we
＞> need
＞> ＞to add Eclipse onto it?
＞>
＞> As a demonstrator： "just test it" [TM].

＞Then test it!  We don't have to distribute it too :)

Well, the point is to /convince/ less passionate people. I have seen enough
freeware/opensource sites that shave a zero cost tomorrow, but which soft as
of today is not up to what is said should work (mind you, I am bearded, and
I never shaved in 10 years). Having just one or two bundles to begin to
"just play with it" (with some screenshots) IMHO is really the simplest way
to convince people of practical usability.

-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Tuesday, May 24, 2005 11:33 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/


On May 23, 2005, at 10:09 PM, Renaud BECHADE wrote:

> ＞I don't understand this argument.  If our J2SE implementation is
> ＞feature-comparable to the one from Sun, IBM or BEA, why would we
> need
> ＞to add Eclipse onto it?
>
> As a demonstrator： "just test it" [TM].

Then test it!  We don't have to distribute it too :)

> Also, as I said before, if its entry level for developers is high
> (****
> configuration with Eclipse or some other candidate, the lazy
> effect, you
> see), then we are digging our grave, because the best way to have
> other
> projects bundle with the VM is to help them play with it in the
> first time.
>
> Regards,
>
> RB
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Tuesday, May 24, 2005 10:49 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [arch] VM Candidate : JikesRVM http://
> jikesrvm.sourceforge.net/
>
>
> On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote:
>
>
>>
>>
>> ＞It would be great if people would bundle Harmony with stuff (and
>> plan
>> ＞to do it w/ Geronimo when that time comes), bit it's way out of
>> scope
>> ＞for *this* project to get into the business of reditributing
>> software
>> ＞from outside of the ASF.
>>
>> Hum... I still think there is a minimum distribution effort to be
>> done (call
>> that marketing if you want) to get people to actually test the VM,
>> as in the
>> beginning it might be very, very, very unlikely that absolutely
>> everything
>> runs out of the box as replacement for J2SE 5 or 6... So we will
>> need to
>> help them try it out.
>>
>
> Yes! And this is classic behavior for OSS projects - once you have
> something useful, you go out and proselytize, helping other projects
> see the value, and use it.
>
> So you go out and get Eclipse to bundle with it, you get Geronimo to
> bundle with it, you get JBoss to bundle with it, you get JOnAS to
> bundle with it, you get Tomcat to bundle with it, you get....
>
> And then you learn from their bundling efforts and make the thing
> even easier to use in that way.
>
> But distributing Eclipse or JBoss from here?  No....
>
>
>> Just think of it in OS terms as a
>> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a
>> stuff
>> for decision makers). Bundling with 1 or 2 apps we/the ASF did not
>> write is
>> not to be covered by NIH syndrome in my opinion, but rather a way
>> to prove
>> it actually works to decision makers. (After all, mono bundles mono
>> with
>> monodevelop [or rather monodevelop with mono, I think], and Sun
>> bundles
>> Netbeans with J2SE...)
>>
>
> I'd prefer we don't re-distribute other people's software unless part
> of the distribution for which the Apache project provides top-line
> value.
>
> [SNIP]
>
>
>>
>> To come back to more soft-only concerns, IMHO providing
>> distributors with
>> the minimum tool they need to polish the VM-to-VM discrepancies and
>> external
>> developers the minimum tools they need to test their soft on the
>> Harmony VM
>> (and get a chance to actually do something - not just: 'it does not
>> work' -
>> if it does not work the way they planned it) might be a big ROI,
>> comparatively small effort.
>>
>
> That's an entirely different kettle of fish, and I support that.
>
>
>>
>> A VM without the bare minimum support tools might appear a bit
>> useless to
>> many people (and also impractical to test with an ergonomic, long-
>> lasting
>> experience of beautiful-looking piece of software). If you take,
>> say, the
>> FreeBSD case, you don’t have much choice for instance for the VM
>> you use
>> with your favorite IDE, so that ipso facto you stick with the VM
>> you get in
>> stock (because the other VMs might be good, but if it’s a
>> nightmare to
>> reconfigure it all to use your VM of choice with your favorite
>> IDE...), just
>> like IE sticks with many win$ users.
>>
>
> I don't understand this argument.  If our J2SE implementation is
> feature-comparable to the one from Sun, IBM or BEA, why would we need
> to add Eclipse onto it?
>
>
>>
>> As a use case, if I want to test a piece of software, well I would
>> like it
>> to be kind of "download it and play".
>>
>
> Yes!  So we go out there and get everyone to bundle with our J2SE
> distribution.  We go there, do the work, and help them. :)
>
> geir
>
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 23, 2005, at 10:09 PM, Renaud BECHADE wrote:

> ＞I don't understand this argument.  If our J2SE implementation is
> ＞feature-comparable to the one from Sun, IBM or BEA, why would we  
> need
> ＞to add Eclipse onto it?
>
> As a demonstrator： "just test it" [TM].

Then test it!  We don't have to distribute it too :)

> Also, as I said before, if its entry level for developers is high  
> (****
> configuration with Eclipse or some other candidate, the lazy  
> effect, you
> see), then we are digging our grave, because the best way to have  
> other
> projects bundle with the VM is to help them play with it in the  
> first time.
>
> Regards,
>
> RB
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Tuesday, May 24, 2005 10:49 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [arch] VM Candidate : JikesRVM http:// 
> jikesrvm.sourceforge.net/
>
>
> On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote:
>
>
>>
>>
>> ＞It would be great if people would bundle Harmony with stuff (and
>> plan
>> ＞to do it w/ Geronimo when that time comes), bit it's way out of
>> scope
>> ＞for *this* project to get into the business of reditributing
>> software
>> ＞from outside of the ASF.
>>
>> Hum... I still think there is a minimum distribution effort to be
>> done (call
>> that marketing if you want) to get people to actually test the VM,
>> as in the
>> beginning it might be very, very, very unlikely that absolutely
>> everything
>> runs out of the box as replacement for J2SE 5 or 6... So we will
>> need to
>> help them try it out.
>>
>
> Yes! And this is classic behavior for OSS projects - once you have
> something useful, you go out and proselytize, helping other projects
> see the value, and use it.
>
> So you go out and get Eclipse to bundle with it, you get Geronimo to
> bundle with it, you get JBoss to bundle with it, you get JOnAS to
> bundle with it, you get Tomcat to bundle with it, you get....
>
> And then you learn from their bundling efforts and make the thing
> even easier to use in that way.
>
> But distributing Eclipse or JBoss from here?  No....
>
>
>> Just think of it in OS terms as a
>> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a
>> stuff
>> for decision makers). Bundling with 1 or 2 apps we/the ASF did not
>> write is
>> not to be covered by NIH syndrome in my opinion, but rather a way
>> to prove
>> it actually works to decision makers. (After all, mono bundles mono
>> with
>> monodevelop [or rather monodevelop with mono, I think], and Sun
>> bundles
>> Netbeans with J2SE...)
>>
>
> I'd prefer we don't re-distribute other people's software unless part
> of the distribution for which the Apache project provides top-line
> value.
>
> [SNIP]
>
>
>>
>> To come back to more soft-only concerns, IMHO providing
>> distributors with
>> the minimum tool they need to polish the VM-to-VM discrepancies and
>> external
>> developers the minimum tools they need to test their soft on the
>> Harmony VM
>> (and get a chance to actually do something - not just: 'it does not
>> work' -
>> if it does not work the way they planned it) might be a big ROI,
>> comparatively small effort.
>>
>
> That's an entirely different kettle of fish, and I support that.
>
>
>>
>> A VM without the bare minimum support tools might appear a bit
>> useless to
>> many people (and also impractical to test with an ergonomic, long-
>> lasting
>> experience of beautiful-looking piece of software). If you take,
>> say, the
>> FreeBSD case, you don’t have much choice for instance for the VM
>> you use
>> with your favorite IDE, so that ipso facto you stick with the VM
>> you get in
>> stock (because the other VMs might be good, but if it’s a
>> nightmare to
>> reconfigure it all to use your VM of choice with your favorite
>> IDE...), just
>> like IE sticks with many win$ users.
>>
>
> I don't understand this argument.  If our J2SE implementation is
> feature-comparable to the one from Sun, IBM or BEA, why would we need
> to add Eclipse onto it?
>
>
>>
>> As a use case, if I want to test a piece of software, well I would
>> like it
>> to be kind of "download it and play".
>>
>
> Yes!  So we go out there and get everyone to bundle with our J2SE
> distribution.  We go there, do the work, and help them. :)
>
> geir
>
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

By this I mean sort of "stripped down to its maximum demo Eclipse" (usable
for small projects, but without all those fancy plugins). This is not really
redistributing but rather "pamphleting"...

RB

-----Original Message-----
From: Renaud BECHADE [mailto:renaud.bechade@numerix.com] 
Sent: Tuesday, May 24, 2005 11:10 AM
To: harmony-dev@incubator.apache.org
Subject: RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

＞I don't understand this argument.  If our J2SE implementation is
＞feature-comparable to the one from Sun, IBM or BEA, why would we need
＞to add Eclipse onto it?

As a demonstrator： "just test it" [TM].
Also, as I said before, if its entry level for developers is high (****
configuration with Eclipse or some other candidate, the lazy effect, you
see), then we are digging our grave, because the best way to have other
projects bundle with the VM is to help them play with it in the first time.

Regards,

RB

-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Tuesday, May 24, 2005 10:49 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/


On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote:

>
>
> ＞It would be great if people would bundle Harmony with stuff (and
> plan
> ＞to do it w/ Geronimo when that time comes), bit it's way out of
> scope
> ＞for *this* project to get into the business of reditributing
> software
> ＞from outside of the ASF.
>
> Hum... I still think there is a minimum distribution effort to be
> done (call
> that marketing if you want) to get people to actually test the VM,
> as in the
> beginning it might be very, very, very unlikely that absolutely
> everything
> runs out of the box as replacement for J2SE 5 or 6... So we will
> need to
> help them try it out.

Yes! And this is classic behavior for OSS projects - once you have
something useful, you go out and proselytize, helping other projects
see the value, and use it.

So you go out and get Eclipse to bundle with it, you get Geronimo to
bundle with it, you get JBoss to bundle with it, you get JOnAS to
bundle with it, you get Tomcat to bundle with it, you get....

And then you learn from their bundling efforts and make the thing
even easier to use in that way.

But distributing Eclipse or JBoss from here?  No....

> Just think of it in OS terms as a
> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a
> stuff
> for decision makers). Bundling with 1 or 2 apps we/the ASF did not
> write is
> not to be covered by NIH syndrome in my opinion, but rather a way
> to prove
> it actually works to decision makers. (After all, mono bundles mono
> with
> monodevelop [or rather monodevelop with mono, I think], and Sun
> bundles
> Netbeans with J2SE...)

I'd prefer we don't re-distribute other people's software unless part
of the distribution for which the Apache project provides top-line
value.

[SNIP]

>
> To come back to more soft-only concerns, IMHO providing
> distributors with
> the minimum tool they need to polish the VM-to-VM discrepancies and
> external
> developers the minimum tools they need to test their soft on the
> Harmony VM
> (and get a chance to actually do something - not just: 'it does not
> work' -
> if it does not work the way they planned it) might be a big ROI,
> comparatively small effort.

That's an entirely different kettle of fish, and I support that.

>
> A VM without the bare minimum support tools might appear a bit
> useless to
> many people (and also impractical to test with an ergonomic, long-
> lasting
> experience of beautiful-looking piece of software). If you take,
> say, the
> FreeBSD case, you don’t have much choice for instance for the VM
> you use
> with your favorite IDE, so that ipso facto you stick with the VM
> you get in
> stock (because the other VMs might be good, but if it’s a
> nightmare to
> reconfigure it all to use your VM of choice with your favorite
> IDE...), just
> like IE sticks with many win$ users.

I don't understand this argument.  If our J2SE implementation is
feature-comparable to the one from Sun, IBM or BEA, why would we need
to add Eclipse onto it?

>
> As a use case, if I want to test a piece of software, well I would
> like it
> to be kind of "download it and play".

Yes!  So we go out there and get everyone to bundle with our J2SE
distribution.  We go there, do the work, and help them. :)

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

＞I don't understand this argument.  If our J2SE implementation is
＞feature-comparable to the one from Sun, IBM or BEA, why would we need
＞to add Eclipse onto it?

As a demonstrator： "just test it" [TM].
Also, as I said before, if its entry level for developers is high (****
configuration with Eclipse or some other candidate, the lazy effect, you
see), then we are digging our grave, because the best way to have other
projects bundle with the VM is to help them play with it in the first time.

Regards,

RB

-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Tuesday, May 24, 2005 10:49 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/


On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote:

>
>
> ＞It would be great if people would bundle Harmony with stuff (and
> plan
> ＞to do it w/ Geronimo when that time comes), bit it's way out of
> scope
> ＞for *this* project to get into the business of reditributing
> software
> ＞from outside of the ASF.
>
> Hum... I still think there is a minimum distribution effort to be
> done (call
> that marketing if you want) to get people to actually test the VM,
> as in the
> beginning it might be very, very, very unlikely that absolutely
> everything
> runs out of the box as replacement for J2SE 5 or 6... So we will
> need to
> help them try it out.

Yes! And this is classic behavior for OSS projects - once you have
something useful, you go out and proselytize, helping other projects
see the value, and use it.

So you go out and get Eclipse to bundle with it, you get Geronimo to
bundle with it, you get JBoss to bundle with it, you get JOnAS to
bundle with it, you get Tomcat to bundle with it, you get....

And then you learn from their bundling efforts and make the thing
even easier to use in that way.

But distributing Eclipse or JBoss from here?  No....

> Just think of it in OS terms as a
> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a
> stuff
> for decision makers). Bundling with 1 or 2 apps we/the ASF did not
> write is
> not to be covered by NIH syndrome in my opinion, but rather a way
> to prove
> it actually works to decision makers. (After all, mono bundles mono
> with
> monodevelop [or rather monodevelop with mono, I think], and Sun
> bundles
> Netbeans with J2SE...)

I'd prefer we don't re-distribute other people's software unless part
of the distribution for which the Apache project provides top-line
value.

[SNIP]

>
> To come back to more soft-only concerns, IMHO providing
> distributors with
> the minimum tool they need to polish the VM-to-VM discrepancies and
> external
> developers the minimum tools they need to test their soft on the
> Harmony VM
> (and get a chance to actually do something - not just: 'it does not
> work' -
> if it does not work the way they planned it) might be a big ROI,
> comparatively small effort.

That's an entirely different kettle of fish, and I support that.

>
> A VM without the bare minimum support tools might appear a bit
> useless to
> many people (and also impractical to test with an ergonomic, long-
> lasting
> experience of beautiful-looking piece of software). If you take,
> say, the
> FreeBSD case, you don’t have much choice for instance for the VM
> you use
> with your favorite IDE, so that ipso facto you stick with the VM
> you get in
> stock (because the other VMs might be good, but if it’s a
> nightmare to
> reconfigure it all to use your VM of choice with your favorite
> IDE...), just
> like IE sticks with many win$ users.

I don't understand this argument.  If our J2SE implementation is
feature-comparable to the one from Sun, IBM or BEA, why would we need
to add Eclipse onto it?

>
> As a use case, if I want to test a piece of software, well I would
> like it
> to be kind of "download it and play".

Yes!  So we go out there and get everyone to bundle with our J2SE
distribution.  We go there, do the work, and help them. :)

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 23, 2005, at 9:35 PM, Renaud BECHADE wrote:

>
>
> ＞It would be great if people would bundle Harmony with stuff (and  
> plan
> ＞to do it w/ Geronimo when that time comes), bit it's way out of  
> scope
> ＞for *this* project to get into the business of reditributing  
> software
> ＞from outside of the ASF.
>
> Hum... I still think there is a minimum distribution effort to be  
> done (call
> that marketing if you want) to get people to actually test the VM,  
> as in the
> beginning it might be very, very, very unlikely that absolutely  
> everything
> runs out of the box as replacement for J2SE 5 or 6... So we will  
> need to
> help them try it out.

Yes! And this is classic behavior for OSS projects - once you have  
something useful, you go out and proselytize, helping other projects  
see the value, and use it.

So you go out and get Eclipse to bundle with it, you get Geronimo to  
bundle with it, you get JBoss to bundle with it, you get JOnAS to  
bundle with it, you get Tomcat to bundle with it, you get....

And then you learn from their bundling efforts and make the thing  
even easier to use in that way.

But distributing Eclipse or JBoss from here?  No....

> Just think of it in OS terms as a
> micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a  
> stuff
> for decision makers). Bundling with 1 or 2 apps we/the ASF did not  
> write is
> not to be covered by NIH syndrome in my opinion, but rather a way  
> to prove
> it actually works to decision makers. (After all, mono bundles mono  
> with
> monodevelop [or rather monodevelop with mono, I think], and Sun  
> bundles
> Netbeans with J2SE...)

I'd prefer we don't re-distribute other people's software unless part  
of the distribution for which the Apache project provides top-line  
value.

[SNIP]

>
> To come back to more soft-only concerns, IMHO providing  
> distributors with
> the minimum tool they need to polish the VM-to-VM discrepancies and  
> external
> developers the minimum tools they need to test their soft on the  
> Harmony VM
> (and get a chance to actually do something - not just: 'it does not  
> work' -
> if it does not work the way they planned it) might be a big ROI,
> comparatively small effort.

That's an entirely different kettle of fish, and I support that.

>
> A VM without the bare minimum support tools might appear a bit  
> useless to
> many people (and also impractical to test with an ergonomic, long- 
> lasting
> experience of beautiful-looking piece of software). If you take,  
> say, the
> FreeBSD case, you don’t have much choice for instance for the VM  
> you use
> with your favorite IDE, so that ipso facto you stick with the VM  
> you get in
> stock (because the other VMs might be good, but if it’s a  
> nightmare to
> reconfigure it all to use your VM of choice with your favorite  
> IDE...), just
> like IE sticks with many win$ users.

I don't understand this argument.  If our J2SE implementation is  
feature-comparable to the one from Sun, IBM or BEA, why would we need  
to add Eclipse onto it?

>
> As a use case, if I want to test a piece of software, well I would  
> like it
> to be kind of "download it and play".

Yes!  So we go out there and get everyone to bundle with our J2SE  
distribution.  We go there, do the work, and help them. :)

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

＞It would be great if people would bundle Harmony with stuff (and plan
＞to do it w/ Geronimo when that time comes), bit it's way out of scope
＞for *this* project to get into the business of reditributing software
＞from outside of the ASF.

Hum... I still think there is a minimum distribution effort to be done (call
that marketing if you want) to get people to actually test the VM, as in the
beginning it might be very, very, very unlikely that absolutely everything
runs out of the box as replacement for J2SE 5 or 6... So we will need to
help them try it out.
(Basically, to me some nice IDE + app-server + a few dummy examples, swing &
jsf for instance, is the bare minimum to provide as a
demo-micro-distribution-to-test-it-in-reasonable-situations; the IDE only
might be non-ASF, as I don’t think there is a widely accepted ASF-IDE
[well, yes: Eclipse plugins for Tapestry & co. :-); please accept my
apologies if there is one, my point is not selling Eclipse in particular but
having an IDE to play with the VM, for instance to test practically its
debugging interface, and show it to others])

Just think of it in OS terms as a
micro-bootable-live-CD-to-demo-it-actually-works-on-useful-cases (a stuff
for decision makers). Bundling with 1 or 2 apps we/the ASF did not write is
not to be covered by NIH syndrome in my opinion, but rather a way to prove
it actually works to decision makers. (After all, mono bundles mono with
monodevelop [or rather monodevelop with mono, I think], and Sun bundles
Netbeans with J2SE...)

Just the same as if you develop, say, a 'new simulation algorithm for
reaction-diffusion discrete systems, which is "discrete, adaptive" '[1]. In
order to get credit from ordinary people (who might not be familiar with its
technical beauty, right?), even if the scope of this project is on soft
architecture and math analysis, you might have to provide scientifically
uninteresting display that it works... (Spiraling pattern for simplified
models of myocardium cells electrophysiology: that is, simulation of cardiac
arrhythmia in dummy demo-only situation, so here the mystery of what it is
ends here [2])
That is, with some 'out of scope' effort you get images for the layman to be
impressed...

To come back to more soft-only concerns, IMHO providing distributors with
the minimum tool they need to polish the VM-to-VM discrepancies and external
developers the minimum tools they need to test their soft on the Harmony VM
(and get a chance to actually do something - not just: 'it does not work' -
if it does not work the way they planned it) might be a big ROI,
comparatively small effort.

A VM without the bare minimum support tools might appear a bit useless to
many people (and also impractical to test with an ergonomic, long-lasting
experience of beautiful-looking piece of software). If you take, say, the
FreeBSD case, you don’t have much choice for instance for the VM you use
with your favorite IDE, so that ipso facto you stick with the VM you get in
stock (because the other VMs might be good, but if it’s a nightmare to
reconfigure it all to use your VM of choice with your favorite IDE...), just
like IE sticks with many win$ users.

As a use case, if I want to test a piece of software, well I would like it
to be kind of "download it and play".

Regards,

RB

[1] Sorry I take examples of my own... (Well, the research I once did)
[2] It was so simplified it was meaningless in my opinion, but I got my
credits with it...

-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Monday, May 23, 2005 8:58 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/


On May 22, 2005, at 9:27 PM, Renaud BECHADE wrote:

>
>
> ＞　No.  Why would we do this?
> People tend to be lazy. If they have a bundle with one VM, then
> they will
> use that VM, for most of them, IMHO. I seriously doubt we can have
> people
> trust an alternative VM if it is not a piece of cake (sort of "with
> a one
> liner on the console you are started") to develop with it, and as
> it is
> unlikely it will support everything perfectly at the beginning (to
> convince
> you let us consider running .NET soft on a Linux/Mono machine, or
> XSP code
> on a FreeBSD/mono machine - sometimes it crashes badly, or again
> freeware
> support of Flash swf, all of which can have slightly strange behaviors
> sometimes, if compared with commercial equivalents, so that a
> development
> that is not started /from the beginning/ with them might get into
> troubles)
> there will be some intensive testing to do on real applications,
> which might
> involve some patches on "must-have" packages such as Eclipse / J2EE
> etc.
> (including strategies as simple as repackaging with a bit less
> modules to
> have it actually run because some funny class is not here)


It would be great if people would bundle Harmony with stuff (and plan
to do it w/ Geronimo when that time comes), bit it's way out of scope
for *this* project to get into the business of reditributing software
from outside of the ASF.

geir

>
> RB
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Friday, May 20, 2005 7:38 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [arch] VM Candidate : JikesRVM http://
> jikesrvm.sourceforge.net/
>
>
> On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
>
>
>>
>>
>> Another point that is unrelated, but what about the "packaging" of
>> the VM?
>> Do we plan to release it with say Eclipse + Server (JSF + IDE +
>> object DB or
>> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
>>
>
> No.  Why would we do this?
>
> We want our JRE or JDK to be an alternative to the existing JREs and
> JDKs w/o having people worry about all the cruft.
>
> If you had an interest in bundling for some reason,  you could of
> course take the thing and do that elsewhere (or start a separate
> project here if there was enough support and a decent rationale...)
>
> geir
>
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 22, 2005, at 9:27 PM, Renaud BECHADE wrote:

>
>
> ＞　No.  Why would we do this?
> People tend to be lazy. If they have a bundle with one VM, then  
> they will
> use that VM, for most of them, IMHO. I seriously doubt we can have  
> people
> trust an alternative VM if it is not a piece of cake (sort of "with  
> a one
> liner on the console you are started") to develop with it, and as  
> it is
> unlikely it will support everything perfectly at the beginning (to  
> convince
> you let us consider running .NET soft on a Linux/Mono machine, or  
> XSP code
> on a FreeBSD/mono machine - sometimes it crashes badly, or again  
> freeware
> support of Flash swf, all of which can have slightly strange behaviors
> sometimes, if compared with commercial equivalents, so that a  
> development
> that is not started /from the beginning/ with them might get into  
> troubles)
> there will be some intensive testing to do on real applications,  
> which might
> involve some patches on "must-have" packages such as Eclipse / J2EE  
> etc.
> (including strategies as simple as repackaging with a bit less  
> modules to
> have it actually run because some funny class is not here)


It would be great if people would bundle Harmony with stuff (and plan  
to do it w/ Geronimo when that time comes), bit it's way out of scope  
for *this* project to get into the business of reditributing software  
from outside of the ASF.

geir

>
> RB
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Friday, May 20, 2005 7:38 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [arch] VM Candidate : JikesRVM http:// 
> jikesrvm.sourceforge.net/
>
>
> On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:
>
>
>>
>>
>> Another point that is unrelated, but what about the "packaging" of
>> the VM?
>> Do we plan to release it with say Eclipse + Server (JSF + IDE +
>> object DB or
>> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)
>>
>
> No.  Why would we do this?
>
> We want our JRE or JDK to be an alternative to the existing JREs and
> JDKs w/o having people worry about all the cruft.
>
> If you had an interest in bundling for some reason,  you could of
> course take the thing and do that elsewhere (or start a separate
> project here if there was enough support and a decent rationale...)
>
> geir
>
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

＞　No.  Why would we do this?
People tend to be lazy. If they have a bundle with one VM, then they will
use that VM, for most of them, IMHO. I seriously doubt we can have people
trust an alternative VM if it is not a piece of cake (sort of "with a one
liner on the console you are started") to develop with it, and as it is
unlikely it will support everything perfectly at the beginning (to convince
you let us consider running .NET soft on a Linux/Mono machine, or XSP code
on a FreeBSD/mono machine - sometimes it crashes badly, or again freeware
support of Flash swf, all of which can have slightly strange behaviors
sometimes, if compared with commercial equivalents, so that a development
that is not started /from the beginning/ with them might get into troubles)
there will be some intensive testing to do on real applications, which might
involve some patches on "must-have" packages such as Eclipse / J2EE etc.
(including strategies as simple as repackaging with a bit less modules to
have it actually run because some funny class is not here)

RB

-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org] 
Sent: Friday, May 20, 2005 7:38 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/


On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:

>
>
> Another point that is unrelated, but what about the "packaging" of  
> the VM?
> Do we plan to release it with say Eclipse + Server (JSF + IDE +  
> object DB or
> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)

No.  Why would we do this?

We want our JRE or JDK to be an alternative to the existing JREs and  
JDKs w/o having people worry about all the cruft.

If you had an interest in bundling for some reason,  you could of  
course take the thing and do that elsewhere (or start a separate  
project here if there was enough support and a decent rationale...)

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 19, 2005, at 10:29 PM, Renaud BECHADE wrote:

>
>
> Another point that is unrelated, but what about the "packaging" of  
> the VM?
> Do we plan to release it with say Eclipse + Server (JSF + IDE +  
> object DB or
> O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)

No.  Why would we do this?

We want our JRE or JDK to be an alternative to the existing JREs and  
JDKs w/o having people worry about all the cruft.

If you had an interest in bundling for some reason,  you could of  
course take the thing and do that elsewhere (or start a separate  
project here if there was enough support and a decent rationale...)

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

＞This is why I would like Harmony to have two VMs, one written in java
＞and one written in C-or-friends: this would give us
＞
＞ 1) the goal of making things modular enough to allow to swap things
＞around and allow parallel development
＞
＞ 2) create some internal (and friendly!) competition on speed and
＞compliance :-)
＞
＞ 3) attract two different pools of talents
＞
＞ 4) allow compensation (easier to experiment in java than in C, harder
＞to port java than C)
＞
＞Thoughts?

Having a plugin-based JVM based on a VM that already works (or even /ANY/
JVM if we suppose we do enough bytecode engineering[1] and limit ourselves
to minimum assertions on the runtime - say we only use JNI & Java debugger
interface & reflection to link bytecode with JIT generated code) could do
that, with the added benefit we have a working system NOW (including the
libraries for java 5, that are quite a big bunch of work in themselves, and
the packaging effort). I think this is compatible with the use of an LLVM
based solution too (for instance llvi calls gcj or another VM with the
adequate function pointers so that gcj can in turn call the LLVM-based VM
plugin.

s/gcj/other vm/. My point is that gcj is working everywhere, really, even
obscure chips, and can potentially execute java5 bytecode (with the adequate
java 5 bytecode -> java normal bytecode + additional meta information in
some format if required), NOW.

That makes 2 VMs, one in C/C++ (bootstrap VM, a hacked version of an
existing one) and one in java (the JIT plugin), and also a common runtime to
develop (which in itself is resource-greedy)

Another point that is unrelated, but what about the "packaging" of the VM?
Do we plan to release it with say Eclipse + Server (JSF + IDE + object DB or
O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)

[1] ex: the AOP techniques used in JAC enable transparent distributed
deployment, such as for instance A calls B on machine x but in fact B is
working on machine y (and except from the AOP system, x has a jar of A+B, or
an empty shell of B, where a calls B the "usual way")

[Renaud BECHADE] RB

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Stefano Mazzocchi <st...@apache.org>]

Renaud BECHADE wrote:
>>>That being said...doing so in a portable and platform independent way is 
>>>actually HARDER in Java than in C (and by C I mean 
>>>C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see what 
>>>I mean :-)
> 
> 
> Why should it be so? I guess the platform dependent code emission code is
> err ... not platform independent anyway. Also, if the reference platform is
> for instance LLVM, or some other, off the shelf, low-level intermediate
> representation, then there is no more platform dependence to take care of at
> the JVM level (I suppose)...

Andy is right: "writing in Java" *above* the JVM interface means you are
creating bytecode and all the portability efforts were taken care for
you by the JVM makers. "writing in Java" *below* the JVM interface means
that you have to do, at some point, some native code transformations
yourselfs, for every single different CPU architecture.

Writing a JVM in a compilable higher language means that the compiler
will do all that for you.

So, interestingly enough, writing a JVM in java could allow java
developers to work on it more easily (java programmers tend to be
allergic to C and friends), but would require a lot more work,
portability wise.

It's also true that this kind of portability is perfectly parallelizable
and it's CPU-dependent, not OS-dependent (well, really it's
(CPU,OS)-dependent, but the two are almost orthogonal axis) and there
are not so many CPU architectures remaining out there in the server market.

This might hit us on the mobile/embedded market, though and hit us
pretty hard.

This is why I would like Harmony to have two VMs, one written in java
and one written in C-or-friends: this would give us

 1) the goal of making things modular enough to allow to swap things
around and allow parallel development

 2) create some internal (and friendly!) competition on speed and
compliance :-)

 3) attract two different pools of talents

 4) allow compensation (easier to experiment in java than in C, harder
to port java than C)

Thoughts?

-- 
Stefano.

RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Renaud BECHADE <re...@numerix.com>]

>>That being said...doing so in a portable and platform independent way is 
>>actually HARDER in Java than in C (and by C I mean 
>>C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see what 
>>I mean :-)

Why should it be so? I guess the platform dependent code emission code is
err ... not platform independent anyway. Also, if the reference platform is
for instance LLVM, or some other, off the shelf, low-level intermediate
representation, then there is no more platform dependence to take care of at
the JVM level (I suppose)...

RB

-----Original Message-----
From: acoliver@apache.org [mailto:acoliver@apache.org] 
Sent: Thursday, May 19, 2005 4:49 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

The problem of Java written JVM/JIT isn't one of performance.  You can 
theoretically achieve the same performance (although I'm not 100% 
convinced, I'm partially there) especially if you're willing to "extend" 
Java for the purpose of writing Java.

That being said...doing so in a portable and platform independent way is 
actually HARDER in Java than in C (and by C I mean 
C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see what 
I mean :-)

-Andy

Geir Magnusson Jr. wrote:
> 
> On May 18, 2005, at 2:18 AM, Ozgur Akan wrote:
> 
>> I think everyone shall read this first http:// 
>> jikesrvm.sourceforge.net/info/overview.shtml . If performance will  
>> not be a problem then the product based on Jikes can be an  
>> alternative to Sun`s JVM.
> 
> 
> Can we put the performance question to rest once and for all?
> 
> geir
> 
>>
>> Personally Java is the language I feel myself most confortable and  I 
>> think most of the people here feels the same. This is also an  
>> advantage which will shorten the development time if Java language  is 
>> used.
>>
>> Ozgur Akan
>>
>> Geir Magnusson Jr. wrote:
>>
>>
>>> We've been talking about two threads of discussion, one working  
>>> with  a C/C++ based VM, one w/ Java.
>>>
>>> Here's a Java one for discussion (just want to focus threads...)
>>>
>>> geir
>>>
>>>
>>
>>
> 


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

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[ac...@apache.org]

The problem of Java written JVM/JIT isn't one of performance.  You can 
theoretically achieve the same performance (although I'm not 100% 
convinced, I'm partially there) especially if you're willing to "extend" 
Java for the purpose of writing Java.

That being said...doing so in a portable and platform independent way is 
actually HARDER in Java than in C (and by C I mean 
C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see what 
I mean :-)

-Andy

Geir Magnusson Jr. wrote:
> 
> On May 18, 2005, at 2:18 AM, Ozgur Akan wrote:
> 
>> I think everyone shall read this first http:// 
>> jikesrvm.sourceforge.net/info/overview.shtml . If performance will  
>> not be a problem then the product based on Jikes can be an  
>> alternative to Sun`s JVM.
> 
> 
> Can we put the performance question to rest once and for all?
> 
> geir
> 
>>
>> Personally Java is the language I feel myself most confortable and  I 
>> think most of the people here feels the same. This is also an  
>> advantage which will shorten the development time if Java language  is 
>> used.
>>
>> Ozgur Akan
>>
>> Geir Magnusson Jr. wrote:
>>
>>
>>> We've been talking about two threads of discussion, one working  
>>> with  a C/C++ based VM, one w/ Java.
>>>
>>> Here's a Java one for discussion (just want to focus threads...)
>>>
>>> geir
>>>
>>>
>>
>>
> 


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

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[usman bashir <gr...@gmail.com>]

Yeah! i was thinking over the same lines while reading last night the 
impatients! and what the other communtities is looking towards us, they 
surelly wana see us to get some thing innovative rather then just a wrapper 
over the oldies, ( sorry guys its not just critic plz forgive me if some 
minds) , so i think we should came out some thing that is innovative , we 
dont lack the skills and as the time went on , we will have more active 
participation of the people from the community.
 but there is another prospect as well , while keeping a design and other 
issues aside we can also dig into the holes to get some thing out of it from 
the current availaibities. (as we dont want to loose and discard what the 
people already had done it) so the best possible scenario will be like this
 start now with some thing avialable and put the things in such a way that 
as time went on , we can replace the modules with our own inventions ( ;) ) 
and this modulairty is what i m crying for now, we should not forget this as 
for me i m looking it positively from harmony.
 so what u think going parrallel in both ways could help us , is not ?
 and yeah along wiht it many many ideas are coming and i will raise a point 
as well (we should keep a list of these wishlist together and also allow the 
guys to work over it ) and later on we can add those wishies into our final 
releases.
 so for me i m not looking the first release i m also looking for the future 
releases of harmony

 On 5/18/05, Mladen Turk <mt...@apache.org> wrote: 
> 
> Ozgur Akan wrote:
> 
> > Actually Jikes uses it`s own VM and has a part written in C. This makes
> > things a little bit different.
> >
> 
> Huh, yes. It makes a completely different light on Harmony project.
> Perhaps the Harmony project should start as Jikes based proposal.
> Now that people get enthusiastic about building something new and
> technologically advanced, seems we are going to use the existing
> technology after all with exiting JVM and existing classpath library.
> 
> 
> > If we are talking about the architecture of Jikes, like how it
> > implemented GC etc., then yes it is not time to speak about performance.
> >
> 
> Not sure what Gair had in mind, but that was mine concern about
> premature optimization.
> 
> Regards,
> Mladen.
> 



-- 
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: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Mladen Turk <mt...@apache.org>]

Ozgur Akan wrote:

> Actually Jikes uses it`s own VM and has a part written in C. This makes 
> things a little bit different.
>

Huh, yes. It makes a completely different light on Harmony project.
Perhaps the Harmony project should start as Jikes based proposal.
Now that people get enthusiastic about building something new and
technologically advanced, seems we are going to use the existing
technology after all with exiting JVM and existing classpath library.


> If we are talking about the architecture of Jikes, like how it 
> implemented GC etc., then yes it is not time to speak about performance.
>

Not sure what Gair had in mind, but that was mine concern about
premature optimization.

Regards,
Mladen.

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Ozgur Akan <ak...@aiqa.com>]

I don`t agree you Mladen;

If we are going to extend an existing JVM then we have to use the same 
language with that JVM. When talking about Jikes our only option is to 
use Java and I am not sure a JVM written with Java can be at production 
quality. If Harmony will only be an experiment

Actually Jikes uses it`s own VM and has a part written in C. This makes 
things a little bit different.

If we are talking about the architecture of Jikes, like how it 
implemented GC etc., then yes it is not time to speak about performance.

Maybe I misunderstood Geir`s e-mail.

thanks,
Ozgur Akan


Mladen Turk wrote:

> Geir Magnusson Jr. wrote:
>

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Mladen Turk <mt...@apache.org>]

Geir Magnusson Jr. wrote:
> 
> On May 18, 2005, at 2:18 AM, Ozgur Akan wrote:
> 
>> I think everyone shall read this first http:// 
>> jikesrvm.sourceforge.net/info/overview.shtml . If performance will  
>> not be a problem then the product based on Jikes can be an  
>> alternative to Sun`s JVM.
> 
> 
> Can we put the performance question to rest once and for all?
> 

The rules of programming are transitory; only Tao is eternal.
Therefore you must contemplate Tao before you receive enlightenment.
But how will I know when I have received enlightenment? asked
the novice.
Your program will then run correctly, replied the master.


So I agree wit Geir, for an enlightenment, the first rule is to
run it correctly. Speaking on performance before a single line
of code in not Tao!


Regards,
Mladen.

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

["Geir Magnusson Jr." <ge...@apache.org>]

On May 18, 2005, at 2:18 AM, Ozgur Akan wrote:

> I think everyone shall read this first http:// 
> jikesrvm.sourceforge.net/info/overview.shtml . If performance will  
> not be a problem then the product based on Jikes can be an  
> alternative to Sun`s JVM.

Can we put the performance question to rest once and for all?

geir

>
> Personally Java is the language I feel myself most confortable and  
> I think most of the people here feels the same. This is also an  
> advantage which will shorten the development time if Java language  
> is used.
>
> Ozgur Akan
>
> Geir Magnusson Jr. wrote:
>
>
>> We've been talking about two threads of discussion, one working  
>> with  a C/C++ based VM, one w/ Java.
>>
>> Here's a Java one for discussion (just want to focus threads...)
>>
>> geir
>>
>>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/

[Ozgur Akan <ak...@aiqa.com>]

I think everyone shall read this first 
http://jikesrvm.sourceforge.net/info/overview.shtml . If performance 
will not be a problem then the product based on Jikes can be an 
alternative to Sun`s JVM.

Personally Java is the language I feel myself most confortable and I 
think most of the people here feels the same. This is also an advantage 
which will shorten the development time if Java language is used.

Ozgur Akan

Geir Magnusson Jr. wrote:

> We've been talking about two threads of discussion, one working with  
> a C/C++ based VM, one w/ Java.
>
> Here's a Java one for discussion (just want to focus threads...)
>
> geir
>