date:20050517

On May 13, 2005, at 6:27 AM, Steven Martin wrote:
No obviously have stacktrace.  Sun's implementation uses native calls
instead of 100% Java.
I think we're going to be making native calls at some point.  How  
else do you get to resources from the OS?

geir

On 5/12/05, Gerry Steele [EMAIL PROTECTED] wrote:
I don't see how you see thar steve. WE guys want to pass the JCK/ 
TCK. They
can't without JNI or getStackTrace(). The project would fail JCK  
otherwise.

 Gerry

On 5/12/05, Steven Martin [EMAIL PROTECTED] wrote:
From what I've read on the announcements it looks like native calls
will not be necessary.  Is that true?  I highly support that as it's
disappointing to see calls like stackTrace require a native call.
Steven


--
Gerry Steele
x74521/+353-1-8199 521
http://blogs.sun.com/roller/page/gerrys
[ [EMAIL PROTECTED] OR [EMAIL PROTECTED]

--
Steven A. Martin

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Wishlist

On May 12, 2005, at 7:26 PM, Nick Lothian wrote:
 In the only-partially-dreaming wishlist category:
It would be really nice if (and make sense for) Sun open sourced  
Swing.

That would:
a) Help classpath along a lot
b) Be a competitive move on Sun's part against IBM's SWT.
This was one of my first suggestions to Sun when I introduced the  
project to them.  I'm keeping my hopes up, but what to do is theirs  
to choose.

geir


-Original Message-
From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
Sent: Friday, 13 May 2005 2:53 AM
To: harmony-dev@incubator.apache.org
Subject: Wishlist
In a lighter vein...
- Wish we could resolve the licensing discussions and move on.
- Wish one or more of the existing VM's consider donating to Apache.
- Wish some of the BigCo's help with code and worker bees.
- Wish we get to our first Hello World! soon.
- Wish we end hunger/poverty/war all over the world (*)
thanks,
dims
(*) Hey this is a wishlist.
--
Davanum Srinivas - http://webservices.apache.org/~dims/


IMPORTANT: This e-mail, including any attachments, may contain  
private or confidential information. If you think you may not be  
the intended recipient, or if you have received this e-mail in  
error, please contact the sender immediately and delete all copies  
of this e-mail. If you are not the intended recipient, you must not  
reproduce any part of this e-mail or disclose its contents to any  
other party.
This email represents the views of the individual sender, which do  
not necessarily reflect those of education.au limited except where  
the sender expressly states otherwise.
It is your responsibility to scan this email and any files  
transmitted with it for viruses or any other defects.
education.au limited will not be liable for any loss, damage or  
consequence caused directly or indirectly by this email.


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Proposal: A VM launcher

Any other comments?
Care to get started, Nick?  As Jon used to say Thanks for volunteering
One of the things we have to still discuss (and I'll be posting in a  
sec) is some enhancement to our regular IP processes, as we want to  
be *very* sure that we maintain the highest level possible of IP  
provenance for the project...

geir
On May 13, 2005, at 1:01 AM, Nick Lothian wrote:
It seems people want something specific to work on. Here's an idea I
had:
Apache Harmony should develop a JVM launcher (java/java.exe) that
uses a standard API (based on JNI_CreateJavaVM()) that will allow  
any VM
to be used. Note that this is different to the alternatives  
command in
Linux which makes it easy to switch between different launchers.

This would be an important step forward because it would make it  
easier
for developers to test on multiple VMs. It also has the benefit  
that of
being a fairly (very!) small, self contained piece of work that isn't
covered by any other cross platform project (AFAIK) but could be  
useful
to all of them.

The algorithm for VM selection could be as simple as user flags or it
could use heuristics to analyze the machine it is running on and  
select
an appropriate VM.

The Sun VM currently has a similar mechanism that allows (for  
instance)
the JRockit VM to be used from a Sun JRE installation by editing one
config file and passing a command line argument:
http://www.neward.net/ted/weblog/index.jsp?date=20030307

Some useful documentation links:
Java JNI: http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/ 
jniTOC.html
Creating a VM using JNI:
http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/ 
invocation.html#wp159
56
Kaffe's launcher:
http://www.kaffe.org/cgi-bin/viewcvs.cgi/kaffe/kaffe/kaffe/main.c? 
rev=HE
ADcontent-type=text/vnd.viewcvs-markup
Jsmooth: http://jsmooth.sourceforge.net/
Launch4J: http://launch4j.sourceforge.net/
Roll you own Java laucher:
http://www.neward.net/ted/Papers/RollYourOwnJava/index.html (beware  
that
this paper contains code from Sun's launcher - make sure you don't  
copy
that)

Nick
IMPORTANT: This e-mail, including any attachments, may contain  
private or confidential information. If you think you may not be  
the intended recipient, or if you have received this e-mail in  
error, please contact the sender immediately and delete all copies  
of this e-mail. If you are not the intended recipient, you must not  
reproduce any part of this e-mail or disclose its contents to any  
other party.
This email represents the views of the individual sender, which do  
not necessarily reflect those of education.au limited except where  
the sender expressly states otherwise.
It is your responsibility to scan this email and any files  
transmitted with it for viruses or any other defects.
education.au limited will not be liable for any loss, damage or  
consequence caused directly or indirectly by this email.


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: JIT vs. WAT

CPL-ed code is fine for us to include and distribute (not host)
geir
On May 13, 2005, at 1:45 PM, Patrice Le Vexier wrote:
hi everybody,
the same for kaffe, no ?
And what about the CPL license of jykesRVM ?
patrice

-Message d'origine-
De : Davanum Srinivas [mailto:[EMAIL PROTECTED]
Envoyé : Friday, May 13, 2005 1:37 PM
À : harmony-dev@incubator.apache.org; Rodrigo Kumpera
Objet : Re: JIT vs. WAT
Great Question. adding it to my legal list :)
On 5/13/05, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
It would be great to be GCJ compatible. Leveraging they effort with
the binary ABI is a smart move and will promote more harmony instead
of fragmentation between the java ahead-of-time systems.
But this raises a question, can Harmony use GCJ's binary ABI
without been GPL?
Rodrigo
On 5/13/05, Panagiotis Astithas [EMAIL PROTECTED] wrote:
Bob wrote:

IMHO both JITs and pre-compiling have their place.. it
depends on the application whether one is definitely better
than the other.
Ideally, the design of harmony would allow for people to
pursue both approaches and the two could coexist peacefully.

This is a recipe for a bloated system that never works.
Also, most app
programmers don't want to worry about the details of how
their program
is compiled.
-- Bob
And how would a componentized system with multiple
configuration choices
force them to? The Sun JVM has many GC algorithms to choose  
from, yet
many people are unaware of it and use happily the default.

Cheers,
Panagiotis
--
Panagiotis Astithas
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601
http://www.ebs.gr



--
Davanum Srinivas - http://webservices.apache.org/~dims/

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Java Application Native Wrapper

On May 13, 2005, at 8:11 AM, Bob wrote:
This project should provide a tool that generates a native  
executable
program that just starts a new VM and provides all arguments and

classespath
etc... without suffering with batch and shell files. That's  
similar to a
feature in Borland's JBuilder.

Presumeably, the JVM will be stored in a .so/.dll file, and will be  
made available to other applications via the standard shared  
library interfaces.  In that case, this program would be no  
problem.  It would also be possible for non-Java apps to embed and  
integrate a JVM right into their own system, they wouldn't always  
have to be calling an external JVM.

Could someone capture this in the wiki?  I'm on a plane...
geir
-- Bob

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Developing Harmony

On May 13, 2005, at 1:23 AM, Steve Blackburn wrote:
I am going to stick my neck out and make a few concrete suggestions
for how the Harmony VM might be developed.
A few motivating goals:
 o Focus on modular, interchangeable components
   - exploit existing compilers, memory managers etc
   - promote configurability (different components for different  
contexts)
   - allow diversity in development approaches
   - encourage large-scale contributions (here's a compiler)
Yes - that was the goal :)
 o Bootstrap the project rapidly
   - capture momentum
   - seed the project with an existing VM-core (or cores)
That too :)
 o Design a clean core (or cores) from scratch
   - do this concurrently with work on components in existing core/s
   - the core should be lightweight
   - multiple cores may make sense
 - the needs of different contexts may require this
 - competing approaches may be healthy
Agreed.  I'd like to see us start with *one* donation from someone  
that won't mind us kicking it around and deciding what's wrong :) and  
examining all the other VMs that we can.  THen we either fix (because  
I'm really lazy), or start again based on what we've learned from all  
the others..

A concrete option:
1. Use two VMs as seeds
   a) Jikes RVM is a possible candidate
  . Focus energy on cleaning it up and modularizing it. This is
something we've already begun (see earlier post), but will
take a lot of work.
+ Get a very good optimizing compiler
+ Get an efficient and modular memory management toolkit
  (MMTk)
- Need to deal with licensing issues and gain the consent of
  the community (not insurmountable)
- Need hard work to achieve modularity goal for whole VM
   b) Another very different VM (kaffe?)
 . amenable to modularization
 . amenable to other components (drop in MMTk?)
Well, Kaffe is certainly something we want to study and learn from,  
but I'm not sure we can start with it - it's already a separate,  
healthy project elsewhere!

2. Leverage extensive experience to build new core/s
   . Start with a clean slate
   . Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,  
jnode,...)
   . Work concurrently with above work on components in old core/s,
 miminize loss of momentum, try to really think it through
 carefully.
   . May be sensible to develop more than one core

3. Develop new components
   . Extract components from existing work, apply to new VM/s
   . Develop new components from scratch
   . Encourage porting of existing compilers etc into this framework
Alternative options:
 o Start with just one seed
 o There are many different ways... the above is indicative, not  
exclusive

OK.  So I've stuck my neck out.  The above is vague and very
ambitious, but those rough thoughts come out of a lot of experience
with VM design---not just mine but the experience of those who I've
been discussing this with and working with.  A component based VM is
not trivial at all.  I've not mentioned any of the vast complexity
that lies within a real VM.  However, my experience with porting MMTk
across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
working on porting to jnode--Java) gives me hope!
Cheers,
--Steve

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Questions about the Classpath license exception

On May 14, 2005, at 9:35 PM, Sven de Marothy wrote:
- Harmonization of developer-demands. Classpath requires clean-room  
status
(i.e. hasn't seen Sun's code) and FSF assignment (with rights  
granted back).
Harmony will require some form of clean-roomness and an Apache  
licensing agreement.
Seems to me we could benefit from having some cooperation here so a  
developer could 'clear'
himself for both projects at the same time.
Yes - we must be clean-room.  More on another thread.
geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Questions about the Classpath license exception

On May 14, 2005, at 7:39 PM, Davanum Srinivas wrote:
Leo
We can use the con call next week as the forum.
Yes please - we have an ongoing conversation with the FSF on  
licensing issues, and we can just add this to the list.

Folks,
Just to summarize *Ideally* what we would like, here's a list:
- We don't want to modify any classpath code. If we need changes, we
can work with classpath folks.
Yes.  Or We will not modify classpath code here...
(And I'll add that any donation I solicit will be of the sort that  
GNU Classpath could use it if they so chose.)


- We don't want to add classpath sources to our tree. this will avoid
local changes.
We will not add classpath code...  :)
- We want to add classpath jar snapshots to our CVS/SVN (preferable).
I don't.  I'd rather stay away from that and just use maven snapshots  
for now.  Keeps us away from more license issues, and gets rid of the  
a) maintenance overhead and b) size of update when going over slow  
pipes.

- We want to add classpath jar to our installer to distribute a
working JVM/JRE in a single download.
We will certainly need to add the class library jar, and I'm not  
trying to make anyone angry here, but it's *way* too early to know  
what that will be.

- We want to enable a commercial product to be able to sublicense the
complete JVM/JRE.
Yes
geir
Thanks,
dims
On 5/14/05, Leo Simons [EMAIL PROTECTED] wrote:
Hi classpath developers!
(Harmony people: replies only on the classpath mailing list  
please, this has
in reality only little to do with harmony.)

Oh no, not all that licensing crap again!
As part of the ongoing investigation whether the new Apache  
Harmony project
can legally use GNU Classpath and what the licensing implications  
of that
should be, one of Apache's resident license experts inlined some  
comments
into the classpath exception wording:

   Linking this library (scope?) statically or dynamically with
   other modules (define?) is making a combined work based on this
   library. Thus, the terms and conditions of the GNU General
   Public License cover the whole combination. (I.e., this work
   and anything you combine with it cannot be copied, redistributed,
   or made into derivative works except under the terms of the GPL).
   As a special exception (on what?), the copyright holders (who?)
   of this library (encompassing what?) give you permission to
   link (how?) this (what?) library with independent modules (defined
   later) to produce an executable (what's that?), regardless of
   the license terms of these independent modules (license as
   received or license for redistribution?), and to copy and
   distribute (a small fraction of the rights under copyright law,
   not to mention patents) the resulting executable (but what about
   the source libraries?) under terms of your choice, provided that
   you also meet, for each linked independent module, the terms and
   conditions of the license of that module. An independent module
   is a module which is not derived from or based on (define?) this
   library. If you modify this library, you may extend this exception
   to your version of the library, but you are not obligated to do  
so.
   If you do not wish to do so, delete this exception statement from
   your version (which is the same as dual-licensing with GPL).

That's a lot of comments and question marks! The gist of this is  
that the
combination of GPL + this exception has many legal holes at a  
glance. From
what I understand (not a lot, IANAL), that is because various  
things in the
statement are not fully defined.

The first thing we would like to do is get rid of all those  
question marks.
It's probably not productive to go through all of them. One  
suggestion I'd
like to pass on is that you guys write up a list of the goals to  
be achieved
with the GPL+exception construct (ideally in the form of a web  
page, since
links are easy to pass around :-)) and some of the ASF people take  
a look at
that and take a stab at a proposal for a different kind of wording  
which
would be deemed to be compatible with those goals, Apache's goals  
with
Harmony, and the Apache License, if that's possible. We can then  
make the
three texts (the classpath exception, the goals to be achieved  
with the
exception, an alternative proposal) subject of a discussion,  
perhaps via
concall.

Sound like a plan? Mark, I think you've got my cell if you want a
high-bandwidth chat :-)
Cheers,
Leo



--
Davanum Srinivas - http://webservices.apache.org/~dims/

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: class file reader

On May 13, 2005, at 11:54 PM, Rob Gonzalez wrote:
The bytecode verifier is not a particularly difficult thing to
implement, just an important one to get correct ;)
Regarding BCEL's bytecode verifier implementation: it is not 100%
compatible with Sun's as it is more strict, but the code is nice and
definitely worth using for any Java-based verifier implementation.
In any event, I don't think the verifier--which basically performs
static type checking to save some run-time cost--will affect the
architecture of the VM, which should be the main focus of the
discussion for now.
Right - and we want to make this...
... wait for it 
 pluggable!
Is anyone familiar enough to suggest the interfaces for such a  
module? :)

geir
-Rob
On 5/13/05, Stephan Michels [EMAIL PROTECTED] wrote:
On 5/13/05, Davanum Srinivas [EMAIL PROTECTED] wrote:
http://jakarta.apache.org/bcel/
http://cglib.sourceforge.net/
http://forge.objectweb.org/projects/asm
http://serp.sourceforge.net/
I don't know  the others, but BCEL also include a bytecode verifier,
which is not an easy task.
Stephan.


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Apache Harmony / GNU Classpath

2005-05-17 Thread Luis Sanabria

You can get an idea of the status of the project by checking the
Classpath::Status section in the home page
(http://www.gnu.org/software/classpath/).

Regarding the work for Java 5.0, you can check the following page:
(http://developer.classpath.org/mediation/ClasspathDecisionsPage#head-56ff13c4b7f52b8583537864d6829087cf152c7f)

Hope this helps!

On 5/16/05, Stu Statman [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:

On May 16, 2005, at 2:38 AM, Stu Statman wrote:

Geir Magnusson Jr. wrote:

the classlibrary is. GNU Classpath is something we are going to work
with now, and sort out the license issues in parallel.

Does this mean that the core classes development work will happen
within and as part of the GNU Classpath project? Or is there an
intent to fork?

Right now, I see nothing else out there, so yah, we can use GNU
Classpath :)

Would it be possible for someone from the GNU Classpath community ... if
any are on this list ... to give an overview of the status of GNU
Classpath? How complete is it now? How much work do they anticipate it
being to get to 1.5?

I did a quick (a *very* quick) spin around the GNU Classpath site, and
I'm a bit confused by some of the task lists. According to one URL
(http://www.gnu.org/software/classpath/tasks.html), they're a few weeks
away from being done; according to another
(http://savannah.gnu.org/task/?group=classpath), there are open tasks
going back years.

It would be nice to get the nickel tour, giving the lay of the land, an
explanation of who the players are, of where volunteers are most needed,
of how 1.5 code gets submitted. I don't think it's in anybody's
interests for a bunch of new devs who don't know the internal culture of
GNU Classpath to storm in and start tromping around.

I have no intention of forking GNU Classpath. Even if we wanted to, we
couldn't because of the license.

What is the licensing goal, by the way? Dual licensing under
GPL+Exception and Apache? Or is GPL+Exception good enough?

Stu Statman

Re: Developing Harmony

2005-05-17 Thread Brett Porter



 LLVM looks cool, but comes with a wholebunchastuff under different
 licenses embedded in it. A casual inspection suggests we can probably
 work around them, but a closer inspection would be required.

They all looked to be the same with additional copyrights, ie BSD-ish,
with the exception of a stripped down libc which is LGPL. But I'll
respect Leo's rights to not discuss licensing issues :) This means it
should probably be evaluated on its merits.


 I don't really buy this is a drawback, since whatever you choose,
 everybody'll have to learn it.

 It would be wrong to assume that everyone involved in this project is
 totally in love with Java :-)

I'd have thought everyone knew it though, or at least wanted to learn
it, given they are implementing, well, Java :)


 I'm pretty sure we want a framework in C/C++, whatever components are
 developed in.

 Question to the floor: if it had to be one of C and C++, which would
 you prefer?

If it came down to that, I think C++ for 3 reasons:
- the concepts are a lot closer to Java, which should make most people
feel more comfortable, and should there be any wanting to later write a
component in Java instead or vice-versa, the design structure is less
likely to change
- it would give an opportunity to work with a new incubator project
(should it be accepted)
- you can still use any C APIs in C++, but the reverse is not true (or
at least, not easy).

Cheers,
Brett

Re: Apache Harmony / GNU Classpath

2005-05-17 Thread Tom Tromey

 Stu == Stu Statman [EMAIL PROTECTED] writes:

Stu Would it be possible for someone from the GNU Classpath community ...
Stu if any are on this list ... to give an overview of the status of GNU
Stu Classpath? How complete is it now? How much work do they anticipate it
Stu being to get to 1.5?

You can see nightly reports here:

http://www.kaffe.org/~stuart/japi/

This doesn't show everything -- japi hasn't been updated for the 1.5
features, so it won't say whether a class needs to be genericized.
Still, a lot of this has been done, in particular java.util.

Stu It would be nice to get the nickel tour, giving the lay of the land,
Stu an explanation of who the players are, of where volunteers are most
Stu needed, of how 1.5 code gets submitted. I don't think it's in
Stu anybody's interests for a bunch of new devs who don't know the
Stu internal culture of GNU Classpath to storm in and start tromping
Stu around.

There should be a fair amount of info about the development processes
on the Classpath web site.

The usual process is: write a patch, including a ChangeLog entry, then
send it all to the classpath-patches list.  For best results, also
write a test for inclusion in Mauve.  You'll need to go through the
FSF paperwork process for anything that isn't completely trivial (this
is easy).

Someone will check your patch in, or discuss it with you.  Do this for
a while and you're likely to get cvs commit access.  In general, bug
fixes and new classes/packages/etc can just go in without discussion;
for more controversial stuff it is better to discuss first.

1.5 changes go on the 'generics branch', just put '[generics]' in the
Subject.

Development proceeds (as with Apache I suppose) according to each
developer's interest.  Lately those of us at Red Hat have mostly been
working to get some specific big java applications working: eclipse,
tomcat, ant, their many dependencies, jonas, and OO.o.  This mostly
seems to mean bug fixing and minor additions here and there.

Tom

Re: Apache Harmony / GNU Classpath

On May 16, 2005, at 8:50 AM, S. Meslin-Weber wrote:
Hi Geir,
On Mon, May 16, 2005 at 06:47:40AM -0400, Geir Magnusson Jr. wrote:
I have no intention of forking GNU Classpath.  Even if we wanted to,
we couldn't because of the license.

Just to be clear on this point, the license for GNU Classpath is
GPL+Exception and does not prohibit forking.
Of course, but
a) we don't want to fork
b) if we did, we couldn't put software under that license in the  
Apache repository

I believe you are saying that forking and relicensing under an Apache
license isn't currently feasible. The forking block is merely a  
license
incompatibility in this context (and has a separate discussion).
Yes :)
I think that when referring to the license or the licenses we  
should
be more clear as to which licenses we mean otherwise we run the  
risk of
confusing those unfamiliar with current context.

Best Regards,
Steph
--

Stephane Meslin-Weber Email: [EMAIL PROTECTED]
Software Engineer Web: http://odonata.tangency.co.uk

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Java

On May 16, 2005, at 12:42 PM, Mark Brooks wrote:
Why?
Because knowing what tools we are going to use is the logical first  
step.
Heh!  Next time, please give a bit more context on what the Why is  
about :)

I was responding to :
I lack the requisite experience to take the lead on this.  However,  
I think we couldn't really make that determination until someone has  
done some high-level specifications and determined what exactly needs  
to be done.  That requires us to identify preliminary issues  
regarding the build environment.

And I'm not so sure we need to be there yet.
I'd like to start by working on two tracks :
1) Process stuff (in another thread coming soon to a mail list near you)
2) VM-Classlibrary Interface (in another thread...)
Since we have nothing to build, the tools don't quite matter yet..   
We can't even figure out what language we are going to work in.

geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Apache Harmony / GNU Classpath

On May 16, 2005, at 12:18 PM, Stu Statman wrote:
What is the licensing goal, by the way? Dual licensing under GPL 
+Exception and Apache? Or is GPL+Exception good enough?
We are looking at what the GPL+Exception actually means in another  
effort that we have going on between the FSF and the ASF regarding  
licensing matters in general.

We'll report back as things develop, but for now
geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Developing Harmony

On May 16, 2005, at 11:51 AM, Ben Laurie wrote:
I'm pretty sure we want a framework in C/C++, whatever components  
are developed in.
+1
Question to the floor: if it had to be one of C and C++, which  
would you prefer?
C++
Oog. grunt Thog like to bang rocks, but Thog also like inheritance,  
ABCs and generics.

geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Java

welcome :)
On May 16, 2005, at 11:53 AM, Ahmed Saad wrote:
hi all... i'm a computer science student located in cairo, egypt  
with a
modest experience in c/c++ (wrote some bsd-style sockets and posix  
stuff)
and designing web applications with java/php i've just read about
harmony yesterday on slashdot and i'm just itching to be  
invloved... and i
totally agree that there must be an effort to put newbies, like me,  
on the
track.. i'll be more backgrouding, doin' research and pushing foreward
material as much as i can, and i hope i can catch up quickly with  
gurus down
here to code more and more
 regards,
ahmed

 On 5/16/05, Patrice Le Vexier [EMAIL PROTECTED] wrote:
It would be sad if the list really exponentially divide. I thing  
such a
big
project need a lot of people, and not only VM or compiler gurus. I  
think
one
of the big interest of this project is it can elevate the java  
knowledge
of
the community. But for that, an effort must be made to integrate new
comers
(I definitely am), by providing a good set of documentation and
references,
and may be, when it is possible, eating our own food, to avoid to  
create a
gap between peoples who already worked with technologies where are  
going
to
used, and others who not.

Some ideas to try to achieve that:
-providing clear documentations on all aspects we are going to  
work on,
-using a set of tool available on all main platforms (don't exclude
windows
people, it a J2SE, not just a server system)
-try to make it simple, even if the subject is very complicated,

If I think meritocracy is the best thing to make good piece of  
software,
some effort must be made to try to integrate more possible motivated
peoples. I definitely am too ;)

patrice

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : Monday, May 16, 2005 4:40 AM
À : harmony-dev@incubator.apache.org
Objet : Re: Java
Mark Brooks wrote:
Hey, this is an Apache project. There is no lead - we're all  
peers.


Then we are doomed. :)

That's absurd.

But if you are looking for something to do  how can we figure
out the viability of this approach, and either park the idea as an
interesting one but not appropriate for the project, or a good one
that we'll keep going forward with?

I lack the requisite experience to take the lead on this.  
However, I
think we couldn't really make that determination until someone has

done
some high-level specifications and determined what exactly needs  
to be
done. That requires us to identify preliminary issues regarding the
build environment. Realistically, what is our timeframe here? If we
have 36 months, we might be able to achieve a lot. If somebody is
looking for something in the next 12 months, the project might  
have to
be scaled back.


Wow... So I'm guessing you've never worked on an open source  
project.
Welcome. Take a look around, you'll find many projects are governed
this way and accomplish great things without traditional project
management per se.


Exactly what IS Harmony? If the goal is an Apache-licensed J2SE 5.0
implementation, then we have two parts (1) the VM and (2) the class
library. Our requirements tool is the TCK -- but somebody still  
needs
to reduce that to a series of requirements and specifications so we

can
target what needs to be done and estimate how long it will take  
to do.


So stop complaining and start doing it. There are no appointed  
leaders,
that is not to say there are no leaders. Good leaders take  
action, set
an example and then others choose to follow. The TCK is not our
requirements tool per se. Open specifications are our first and
foremost tools. There is a reason for this, the TCK is governed my
nondisclosure agreements that will only make it open to key  
contributors
most likely Apache members. However, plenty of information is out  
there
that will allow everyone qualified to contribute. how will we filter
the qualfied? Frankly the population of this list will exponentially
divide once real coding starts :-)

-Andy

_
Is your PC infected? Get a FREE online computer virus scan from
McAfee?
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp? 
cid=3963



--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Organizing the Mailing List

2005-05-17 Thread Bryce Leo

As harmony is just getting started, there is a great deal of good
suggestions, questions and offers for help. Ever since the Slashdot
announcement I personally think that the number of people whom have
joined and offered their services has clearly gone up and to promote
organization I'm proposing a naming scheme for subject of emails. The
Bulletin board style tags are just to promote reading ease.


First lets look at what seem to be the larger topics of discussion.

[BigCategories]
JVM: The Java Virtual Machine, where to start, different available
codebases and strategies.

Compiler: Creating a javac like tool.

Documentation: It's always easier to document as you go along and well
documented code can save tons of time in tracking down bugs.

Libraries: Which ones to choose or develop individually

Tools: The associated java tools, applet viewer, jar, etc.

Introduction: This would be used for if your'e introducing yourself,
listing prior experience, etc.

DevPriority: The overall discussion of which parts of harmony should
be developed first.

Target OS: Seems small but it doesn't belong as a part of any other so
it gets its own.

Licensing: Should really be a minor concern for now, once we pick up
steam this issue will be logically sorted out. It's and
inter-dependancy (i apologize if i used the word wrong), choosing a
licence effects our code base choices and visa-versa

Organization: How things should be organized.
[/BigCategories]

Below these would be sub-categories that would provide more insight
into the larger topic.

[SmallCategories]
Suggestion: General suggestion(s) for a particular topic.

Questions: Questions about a particular topic.

DevPriority: Probably shouldn't be used yet, would be used for
sub-development. i.e. What order things should be developed for the
compiler.

Organization: How things should be organized.
[/SmallCategories]


So say for example you wanted to send a brand new suggestion for the
JVM the topic of the post would be JVM--Suggestion and if you wanted
to ask a questions about a compiler it would be Compiler--question
and so on like that.

This should be friendly for both threaded and un-threaded mail
clients. And under this system this mail would be
Organization--Organization but for now that's irrelevant.


I think this system would really help focus the group and allow people
to easily tune in to what interests them and keep a tab on the general
flow of the project, while right now things seem a bit willy-nilly.

What do you think?
-- 
~Bryce Leo


--Veritas Vos Liberabis--

Intro to Classpath

2005-05-17 Thread Sven de Marothy

On Mon, 2005-05-16 at 09:18 -0700, Stu Statman wrote:
 Would it be possible for someone from the GNU Classpath community ... if 
 any are on this list ... to give an overview of the status of GNU 
 Classpath? How complete is it now? How much work do they anticipate it 
 being to get to 1.5?

Sure. The quickest way to get a general picture is the API comparison:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
Showing how much of the API is implemented (In general, methods stubs
are not allowed in Classpath, so this is a fairly accurate view)
(Sorry, no comparison against 1.5 is available yet)

The parts which immediately stand out are CORBA (although work on this
has finally gotten started recently) and javax.sound (which is available
from the Tritonus project, which we're working on trying to integrate
with Classpath).

Apart from that AWT and Swing are the most important missing parts,
which need a lot more love :) We do have a generics-branch of our tree
working on 1.5-related stuff, too. (E.g. most of the work moving
container classes to generics has been done) New methods and such for
1.5 that don't break binary compatibility are allowed into the main tree
though.

Personally I'd say 1.5 may be realistic in maybe 1.5-2 years at our
current pace. But that pace is also quickening, and with Harmony's help,
who knows?

 I did a quick (a *very* quick) spin around the GNU Classpath site, 

Yeah, it sucks, doesn't it? :) We're too busy hacking I guess.

 and I'm a bit confused by some of the task lists. According to one URL 
 (http://www.gnu.org/software/classpath/tasks.html), they're a few weeks 
 away from being done; 

Right, well that task list is pretty much outdated and disued now.
Although it isn't a 'schedule' of when things will be done, just
suggestions of things which need doing. 

 according to another 
 (http://savannah.gnu.org/task/?group=classpath), there are open tasks 
 going back years.

Yeah.. that one hasn't worked out well either. Only the latest tasks
there (mostly CORBA-related) are really relevant. The rest should really
be deleted, IMHO. People haven't been following-up on them.

 It would be nice to get the nickel tour, giving the lay of the land, an 
 explanation of who the players are, of where volunteers are most needed, 
 of how 1.5 code gets submitted. 

Ok, well first off everyone should read the Hacker's guide:
http://www.gnu.org/software/classpath/docs/hacking.html
And probably the 'Classpath First Steps' wiki:
http://developer.classpath.org/mediation/ClasspathFirstSteps
I put a real quick-and-dirty guide on how to get started here:
http://lists.gnu.org/archive/html/classpath/2005-05/msg00040.html

It does take a while before you learn your way around the code, but the
easiest way to get started is to work on something which is pure Java
and not worry about the native bits and bobs.

In the classpath source directory you've got the java/ and javax/
directories with the sources for the public class libraries in them. If
they need supporting classes and such, those go in gnu/, e.g. the
private implementation classes for package java.foo.bar are in
gnu/foo/bar. Adding a java class is as simple as that; no changes to the
build scripts required. Adding native bits does though.

Ok, so key players? We don't really have any designated roles, but Mark
Wielaard and Tom Tromey are the head honchos. Thomas Fitzsimmons is the
main guy for AWT/Swing issues. Chris Burdess, XML. Casey Marshall,
crypto. Audrius Mekauskas, CORBA. Roman Kennke, Swing.

Note that I'm intentionally leaving out a big bunch of major
contributors here, (so no offense, folks!). These are just the ones
who's 'area of responsibility' is easily characterizable to me.

Best thing to do is to refer to the mailing list or drop in on
#classpath on IRC (freenode.net) and simply ask if someone's hacking on
something. IRC is also a good way to get to know the folks involved.

There is certainly lots to do.. Lemme throw out some varied suggestions,
here:
* Composite contexts for Java2D (from the Tasks list above) is still not
implemented. (we have compositing in our AWT implementation, but a
pure-java implementation is really needed too). This is relatively easy.

* More character sets for java NIO. 
A list of the supporter character sets in the JDK is here:
http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html
We've got a big number, but still need more. (sources in
gnu/java/nio/charset) Difficulty from easy to intermediate depending on
the charset. 

* awt.image needs more work in general. Requires knowledge of Java2D.

* Complete the imageio framework (may require the above first)

* We have AWT peers using the new Cairo library (www.cairographics.org).
These need improvement. Although this might need to wait until Cairo is
more stable.

* Currently our AWT peers (interface to the native GUI) are built on
GTK. This doesn't mean we don't want to support other toolkits and/or
platforms. KDE, OS X,

RE: Introduction, and a question

2005-05-17 Thread Subramanian, Sundar

This could even help in migrating apps across machines in a grid-like
environment dynamically depending on the availability of resources.
If this can be implemented it would be great.
Regards
~s

-Original Message-
From: Torsten Curdt [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 17, 2005 5:45 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Introduction, and a question

 True, but if you saved the entire state of the JVM memory on disk (an
 JVM 'hibernation'?) then you could just start from where you left,
 instruction pointer included.

huuuh ...that would be awesome!

 Not sure how hard it is to write, but doesn't sound like a bad idea to
me.

absolutely!

cheers
--
Torsten

Re: The topic of the Java Compiler

2005-05-17 Thread Thorbjørn Ravn Andersen

Geir Magnusson Jr. wrote:
Is one maintained better than the other?  I'd like to choose one  
(loosely) so we can start working with it.  Apache Tomcat ships with  
it, and I've used it elsewhere for having a shipping compiler for the  
same reason - for JSP compilation...
The Eclipse compiler is well maintained, and has a high priority within 
the project.  (Not much fun in an IDE if the compiler is buggy).

--
 Thorbjørn


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Intro to Classpath

I'm wondering, some parts of the JDK seens to be product features and not a 
standard. For examples, the sound system should use arts, esd or alsa (I 
believe Sun support the last 2). The printing system should support cups, 
lprng or both? The same goes for the crypto algorithms on the pack.

Rodrigo

On 5/16/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 
 Excellent! This is exactly what I was looking for!
 
 I will send an email to the mailing list tonight, read those links, and 
 maybe even hop onto the IRC channel in the next day or so.
 
 Thanks much!
 
 Stu Statman

Re: Developing Harmony

2005-05-17 Thread Ben Laurie

Steve Blackburn wrote:
A quick recap on key points from my original post (below):
. Focus on componentization
. Use one or two existing VMs to bootstrap and drive effort to componentize
. Concurrently develop new cores
As far as I can tell the goal of componentization is widely accepted.
I view the VM core as another component, one of the simplest, but most 
design critical.  The model of componentization allows any component to 
be written in whatever language makes most sense.

For the sake of momentum I advocate concurrently pushing 
componentization in one or more existing VM cores while developing new 
cores.

In my experience our biggest challenge is going to be in getting 
componentization to work.  We've pushed this hard with MMTk (getting it 
to plug into multiple VMs, across language boundaries), and since the MM 
is probably the most intricately connected component, that gives us hope.
You may find it interesting to read the writeup of the ORP team's effort 
to port their GC  JIT to Rotor 
(http://www.jot.fm/issues/issue_2004_10/article3/index_html).

I'm pretty sure we want a framework in C/C++, whatever components are 
developed in.

Umm.  Why?
So it can run everywhere.
--
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: Developing Harmony

2005-05-17 Thread Stefano Mazzocchi

Simon Chappell wrote:
On 5/16/05, Ben Laurie [EMAIL PROTECTED] wrote:
*snip*
Question to the floor: if it had to be one of C and C++, which would you
prefer?
Thanks Ben, that is a very productive question.
--
Stefano.

Re: Harmony Project Structure Attempt

2005-05-17 Thread Listreader

Hello Nick,

On Tue, May 17, 2005 at 11:23:16AM +0930, Nick Lothian wrote:
 Nice set of diagrams.

Thanks - they tend to visualize long segments of text in a simpler way.

 I certainly wouldn't agree that Harmony should: 
 
 aim[s] at creating a cleanroom, open source implementation of the Java 
 Virtual Machine in C/C++ or other OS-integration-friendly language. We 
 currently lack a good choice for JVM code baseline. Potentially, we face 
 reimplementing from scratch.
 
 A lot of people have expressed interest in a JVM written in Java providing 
 performance is adequate. There has been substantial evidence present to show 
 that it can be.

I simply collected what I felt was the opinion of the majority of posts
on the list thus far. Personally, I care little about the exact language
as long as it is relevant and optimal for writing the compiler.

Since Java lacks low-level memory management capabilities, and the 
JVM obviously needs to deal with these issues, I would be somewhat 
hesitant to write the full JVM in Java myself. 

Of course, we could simply contain these services within the OAL, and
fire away.

 We do not lack good choices for a JVM. Steve Blackburn has presented 
 a proposal to use Jikes RVM, and there has been discussion of Kaffe 
 and GCJ as well.

Good - I will update the text on the site to reflect that.

 (I also believe there is a desire to use the APR if an OS abstraction layer 
 is required).

I am uncertain at this point if the APR actually provides what needs to
be provided. That will likely be thoroughly investigated before long.

 Nick
 
  -Original Message-
  From: Listreader account [mailto:[EMAIL PROTECTED] 
  Sent: Tuesday, 17 May 2005 3:15 AM
  To: harmony-dev@incubator.apache.org
  Subject: Harmony Project Structure Attempt
  
  Hello all,
  
  I have created an initial attempt at reaching a consensus 
  regarding the structure of the Harmony project on 
  
  http://www.jguru.se/jguru/control/Developers/Harmony
  
  I was convenient and lazy enough to stash all on one page for now.
  Please read through it and post your comments on the dev-harmony list.
  
  Thanks all,
  
  ---
  // Lennart J?relid, Senior J2EE Architect // jGuru Europe AB 
  // lj __AT__ jguru.se
  
 
 
 IMPORTANT: This e-mail, including any attachments, may contain private or 
 confidential information. If you think you may not be the intended recipient, 
 or if you have received this e-mail in error, please contact the sender 
 immediately and delete all copies of this e-mail. If you are not the intended 
 recipient, you must not reproduce any part of this e-mail or disclose its 
 contents to any other party.
 This email represents the views of the individual sender, which do not 
 necessarily reflect those of education.au limited except where the sender 
 expressly states otherwise.
 It is your responsibility to scan this email and any files transmitted with 
 it for viruses or any other defects.
 education.au limited will not be liable for any loss, damage or consequence 
 caused directly or indirectly by this email.

Re: Stop this framework/modularity madness!

2005-05-17 Thread Stefano Mazzocchi

Royce Ausburn wrote:
In my experience, delaying the 'modular design' of a system causes  more 
work.
More coding work? sure thing.
If you factor into work the amount of email and time and emotional 
energy you will have to consume to get to that modular design over a 
mail list with 100 people, all thinking they know it best, the ratio 
might change.

Food for thought.
--
Stefano.

RE: Stop worrying about licenses!

2005-05-17 Thread Sven de Marothy

On Tue, 2005-05-17 at 10:58 +0930, Nick Lothian wrote:
 One specific question that I haven't seen addressed elsewhere:
 
 Currently the FAQ for classpath says:
 
 If you are going to contribute source code to GNU Classpath we must
 make sure that you have not studied the source code of the JDK/JRE or
 decompiled any of its classes. [1]

Yes. GNU Classpath has a strict clean-room policy.

 The FAQ for the new Java Research Licence says:
 
 18. Does the JRL prevent you from being able to create an independent
 implementation of J2SE?
 
 The JRL is not a tainting license, and includes an express residual
 knowledge clause. Under the JRL, merely looking at Sun's code does not
 prevent you from being able to create your own independent
 implementation of J2SE, and in any event, you can terminate the JRL at
 any time for any reason. So, yes, you can look at Sun source code and
 then later on go and work on an open-source J2SE implementation. [2]

From what I understand, FSF-legal hasn't said anything official on this
yet, but it's still a grey area. See this thread:
http://lists.gnu.org/archive/html/classpath/2005-05/msg00013.html

 Given these inconsistencies is it safe to look at the Sun JDK if we are
 planning to work on Classpath (and/or Harmony)

Bad wording. There is no inconsistency here. 

No. I would STRONGLY advise against looking at Sun's sources, no matter
what Sun's license says. In my experience hacking on Classpath, and as a
Java coder, there are very few cases where you would ever need or want
to look at Sun's sources anyway. Even though it might be OK with this
new license, why take the risk?

Harmony hasn't decided how to relate to this either, but the Harmony
proposal suggests a cautious stance as well:

Historically, there has been wide exposure to VM and class-library-
specific source code that is the property of Sun Microsystems as well
as others, as it is common for commercial J2SE implementations to be
based on licensed Sun code.  We wish to make every effort to ensure
that the licenses and rights of external projects and efforts is
properly respected.  To that end, we will explore additional ways to
work with the Apache Incubator to ensure that all IP is carefully
monitored and tracked as it enters the project.

Let the FSF and ASF lawyers sort it out.

/Sven

Re: Developing Harmony

2005-05-17 Thread Ozgur Akan

Hi,
I also prefer C which is simpler to use and also As Nicolas said has 
smaller memory footprint.

Ozgur Akan
Simon Chappell wrote:
On 5/16/05, Ben Laurie [EMAIL PROTECTED] wrote:
*snip*
 

Question to the floor: if it had to be one of C and C++, which would you
prefer?
   

C.
C++ was a terrible thing to do to a language! :-)
Simon

Re: Organizing the Mailing List

2005-05-17 Thread Raffaele Castagno

2005/5/17, Bryce Leo [EMAIL PROTECTED]:
 
 
 What do you think?


Good enough for me... I'll use it!

Bye!

Raffaele

Re: Stop worrying about licenses!

On May 16, 2005, at 9:28 PM, Nick Lothian wrote:
One specific question that I haven't seen addressed elsewhere:
Currently the FAQ for classpath says:
If you are going to contribute source code to GNU Classpath we must
make sure that you have not studied the source code of the JDK/JRE or
decompiled any of its classes. [1]
The FAQ for the new Java Research Licence says:
18. Does the JRL prevent you from being able to create an independent
implementation of J2SE?
The JRL is not a tainting license, and includes an express residual
knowledge clause. Under the JRL, merely looking at Sun's code does  
not
prevent you from being able to create your own independent
implementation of J2SE, and in any event, you can terminate the JRL at
any time for any reason. So, yes, you can look at Sun source code and
then later on go and work on an open-source J2SE implementation. [2]

Given these inconsistencies is it safe to look at the Sun JDK if we  
are
planning to work on Classpath (and/or Harmony)
Yes, and no :)
This is a complex issue I have scheduled for another, separate  
thread.  Sun's intent is that if you see src.jar or -ish, you are  
*not* tarnished for life and unable to participate.  That said, we  
want to find a clear, unambiguous statement about what that really  
means.  I think that if you glanced at src.jar when debugging or  
trying to figure out how things work, then you'll be fine (assuming  
we have that clear, unambiguous statement...).  If you were an  
employee of Sun working on this code?  Dunno.  We'll probably ask  
that you stay clear at least from the parts you worked on to prevent  
accidents :)

More in a sep thread.
geir
Nick
[1] http://www.gnu.org/software/classpath/faq/faq.html#faq3_2
[2] http://java.net/jrl.html

-Original Message-
From: Leo Simons [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 17 May 2005 1:05 AM
To: harmony-dev@incubator.apache.org
Subject: Stop worrying about licenses!
Hi all,
Thanks for all the input into the legal discussion so far.
We've got enough input for now :-)
Roughly 95% of the people on this list should from this point
forward stop worrying about licensing issues for, oh, I
dunno, the next 6 months. The harmony project mentors and its
PPMC will keep working with all appropriate parties (like ASF
legal, FSF legal, Sun, and others) to resolve these issues,
and they're perfectly capable of doing that.
For now, you can assume:
 * we *can* use GNU Classpath as long as we do not publish
any releases, ie
   at least for the next six months;
 * we *may* stop using GNU Classpath at some point in the future;
 * the answer to most of your legal questions will be
provided within a
   reasonable timeframe without you needing to actually ask
those questions
   (we already know what those questions are, we don't have
the answers yet,
   but we are working on it).
One of the things the ASF offers to projects is the freedom
to not worry about most of the legal mess. So don't, and get
to work :-)
Thanks and happy hacking!
- Leo



IMPORTANT: This e-mail, including any attachments, may contain  
private or confidential information. If you think you may not be  
the intended recipient, or if you have received this e-mail in  
error, please contact the sender immediately and delete all copies  
of this e-mail. If you are not the intended recipient, you must not  
reproduce any part of this e-mail or disclose its contents to any  
other party.
This email represents the views of the individual sender, which do  
not necessarily reflect those of education.au limited except where  
the sender expressly states otherwise.
It is your responsibility to scan this email and any files  
transmitted with it for viruses or any other defects.
education.au limited will not be liable for any loss, damage or  
consequence caused directly or indirectly by this email.


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Apache Harmony / GNU Classpath

On May 16, 2005, at 3:59 PM, usman bashir wrote:
But !
 if u people dont mind (dont take me splitter again ;) ) then i  
would say
while considering Classpath for library we should design in such a  
way that
if some one want to replace with its own (his own wish thats what  
OSS is )
then he can do it easily. (and i hope follwowing the TCK it could be
accomplish too as well )

Yes - that's the goal of having a standard interface between the VM  
and the class library.

geir
 On 5/16/05, S. Meslin-Weber [EMAIL PROTECTED] wrote:
Hi Geir,
On Mon, May 16, 2005 at 06:47:40AM -0400, Geir Magnusson Jr. wrote:
I have no intention of forking GNU Classpath. Even if we wanted to,
we couldn't because of the license.

Just to be clear on this point, the license for GNU Classpath is
GPL+Exception and does not prohibit forking.
I believe you are saying that forking and relicensing under an  
Apache
license isn't currently feasible. The forking block is merely a  
license
incompatibility in this context (and has a separate discussion).

I think that when referring to the license or the licenses we  
should
be more clear as to which licenses we mean otherwise we run the  
risk of
confusing those unfamiliar with current context.

Best Regards,
Steph
--

Stephane Meslin-Weber Email: [EMAIL PROTECTED]
Software Engineer Web: http://odonata.tangency.co.uk

BodyID:55162909.2.n.logpart (stored separately)


--
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
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Organizing the Mailing List

We tend to do this naturally - we put something in the subject line  
to distinguish.  Maybe we'll come up w/ some patterns.

One thing to consider is when we get going with things, to split off  
an architecture list if the volume gets too much.  But for now, it's  
light enough to keep it all here.  Comments?

geir
On May 16, 2005, at 6:48 PM, Bryce Leo wrote:
As harmony is just getting started, there is a great deal of good
suggestions, questions and offers for help. Ever since the Slashdot
announcement I personally think that the number of people whom have
joined and offered their services has clearly gone up and to promote
organization I'm proposing a naming scheme for subject of emails. The
Bulletin board style tags are just to promote reading ease.
First lets look at what seem to be the larger topics of discussion.
[BigCategories]
JVM: The Java Virtual Machine, where to start, different available
codebases and strategies.
Compiler: Creating a javac like tool.
Documentation: It's always easier to document as you go along and well
documented code can save tons of time in tracking down bugs.
Libraries: Which ones to choose or develop individually
Tools: The associated java tools, applet viewer, jar, etc.
Introduction: This would be used for if your'e introducing yourself,
listing prior experience, etc.
DevPriority: The overall discussion of which parts of harmony should
be developed first.
Target OS: Seems small but it doesn't belong as a part of any other so
it gets its own.
Licensing: Should really be a minor concern for now, once we pick up
steam this issue will be logically sorted out. It's and
inter-dependancy (i apologize if i used the word wrong), choosing a
licence effects our code base choices and visa-versa
Organization: How things should be organized.
[/BigCategories]
Below these would be sub-categories that would provide more insight
into the larger topic.
[SmallCategories]
Suggestion: General suggestion(s) for a particular topic.
Questions: Questions about a particular topic.
DevPriority: Probably shouldn't be used yet, would be used for
sub-development. i.e. What order things should be developed for the
compiler.
Organization: How things should be organized.
[/SmallCategories]
So say for example you wanted to send a brand new suggestion for the
JVM the topic of the post would be JVM--Suggestion and if you wanted
to ask a questions about a compiler it would be Compiler--question
and so on like that.
This should be friendly for both threaded and un-threaded mail
clients. And under this system this mail would be
Organization--Organization but for now that's irrelevant.
I think this system would really help focus the group and allow people
to easily tune in to what interests them and keep a tab on the general
flow of the project, while right now things seem a bit willy-nilly.
What do you think?
--
~Bryce Leo
--Veritas Vos Liberabis--

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Developing Harmony

2005-05-17 Thread Bryce Leo

Now don't go too crazy for my suggesting this, but why not pascal? If
we're considering C as it is this really isn't a terrible suggestion.
I know it's fallen out of favor with most of you guys but it compiles
quickly and supports a good number of operating systems and types of
hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
betting that you guys won't like it but I think the option should be
listed.

Opinions?
 
~Bryce Leo


--Veritas Vos Liberabis--

Re: Developing Harmony

Oog. grunt Thog like to bang rocks, but Thog also like inheritance,  ABCs 
and generics.
If by generics you mean STL, it is my understanding that creates 
cross-platform problems, which is why many cross-platform C++ projects don't 
use it.

_
Dont just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

RE: Harmony Project Structure Attempt

We do not lack good choices for a JVM. Steve Blackburn has presented a 
proposal to use Jikes RVM, and there has been discussion of Kaffe and GCJ 
as well.
And and least one person one this list has offered a VM they have written, 
and to change the license to the Apache license.

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Developing Harmony

I can't think of a single reason why C should be preferred over C++.
C can simply be viewed as a subset of C++
Not anymore, really.  The current ISO standards for C and C++ have 
eliminated the C++ is only a superset aspect.  They really are different 
languages.

Also, you CAN write C in an object-oriented style, as the GTK+ project 
demonstrates.

However...
I'm however very fond of the idea of writing the JVM in Java. I'm
beginning to look into the JikesRVM and I really like the idea,
especially as it is the language that everyone on this list is familiar
with.
That would be my preference as well.  Eating our own dog food has the 
benefit of forcing us to deal with optimization issues that we might 
otherwise sweep under the carpet through using a lower-level language.  It 
also introduces much more time debugging, fixing common errors, handling 
threading through low-level APIs, etc, to use either C or C++, not to 
mention that if we use C++, we would have to use a restricted subset of C++ 
to assure portability, and that will create its own headaches..

So I would support sticking with Java also.
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Developing Harmony

2005-05-17 Thread Thorbjørn Ravn Andersen

Jónas Tryggvi Jóhannsson wrote:
Im however very fond of the idea of writing the JVM in Java. Im 
beginning to look into the JikesRVM and I really like the idea, 
especially as it is the language that everyone on this list is  
familiar with. It would also maximize the quality of the tools that we 
will provide, as we would be using them to develop our JVM.
The JNode project has a JVM which has a small microkernel, and where the 
rest is written in Java.  Their performance figures[1] shows it to be 
comparable to the Sun HotSpot compiler.

Does my mails come through, by the way? 

[1] http://jnode.sourceforge.net/portal/node/51
--
 Thorbjørn

Re: Introduction, and a question

2005-05-17 Thread Ben Laurie

Stefano Mazzocchi wrote:
Christian Damsgaard wrote:
I brought up this idea with Lars Bak (HotSpot architect at Sun back 
then) at a conference some years back when Sun introduced the HotSpot 
VM. The argument back then was that a program mays not execute in the 
same pattern every time and the optimization made previously may no 
longer apply.

True, but if you saved the entire state of the JVM memory on disk (an 
JVM 'hibernation'?) then you could just start from where you left, 
instruction pointer included.
Just one _teensy_ snag. Open files and sockets. And all state external 
to the JVM.

--
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: Stop this framework/modularity madness!

2005-05-17 Thread Steve Blackburn

Hi Rodrigo,
I believe the focus should be on deciding if Harmony will star from
other JVM or not.
I agree entirely that this is an important issue, and a lot of people 
are working hard right now to see if this can happen.  Donating an 
entire JVM to apache is not a trivial issue, so we will need to be patient.

However, it is not the either/or situtation you paint above.  I think it 
may make most sense to work on a preexisting donated VM or VMs while 
*concurrently* developing a new VM core or cores from scratch.  This 
approach has a number of advantages, including maximizing our leverage 
from existing work, minimizing startup time and accelerating the process 
of building an existing VM.  It also allows us to more fruitfully 
explore some of the implementation choices (which language to use, ...).

[previously you wrote...]
Making Harmony modular enouth to be kind of a JVM framework cannot be
done before having a working JVM. There is a lot of literature about
how frameworks should emerge from continuous design and development.
 

The donated VM or VMs (if they araise) may already be at this point.  As 
I have already said, this is a process already underway in the Jikes RVM 
project.  I can't speak for the other projects, but they may also be at 
such a stage or, better, have moved beyond that stage.

This must not be the focus until required, so no JIT plugable layer
until someone tries to write another JIT for Harmony (emphasis on
another).
 

I would like to leverage prexisting VMs to push the process of 
modularization.

Creating such is a big chalenge, to guess what spots need to flexible
and the others that don't. Guess what, people often make bad guesses
about these and in the end we have a very complex design with a lot of
shortcomings.
 

Right.  This is why it is essential that harmony learn from kaffe, gcj, 
jikesrvm, sable, ovm, joeq, etc etc.  The project does not exist in a vacum.

--Steve

Re: The topic of the Java Compiler

Nether support apt, AFAIK, which seens to be an easier task to do with the 
Eclipse compiler.

Rodrigo

On 5/16/05, Nick Lothian [EMAIL PROTECTED] wrote:
 
 
   Berlin == Berlin Brown [EMAIL PROTECTED] writes:
 
  Berlin The compiler seems to be a non-issue at this time
  with a focus
  Berlin on the JavaVM. What are your thoughts on the different
  Berlin compilers?
 
  For Harmony I would say the leading contender is the java
  compiler that comes with Eclipse. It is written in java and
  already supports all the 1.5 features.
 
  As far as gcj goes, the new 1.5-ish front end I'm writing has
  a standalone part which does all the language processing and
  bytecode generation. It does not depend on the rest of gcc
  at all. It is written in C++.
 
  kjc is also out there and being developed, but I don't know
  much about it.
 
 
 The Eclipse compiler is already being embedded in Tomcat and works well.
 It also has the advantage of a liberal Apache compatible licence.
 
 There is also the Jikes compiler (which isn't the same as the Eclipse
 compiler, nor the Jikes RVM).
 
 Nick
 
 IMPORTANT: This e-mail, including any attachments, may contain private or 
 confidential information. If you think you may not be the intended 
 recipient, or if you have received this e-mail in error, please contact the 
 sender immediately and delete all copies of this e-mail. If you are not the 
 intended recipient, you must not reproduce any part of this e-mail or 
 disclose its contents to any other party.
 This email represents the views of the individual sender, which do not 
 necessarily reflect those of education.au limited except where the sender 
 expressly states otherwise.
 It is your responsibility to scan this email and any files transmitted 
 with it for viruses or any other defects.
 education.au limited will not be liable for any loss, damage or 
 consequence caused directly or indirectly by this email.

Re: Developing Harmony

2005-05-17 Thread Carlos Fernandez Sanz

Jónas Tryggvi Jóhannsson wrote:

Question to the floor: if it had to be one of C and C++, which would 
you prefer?

I can't think of a single reason why C should be preferred over C++.
C can simply be viewed as a subset of C++, and as Java users we all
This might be true for newbies but anyone who has used both knows that 
this assertion is very superficial.
Using C or C++ is, among other things, a design decision.

Having said that, I'd say that the biggest advantage of C++ in this case 
is its library. Are we going to use it to implement Java's? Are we going 
to use boost?

Carlos.

RE: Introduction, and a question

2005-05-17 Thread Subramanian, Sundar

My original intention of having a snapshot was not so much as to have a quick 
restart but to be able to migrate apps a la distributed JVM efforts 
(http://djvm.anu.edu.au/) as Steve has mentioned in this thread earlier.

As you say I guess persistence along with machine specific JIT code might be a 
hard problem to solve. Sun's efforts in this direction is a good partial 
solution. But taking care of the environmental parameters like open JDBC 
connections etc would also have to be implemented if any movement in this 
direction is to be expected.

Regards
~sundar

-Original Message-
From: Nick Lothian [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 17, 2005 10:36 AM
To: harmony-dev@incubator.apache.org
Subject: RE: Introduction, and a question

 
 El lun, 16-05-2005 a las 16:08 +0530, Subramanian, Sundar escribió:
 (...)
  I guess what Brad is asking is for a snapshot of the state of JVM.
  This
  would be really useful to migrate stuff from one environment to 
  another preserving the underlying state.
 
 I have mixed feelings about having a save image __a la__ 
 Smalltalk, if this is what you are meaning. While delivering 
 an image looks tempting, state gets corrupt in unpredictable 
 ways, and having ways to track changes becomes a nightmare.
 
 The Smalltalk community has worked hard in this (hard) 
 problem, but I'm still not sure if it would make sense in the 
 java world. Java is a system-oriented language, and the 
 ability to save the whole VM state and recover from this 
 saved image would bring additional constraints to the Virtual 
 Machine implementation. For instance, machine specific JIT 
 code should be invalidated upon save, negating a substantial 
 part of the advantages of a saved image (faster startup).
 
 This said, if VM implementors out there find easy ways to 
 meet these constraints w/o burdening runtime or memory 
 requirements, it could be an area for experimenting.
 

This looks like it would be related to the stuff Sun has done with class data 
sharing in the 1.5 JVMs:

When the JRE is installed on 32-bit platforms using the Sun provided 
installer, the installer loads a set of classes from the system jar file into a 
private internal representation, and dumps that representation to a file, 
called a shared archive. Class data sharing is not supported in Microsoft 
Windows 95/98/ME. If the Sun JRE installer is not being used, this can be done 
manually, as explained below. During subsequent JVM invocations, the shared 
archive is memory-mapped in, saving the cost of loading those classes and 
allowing much of the JVM's metadata for these classes to be shared among 
multiple JVM processes. [1]

This isn't quite the same as saving JIT'ed code, but it sounds like it is 
saving the pre-parsed and verified class files.

Nick

[1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html


IMPORTANT: This e-mail, including any attachments, may contain private or 
confidential information. If you think you may not be the intended recipient, 
or if you have received this e-mail in error, please contact the sender 
immediately and delete all copies of this e-mail. If you are not the intended 
recipient, you must not reproduce any part of this e-mail or disclose its 
contents to any other party.
This email represents the views of the individual sender, which do not 
necessarily reflect those of education.au limited except where the sender 
expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it 
for viruses or any other defects.
education.au limited will not be liable for any loss, damage or consequence 
caused directly or indirectly by this email.

Re: Stop this framework/modularity madness!

On May 16, 2005, at 3:58 PM, Rodrigo Kumpera wrote:
Making Harmony modular enouth to be kind of a JVM framework cannot be
done before having a working JVM. There is a lot of literature about
how frameworks should emerge from continuous design and development.
There's been a lot of work in this area, and many of the people that  
did it are here and willing to help...

Given that body of knowledge, why not?
This must not be the focus until required, so no JIT plugable layer
until someone tries to write another JIT for Harmony (emphasis on
another).
Creating such is a big chalenge, to guess what spots need to flexible
and the others that don't. Guess what, people often make bad guesses
about these and in the end we have a very complex design with a lot of
shortcomings.
I believe the focus should be on deciding if Harmony will star from
other JVM or not.
We hope so :)  We're lazy
geir
Rodrigo

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Intro to Classpath

2005-05-17 Thread Sven de Marothy

On Tue, 2005-05-17 at 11:46 -0300, Rodrigo Kumpera wrote:
 I'm wondering, some parts of the JDK seens to be product features and not a 
 standard. For examples, the sound system should use arts, esd or alsa (I 
 believe Sun support the last 2). The printing system should support cups, 
 lprng or both? 

Such matters are of course not part of the Java spec and are completely
up to the implementation. There would be no point in having a Java API
for these things if a certain underlying API was required. 

 The same goes for the crypto algorithms on the pack.

No. Although parts of crypto (like so much of the newer APIs) is behind
a Service Provider Interface, you still want to provide everything Sun
does, because applications will expect those algorithms to be available.

While I'm not sure this is required for strict-TCK compatibility, it is
certainly a compatibility issue for real-world apps.

/Sven

Gosling on Harmony

2005-05-17 Thread Tomer Barletz

http://www.devx.com/Java/Article/28125?trk=DXRSS_JAVA

Looks like Doc java is pretty upset...

Re: Stop worrying about licenses!

2005-05-17 Thread Felipe Leme

On Mon, 2005-05-16 at 17:34 +0200, Leo Simons wrote:
 Hi all,

Hi Leo...

 For now, you can assume:
 
  * we *can* use GNU Classpath as long as we do not publish any releases, ie
at least for the next six months;
 
  * we *may* stop using GNU Classpath at some point in the future;

So, for all these developers eager to start coding (I've counted more
than a handful of them; unfortunately I'm out of the tally, for lack of
time), should we recommend they start to contribute by submitting
Classpath patches (which we could kindly cal Classpatches :-) ?

[]s,

-- Felipe

Re: Stop this framework/modularity madness!

Maybe this pluggable layer that is not well defined. I think that having 
this as a link time thing is more than enouth. It doesn´t mean that only one 
GC algorithm or JITer will be available at runtime, but all the options 
should be defined when building the JVM.
 Refactoring a system to have a framework emerge is a lot easier, productive 
and produce less cluter. Lets not make generic what doesn't need to be.
 But a better argument is close inspection of this list archive. Seens like 
nobody trully knows how to proper layer a JVM for good modularity. The 
JikesRVM folks are refactoring to make this possible on their JVM, but right 
now they can't really say how it will look when finished.
  Rodrigo
 On 5/17/05, Royce Ausburn [EMAIL PROTECTED] wrote: 
 
 
 Ack - Sorry about the incomplete mail.
 
 On 17/05/2005, at 3:58 AM, Rodrigo Kumpera wrote:
 
 
  This must not be the focus until required, so no JIT plugable layer
  until someone tries to write another JIT for Harmony (emphasis on
  another).
 
 
 In my experience, delaying the 'modular design' of a system causes
 more work. When you rip out the old part, not only do you have to
 design and implement this pluggable layer, this layer probably needs
 alot more design work because you have to consider all the other
 systems that are affected. This also isn't easy because the project
 hasn't been designed in a modular fashion. THen you have to
 reimplement the old part (the JIT bit in your example) - May as well
 design everything to work together in harmony to begin with.
 
 --Royce

Re: Developing Harmony

2005-05-17 Thread Ricky Clarkson

Do we need the extra features of C++ for the low-level stuff that
Harmony needs to do?  Java can provide the OO wrappers around things,
we don't need Java wrappers around C++ classes around C functions..

I don't think there's enough gain in using C++ to warrant the extra
complexity in its use.  But that's just me.

On 16/05/05, Steve Blackburn [EMAIL PROTECTED] wrote:
 A quick recap on key points from my original post (below):
 
 . Focus on componentization
 . Use one or two existing VMs to bootstrap and drive effort to componentize
 . Concurrently develop new cores
 
 As far as I can tell the goal of componentization is widely accepted.
 
 I view the VM core as another component, one of the simplest, but most
 design critical.  The model of componentization allows any component to
 be written in whatever language makes most sense.
 
 For the sake of momentum I advocate concurrently pushing
 componentization in one or more existing VM cores while developing new
 cores.
 
 In my experience our biggest challenge is going to be in getting
 componentization to work.  We've pushed this hard with MMTk (getting it
 to plug into multiple VMs, across language boundaries), and since the MM
 is probably the most intricately connected component, that gives us hope.
 
 You may find it interesting to read the writeup of the ORP team's effort
 to port their GC  JIT to Rotor
 (http://www.jot.fm/issues/issue_2004_10/article3/index_html).
 
  I'm pretty sure we want a framework in C/C++, whatever components are
  developed in.
 
 Umm.  Why?
 
 --Steve
 
 My original post
 
 I am going to stick my neck out and make a few concrete suggestions
 for how the Harmony VM might be developed.
 
 A few motivating goals:
 
  o Focus on modular, interchangeable components
- exploit existing compilers, memory managers etc
- promote configurability (different components for different contexts)
- allow diversity in development approaches
- encourage large-scale contributions (here's a compiler)
 
  o Bootstrap the project rapidly
- capture momentum
- seed the project with an existing VM-core (or cores)
 
  o Design a clean core (or cores) from scratch
- do this concurrently with work on components in existing core/s
- the core should be lightweight
- multiple cores may make sense
  - the needs of different contexts may require this
  - competing approaches may be healthy
 
 A concrete option:
 
 1. Use two VMs as seeds
a) Jikes RVM is a possible candidate
   . Focus energy on cleaning it up and modularizing it. This is
 something we've already begun (see earlier post), but will
 take a lot of work.
 + Get a very good optimizing compiler
 + Get an efficient and modular memory management toolkit
   (MMTk)
 - Need to deal with licensing issues and gain the consent of
   the community (not insurmountable)
 - Need hard work to achieve modularity goal for whole VM
 
b) Another very different VM (kaffe?)
  . amenable to modularization
  . amenable to other components (drop in MMTk?)
 
 2. Leverage extensive experience to build new core/s
. Start with a clean slate
. Leverage all of our diverse experience (gcj, kaffe, ovm, joqe,
 jnode,...)
. Work concurrently with above work on components in old core/s,
  miminize loss of momentum, try to really think it through
  carefully.
. May be sensible to develop more than one core
 
 3. Develop new components
. Extract components from existing work, apply to new VM/s
. Develop new components from scratch
. Encourage porting of existing compilers etc into this framework
 
 Alternative options:
 
  o Start with just one seed
 
  o There are many different ways... the above is indicative, not exclusive
 
 OK.  So I've stuck my neck out.  The above is vague and very
 ambitious, but those rough thoughts come out of a lot of experience
 with VM design---not just mine but the experience of those who I've
 been discussing this with and working with.  A component based VM is
 not trivial at all.  I've not mentioned any of the vast complexity
 that lies within a real VM.  However, my experience with porting MMTk
 across some very different VMs (Jikes RVM--Java, Rotor--C/C++, and now
 working on porting to jnode--Java) gives me hope!
 
 Cheers,
 
 --Steve

Re: Developing Harmony

C++, just C++, is a recipe for trouble. Most projects that use it define a 
subset to make development a less painfull talk. Usually operator 
overloading, templates and virtual inheritance are discarded.

Rodrigo

On 5/17/05, Ben Laurie [EMAIL PROTECTED] wrote:
 
 Jónas Tryggvi Jóhannsson wrote:
 
  Question to the floor: if it had to be one of C and C++, which would
  you prefer?
 
 
  I can´t think of a single reason why C should be preferred over C++,
 as
  C can simply be viewed as a subset of C++.
 
 That sounds like a reason to me.
 
  As Java users, all of us
  appreciate object orientation and understand how it can be used to
  simplify software and make it more readable. Writing C code in an object
  oriented manner simply does not give the same level of abstraction C++
  can provide.
 
 I agree. Many developers don't.
 
  Im however very fond of the idea of writing the JVM in Java. Im
  beginning to look into the JikesRVM and I really like the idea,
  especially as it is the language that everyone on this list is familiar
  with.
 
 As I said before, don't assume we're all Java fans here. I'm far more
 familiar with C++ than I am with Java.
 
  It would also maximize the quality of the tools that we will
  provide, as we would be using them to develop our JVM.
 
 Like I said, a framework that allows you to do this is definitely what I
 want to see. But it should also allow me to write the JVM in C.
 
 Is the Jikes licence one we can use?
 
 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: impatient ;)

2005-05-17 Thread Peter Donald

Hi,
I am sure that the code donated could be of use somewhere in the harmony 
effort. Don't get too discouraged if no one jumps on it right away 
though. The biggest need for harmony is not so much the code that you 
have produced but the code that you will produce in the future.

At the start there may seem like a lot of talking gets done with no code 
 but eventually things will settle down and I hope you are still around 
at that point. It would be very useful to get your input on the harmony 
JVM in what ever form it takes.

I think someone has already said it on this list (probably Stefano if I 
remember him correctly) but the best way to build a community is with 
crappy code and great ideas. Community is what is needed to get Harmony 
into a state that is likely to succeed.

(Just chiming in as you may not get an immediate response but that 
should not discourage you.)

---
Cheers,
Peter Donald
*-*
* Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof.   *
*  - John Kenneth Galbraith   *
*-*
Archie Cobbs wrote:
Stefano Mazzocchi wrote:
Those who have a JVM and want to donate it under the apache license to 
seed harmony raise their hands now!

As mentioned before, and/all of JC [1] is available and I'll
be happy to relicense it. All of the code was written by me
(though I didn't invent all of the algorithms of course).
Some bits I can think of that may be useful, roughly ordered
from smaller and more likely to larger and less likely...
  - Splay tree implementation (splay.c)
  - String/UTF-8 functions (string.c, utf.c)
  - ZIP file reader (zip.c)
  - Class file parser (cf_parse.c)
  - Native local and global reference code (native_ref.c)
  - Per-classloader memory allocator (cl_alloc.c)
  - SableVM thin lock algorithm (lock.c)
  - Native library loader (native_lib.c)
  - VM Bootstrap code (vm.c, bootstrap.c)
  - JNI support (jni_invoke.c, jni_native.c)
  - Reflection support (reflect.c)
  - Dynamic invoker (invoke.c)
  - Threading support (thread.c)
  - Heap structure and garbage collector (heap.c, gc_root.c, gc_scan.c).
  - Bytecode interpreter (interp.c)
  - Class loading, derivation, and resolution (load2.c, derive2.c,
resolve.c)
There's also an ELF object loader and DWARF2 parser if you need those :-)
-Archie
[1] http://jcvm.sourceforge.net/
__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

Re: Organizing the Mailing List

2005-05-17 Thread Stuart Still

I agree.  Perhaps though it might be helpful to split into a legal  
and technical list shortly?

Cheer
Stuart
On 17 May 2005, at 16:55, Geir Magnusson Jr. wrote:
We tend to do this naturally - we put something in the subject line  
to distinguish.  Maybe we'll come up w/ some patterns.

One thing to consider is when we get going with things, to split  
off an architecture list if the volume gets too much.  But for now,  
it's light enough to keep it all here.  Comments?

geir
On May 16, 2005, at 6:48 PM, Bryce Leo wrote:

As harmony is just getting started, there is a great deal of good
suggestions, questions and offers for help. Ever since the Slashdot
announcement I personally think that the number of people whom have
joined and offered their services has clearly gone up and to promote
organization I'm proposing a naming scheme for subject of emails. The
Bulletin board style tags are just to promote reading ease.
First lets look at what seem to be the larger topics of discussion.
[BigCategories]
JVM: The Java Virtual Machine, where to start, different available
codebases and strategies.
Compiler: Creating a javac like tool.
Documentation: It's always easier to document as you go along and  
well
documented code can save tons of time in tracking down bugs.

Libraries: Which ones to choose or develop individually
Tools: The associated java tools, applet viewer, jar, etc.
Introduction: This would be used for if your'e introducing yourself,
listing prior experience, etc.
DevPriority: The overall discussion of which parts of harmony should
be developed first.
Target OS: Seems small but it doesn't belong as a part of any  
other so
it gets its own.

Licensing: Should really be a minor concern for now, once we pick up
steam this issue will be logically sorted out. It's and
inter-dependancy (i apologize if i used the word wrong), choosing a
licence effects our code base choices and visa-versa
Organization: How things should be organized.
[/BigCategories]
Below these would be sub-categories that would provide more insight
into the larger topic.
[SmallCategories]
Suggestion: General suggestion(s) for a particular topic.
Questions: Questions about a particular topic.
DevPriority: Probably shouldn't be used yet, would be used for
sub-development. i.e. What order things should be developed for the
compiler.
Organization: How things should be organized.
[/SmallCategories]
So say for example you wanted to send a brand new suggestion for the
JVM the topic of the post would be JVM--Suggestion and if you  
wanted
to ask a questions about a compiler it would be Compiler--question
and so on like that.

This should be friendly for both threaded and un-threaded mail
clients. And under this system this mail would be
Organization--Organization but for now that's irrelevant.
I think this system would really help focus the group and allow  
people
to easily tune in to what interests them and keep a tab on the  
general
flow of the project, while right now things seem a bit willy-nilly.

What do you think?
--
~Bryce Leo
--Veritas Vos Liberabis--

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Developing Harmony

If C/C++ is going to be used, the reference compiler is gcc. I don´t think 
the pascal frontend of gcc is up to the others. 
  Rodrigo
 On 5/17/05, Bryce Leo [EMAIL PROTECTED] wrote: 
 
 Now don't go too crazy for my suggesting this, but why not pascal? If
 we're considering C as it is this really isn't a terrible suggestion.
 I know it's fallen out of favor with most of you guys but it compiles
 quickly and supports a good number of operating systems and types of
 hardware, like arm and AMD64 (referencing Free Pascal that is). I'm
 betting that you guys won't like it but I think the option should be
 listed.
 
 Opinions?
 
 ~Bryce Leo
 
 --Veritas Vos Liberabis--

Cross plaform issues

A quick look at APR reveal that it doesn´t provide all OS abstraction that a 
JVM needs. There are no functions to mark pages as executable, access to 
scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for 
small diferences on syscalls or libC implementation.
 I think Harmony should use autotools and some m4 magic to help with that.
 Rodrigo

Re: Developing Harmony

Now don't go too crazy for my suggesting this, but why not pascal?
Which dialect?  ISO or GPC?  Free Pascal or Delphi? (and if Delphi, which 
version) etc..

Ada95 is superior for most purposes to Pascal, is more standardized (there 
is only one standard) and is also widely available.  It also produces very 
stable, reliable, maintainable applications, and has great standard thread 
support.  There are widely available free implementations.  It has seen 
heavy use in embedded and real-time applications (where many C/C++ compilers 
don't cut the mustard and real-time Java is still ghosty) which by their 
nature bear a strong resemblance to a VM and have a similar problem domain.

However, most people's exposure to Pascal is long ago and in an academic 
context, at least here in the States. I think most schools here have used C 
or C++, some have moved to Java, and there are some that avoid business 
languages altogether, using stuff like Scheme.  On the other hand, C, C++, 
and Java are more likely to be known to the developer base that would be 
interested in this project.

My comment is not intended to be a flame for the Pascal fans.  I know that 
Free Pascal has just come out with 2.0, and there are many people, 
particularly in Europe, who cut their teeth on Pascal.  If we are looking at 
something outside the C family (i.e. C/C++/Java/C#) as an implementation 
language, my opinion is that Pascal is not necessarily the best choice even 
among imperitive programming languages.  However, most open source 
development centers around C family languages, and there is the issue of 
critical mass as well as of technical suitability.  I guess the answer for 
me is that Pascal in the round doesn't really offer that much of an 
advantage over using a C family language to set off the disadvantages.

_
Dont just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

proposal translation

2005-05-17 Thread Ozgur Akan

I am translating the proposal to Turkish. Whom shall I sent this and in 
which format ?

thanks,
aiQa

Re: impatient ;)

2005-05-17 Thread Matt Benson

just a note... it appears that Ant (and thus Maven, I
assume) can already use the Eclipse JDT compiler when
properly configured.  If by chance one of these
(Apache) projects is used for builds, how much value
is there in creating another point of entry?

-Matt


--- Davanum Srinivas [EMAIL PROTECTED] wrote:
 go for it!
 
 -- dims
 
 On 5/16/05, Patrice Le Vexier
 [EMAIL PROTECTED] wrote:
   here's a task for those of you who want
 something to do: wrap the
   eclipse JDT compiler and make it look/feel like
 javac from the
   command line.
  
   --
   Stefano.
  
  
  
  If there is no objection to use this compiler, I
 can do that.
  
  Please, let me know.
  
  patrice
  
 
 
 -- 
 Davanum Srinivas -
 http://webservices.apache.org/~dims/
 



__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail

Re: Introduction, and a question

2005-05-17 Thread Davanum Srinivas

nice to see u here sundar :)

On 5/17/05, Subramanian, Sundar [EMAIL PROTECTED] wrote:
 My original intention of having a snapshot was not so much as to have a quick 
 restart but to be able to migrate apps a la distributed JVM efforts 
 (http://djvm.anu.edu.au/) as Steve has mentioned in this thread earlier.
 
 As you say I guess persistence along with machine specific JIT code might be 
 a hard problem to solve. Sun's efforts in this direction is a good partial 
 solution. But taking care of the environmental parameters like open JDBC 
 connections etc would also have to be implemented if any movement in this 
 direction is to be expected.
 
 Regards
 ~sundar
 
 -Original Message-
 From: Nick Lothian [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, May 17, 2005 10:36 AM
 To: harmony-dev@incubator.apache.org
 Subject: RE: Introduction, and a question
 
 
  El lun, 16-05-2005 a las 16:08 +0530, Subramanian, Sundar escribió:
  (...)
   I guess what Brad is asking is for a snapshot of the state of JVM.
   This
   would be really useful to migrate stuff from one environment to
   another preserving the underlying state.
 
  I have mixed feelings about having a save image __a la__
  Smalltalk, if this is what you are meaning. While delivering
  an image looks tempting, state gets corrupt in unpredictable
  ways, and having ways to track changes becomes a nightmare.
 
  The Smalltalk community has worked hard in this (hard)
  problem, but I'm still not sure if it would make sense in the
  java world. Java is a system-oriented language, and the
  ability to save the whole VM state and recover from this
  saved image would bring additional constraints to the Virtual
  Machine implementation. For instance, machine specific JIT
  code should be invalidated upon save, negating a substantial
  part of the advantages of a saved image (faster startup).
 
  This said, if VM implementors out there find easy ways to
  meet these constraints w/o burdening runtime or memory
  requirements, it could be an area for experimenting.
 
 
 This looks like it would be related to the stuff Sun has done with class data 
 sharing in the 1.5 JVMs:
 
 When the JRE is installed on 32-bit platforms using the Sun provided 
 installer, the installer loads a set of classes from the system jar file into 
 a private internal representation, and dumps that representation to a file, 
 called a shared archive. Class data sharing is not supported in Microsoft 
 Windows 95/98/ME. If the Sun JRE installer is not being used, this can be 
 done manually, as explained below. During subsequent JVM invocations, the 
 shared archive is memory-mapped in, saving the cost of loading those classes 
 and allowing much of the JVM's metadata for these classes to be shared among 
 multiple JVM processes. [1]
 
 This isn't quite the same as saving JIT'ed code, but it sounds like it is 
 saving the pre-parsed and verified class files.
 
 Nick
 
 [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
 
 
 IMPORTANT: This e-mail, including any attachments, may contain private or 
 confidential information. If you think you may not be the intended recipient, 
 or if you have received this e-mail in error, please contact the sender 
 immediately and delete all copies of this e-mail. If you are not the intended 
 recipient, you must not reproduce any part of this e-mail or disclose its 
 contents to any other party.
 This email represents the views of the individual sender, which do not 
 necessarily reflect those of education.au limited except where the sender 
 expressly states otherwise.
 It is your responsibility to scan this email and any files transmitted with 
 it for viruses or any other defects.
 education.au limited will not be liable for any loss, damage or consequence 
 caused directly or indirectly by this email.
 
 
 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Developing Harmony

On May 17, 2005, at 1:54 PM, Bryce Leo wrote:
Now don't go too crazy for my suggesting this, but why not pascal?
Wow.  I've never had such a strong urge to vote someone off the  
island :)

geir
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Gosling on Harmony

2005-05-17 Thread Ahmed Saad

The clear need that Magnusson cites is anything but clear to Gosling, who 
says Sun has received negative response from the enterprise development 
community regarding the idea of open-source Java.

welcome to the matrix, guys ;)

On 5/17/05, Tomer Barletz [EMAIL PROTECTED] wrote:
 
 http://www.devx.com/Java/Article/28125?trk=DXRSS_JAVA
 
 Looks like Doc java is pretty upset...

Re: Developing Harmony

2005-05-17 Thread Weldon Washburn

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 16, 2005 3:22 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Developing Harmony

On May 16, 2005, at 11:51 AM, Ben Laurie wrote:

 I'm pretty sure we want a framework in C/C++, whatever components  
 are developed in.

+1

If it's an either Java or C/C++ question, I would choose C/C++.  At
this point in time, I worry about the logistics of building a
productizable JVM written in Java.  For example, would we be able to
sort out the boot protocol of a JVM written in Java quick enough to
keep the attention of everyone currently interested in Harmony? 
Writing the JVM in Java might limit JVM components that could be
donated to Apache.  For example, it might not be possible to reuse the
code for a JIT or GC written in C/C++.

In the long term, it would be nice if we could define interfaces such
that Harmony could evolve into being written mostly in Java.  Perhaps
the interfaces between internal JVM components can be defined such
that a component can be written in Java or C/C++.  Perhaps a good
place to start is to define the JIT/VM interface such that a JIT can
be written in Java or C/C++.  Thoughts?

 Question to the floor: if it had to be one of C and C++, which  
 would you prefer?

C++

Oog. grunt Thog like to bang rocks, but Thog also like inheritance,  
ABCs and generics.

geir

-- 
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

RE: Testing - TCK, mauve, harmony's own test suite?

2005-05-17 Thread Nick Lothian


On the Pluto project (which has similar TCK requirements) the NDA hasn't
really been a big issue. Some committers have signed and have access to
it and some don't. We have our own set of test cases written based on
the spec that committers use to verify their commits. 

We just make sure someone runs the TCK before doing a release (which I
believe must be done on Apache owned hardware?). There are a few
oddities with reporting errors, though, since you can't publish the
actual test results, so you need to phrase your reports in terms of spec
violations.

I don't think you would be allowed to make the TCK available to people
who haven't signed, so an external interface isn't allowed.

I believe that on most Apache projects that require a TCK only a
minority of committers have access to the TCK. That is certainly the
case on Pluto and I believe that Tomcat works in a similar way.

Nick

 -Original Message-
 From: Ricky Clarkson [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, 17 May 2005 9:36 PM
 To: harmony-dev@incubator.apache.org
 Subject: Testing - TCK, mauve, harmony's own test suite?
 
 Hi,
 
 From informal chat in IRC, Davanum Srinivas (dims) said that 
 each committer (not contributor) will sign an NDA (Non-Disclosure
 Agreement) with Sun to be able to use Sun's TCK (Technology 
 Compatibility Kit), which is required for Harmony to be 
 certified as Java.
 
 He also said that each contributor (not committer) will be 
 able to test their patches against Harmony's own test cases 
 and against mauve.
 
 This would mean, I think, that Harmony/mauve would duplicate 
 Sun's TCK.
 
 First of all, it seems undesirable to duplicate Sun's TCK, 
 and it seems difficult to make sure that this is legal.
 
 If all the Harmony committers sign a Sun NDA, will that mean 
 that any test cases they write for Harmony or mauve will be 
 suspect, on IP (Intellectual Property) grounds?
 
 Perhaps it would be better if at least one Harmony committer 
 didn't sign the Sun NDA, then they wouldn't have anything to disclose.
 
 Further, it seems undesirable that a normal contributer (not
 committer) shouldn't be able to test their patches against 
 the TCK, which is what you'd expect the committers to do 
 before committing.
 
 Would it be possible/advisable to provide an interface to the 
 TCK that a normal developer could use, without the Sun NDA 
 (which I haven't
 read) being breached, e.g., a web page.  Even if that was 
 legal, technically it would be damn hard, because of security 
 considerations, etc.  Part of the 'etc' would be time; can 
 part of the TCK be run, rather than the whole thing?  I'd 
 imagine the answer would be yes, but the method to do it 
 might be laborious.
 
 Is the Sun NDA publically available, or is it subject to the 
 Sun NDA? ;)
 
 Is the TCK's own licence under review at all, i.e., will it 
 ever become free?
 
 While we're on a testing thread, what will Harmony's own test 
 suite/cases use/look like?
 


IMPORTANT: This e-mail, including any attachments, may contain private or 
confidential information. If you think you may not be the intended recipient, 
or if you have received this e-mail in error, please contact the sender 
immediately and delete all copies of this e-mail. If you are not the intended 
recipient, you must not reproduce any part of this e-mail or disclose its 
contents to any other party.
This email represents the views of the individual sender, which do not 
necessarily reflect those of education.au limited except where the sender 
expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it 
for viruses or any other defects.
education.au limited will not be liable for any loss, damage or consequence 
caused directly or indirectly by this email.

Re: Developing Harmony

C++, just C++, is a recipe for trouble. Most projects that use it define a
subset to make development a less painfull talk. Usually operator
overloading, templates and virtual inheritance are discarded.
Rodrigo
Agreed.  If the decision is to go with C++, it will need to be a subset of 
C++ for sanity.  I still think that, at most, a minimal C kernel and the 
rest in Java is a better option.

 As I said before, don't assume we're all Java fans here. I'm far more
 familiar with C++ than I am with Java.
snip

 Ben.
If you aren't a Java fan, why are you interested in Harmony?  Or am I 
misinterpreting what you meant there?

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Stop this framework/modularity madness!

2005-05-17 Thread Peter Donald

Steve Blackburn wrote:
However, it is not the either/or situtation you paint above.  I think 
it may make most sense to work on a preexisting donated VM or VMs 
while *concurrently* developing a new VM core or cores from scratch.  
This approach has a number of advantages, including maximizing our 
leverage from existing work, minimizing startup time and accelerating 
the process of building an existing VM.  It also allows us to more 
fruitfully explore some of the implementation choices (which language 
to use, ...).
FWIW there is precedent for that process happening at Apache. Tomcat3 
was largely donated by Sun and people hacked on that for a while until 
they understood how a newer shinier servlet container could be built. 
There was a bit more ruckus involved in this process than was strictly 
required but the community seems to have got back on track with tomcat5. 
Hopefully some of the old hat Apache peeps can help minimize the heat 
during harmonys evolution but this is definetly a good way to proceed IMHO.


The donated VM or VMs (if they araise) may already be at this point.  
As I have already said, this is a process already underway in the 
Jikes RVM project. 
excellent.
--
Cheers,
Peter Donald
Nothing changes your opinion of a friend so surely
as success - yours or his. - Franklin P. Jones

Re: Cross plaform issues

2005-05-17 Thread Garrett Rooney

Rodrigo Kumpera wrote:
A quick look at APR reveal that it doesn´t provide all OS abstraction that a 
JVM needs. There are no functions to mark pages as executable,
This is probably not there, but could be added to APR if people were 
interested and willing to write the code.

access to 
scalable IO facilities (IOCP, epoll, kqueue, etc...)
See the apr_pool API, which uses epoll, kqueue, etc on the backend if 
available.

or workarounds for 
small diferences on syscalls or libC implementation.
Uhh, that's what most of APR is...
Not that I'm saying APR should definately be used, but in the interests 
of accuracy...

-garrett

Re: Introduction, and a question

2005-05-17 Thread shudo

 Newbie question: What is to stop us from caching JITed code?  .NET/
 mono does this as far as I know?

We can do it even in the forthcoming Harmony runtime.

On the other hand, an apparent drawback is disk
consumption. Generally, JITted native code takes 3 times or more as
much as bytecode takes.

Another drawback is that the saved JITted code still needs symbol
resolution and the JIT compilers and loader of the saved native code
are complicated according to it.

It may be possible for the reused code to be optimized along runtime
information. But the Java runtime has to have such a feature to
judge a method is being executed or not.

  Kazuyuki Shudo[EMAIL PROTECTED]   http://www.shudo.net/

Re: impatient ;)

2005-05-17 Thread Ahmed Saad

how much value is there in creating another point of entry?

it's not just for devs who will be compiling the class library in harmony. 
it's (or that's what i think) intended to be the javac of Hamroy 

On 5/18/05, Matt Benson [EMAIL PROTECTED] wrote:
 
 just a note... it appears that Ant (and thus Maven, I
 assume) can already use the Eclipse JDT compiler when
 properly configured. If by chance one of these
 (Apache) projects is used for builds, how much value
 is there in creating another point of entry?
 
 -Matt
 
 
 --- Davanum Srinivas [EMAIL PROTECTED] wrote:
  go for it!
 
  -- dims
 
  On 5/16/05, Patrice Le Vexier
  [EMAIL PROTECTED] wrote:
here's a task for those of you who want
  something to do: wrap the
eclipse JDT compiler and make it look/feel like
  javac from the
command line.
   
--
Stefano.
   
   
  
   If there is no objection to use this compiler, I
  can do that.
  
   Please, let me know.
  
   patrice
  
 
 
  --
  Davanum Srinivas -
  http://webservices.apache.org/~dims/
 
 
 __
 Yahoo! Mail Mobile
 Take Yahoo! Mail with you! Check email on your mobile phone.
 http://mobile.yahoo.com/learn/mail

Re: Developing Harmony

2005-05-17 Thread Jónas Tryggvi Jóhannsson

Carlos Fernandez Sanz wrote:
Jónas Tryggvi Jóhannsson wrote:
Question to the floor: if it had to be one of C and C++, which would 
you prefer?
I can't think of a single reason why C should be preferred over C++.
C can simply be viewed as a subset of C++, and as Java users we all
This might be true for newbies but anyone who has used both knows that 
this assertion is very superficial.
Using C or C++ is, among other things, a design decision.
Well, beginner might be the magic word here!
I've had to dig into the Linux code a couple of times when doing 
research, and Linux is written in C in Object Oriented fashion. The 
Linux code is so obscure for newcomers that they really can't understand 
what is going on; all those function pointers that could be virtual 
functions in C++ and lack of abstraction really hinders the research 
community to participate in my opinion. (and more documentation would be 
nice.. a simple wiki updated function by function by the guys that 
implement them would be nice!)

In this project we really need the universities with us as they bring 
fresh ideas and it would be really useful if they could implement some 
of them! I feel that a couple of extra CPU cycles and memory should be 
sacrificed so that more people can participate in the project. It 
ensures that this project can keep up with new ideas, which in the end 
will result in better performance than C gives us. Because of that we 
should go with a more high level language.

I think that we should go the Java way.. and I really hope that JikesRVM 
will be our starting point!

As Mark Brooks says about implement the JVM in Java; Eating our own dog 
food has the benefit of forcing us to deal with optimization issues 
that we might otherwise sweep under the carpet.

But I guess the language will just depend on who donates a JVM.
- Jónas Tryggvi

Question re: Object Serialization?

2005-05-17 Thread Phillip Rhodes

Hey forgive the naive question guys, but does the Java serialization 
spec specify things to a level of detail that will allow objects
serialized on one JVM to be unserialized by a different JVM? That is,
will one be able to share objects between Harmony and the Sun JVM,
or others?

Just curious, as I haven't really heard much about this point. On the
surface it seems like you would expect this to just work but I wonder...
TTYL,
Phil
--
North Carolina - First In Freedom
Free America - Vote Libertarian
www.lp.org

Electrical Fire?

2005-05-17 Thread Phillip Rhodes

Haven't heard anybody mention this yet:
http://www.mozilla.org/projects/ef
Is there anything in EF that could be of use to us? I know the project 
has been dormant for quite some time, but I wonder if there is any code, 
or at least ideas, that would be beneficial to us?

Not sure about the licensing either. EF appears to be NPL
only, not triple-licensed like Mozilla.  Anybody know if the NPL
is Apache License compatible?
TTYL,
Phil
--
North Carolina - First In Freedom
Free America - Vote Libertarian
www.lp.org

Re: Cross plaform issues

2005-05-17 Thread vido

On Tue, May 17, 2005 at 05:56:36PM -0300, Rodrigo Kumpera wrote:
 A quick look at APR reveal that it doesn?t provide all OS abstraction that a 
 JVM needs. There are no functions to mark pages as executable, access to 
 scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for 
 small diferences on syscalls or libC implementation.
  I think Harmony should use autotools and some m4 magic to help with that.

Like the linux kernel source tree and the arch/ subtree ?

[arch] VM Candidate : JC @ http://jcvm.sourceforge.net/

For those that want meaningful subjects lines, here it is and for  
those that are waiting for an architecture discussion - here it is.

Here's the first of the offered VMs.  (I've privately mailed Tom van  
Dijck about mudGE so we can look at something else)

I've downloaded and will begin playing with today.  Archie, can you  
give a brief overview of structure?

Can we get some discussion about this from those that know about  
about VM architecture?

geir
On May 16, 2005, at 3:22 PM, Archie Cobbs wrote:
As mentioned before, and/all of JC [1] is available and I'll
be happy to relicense it. All of the code was written by me
(though I didn't invent all of the algorithms of course).
Some bits I can think of that may be useful, roughly ordered
from smaller and more likely to larger and less likely...
  - Splay tree implementation (splay.c)
  - String/UTF-8 functions (string.c, utf.c)
  - ZIP file reader (zip.c)
  - Class file parser (cf_parse.c)
  - Native local and global reference code (native_ref.c)
  - Per-classloader memory allocator (cl_alloc.c)
  - SableVM thin lock algorithm (lock.c)
  - Native library loader (native_lib.c)
  - VM Bootstrap code (vm.c, bootstrap.c)
  - JNI support (jni_invoke.c, jni_native.c)
  - Reflection support (reflect.c)
  - Dynamic invoker (invoke.c)
  - Threading support (thread.c)
  - Heap structure and garbage collector (heap.c, gc_root.c,  
gc_scan.c).
  - Bytecode interpreter (interp.c)
  - Class loading, derivation, and resolution (load2.c, derive2.c,
resolve.c)

There's also an ELF object loader and DWARF2 parser if you need  
those :-)

-Archie
[1] http://jcvm.sourceforge.net/
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: proposal translation

Add it to the wiki :)
http://wiki.apache.org/harmony/
thanks
On May 17, 2005, at 8:19 AM, Ozgur Akan wrote:
I am translating the proposal to Turkish. Whom shall I sent this  
and in which format ?

thanks,
aiQa
--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

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

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
[EMAIL PROTECTED]

Re: Developing Harmony