date:20050513

Can somebody comment on this guys claims,
[URL omitted to protect the innocent]
How about nobody comments?  I didn't see anything in that blog entry except 
bile from somebody whose accomplishments apparently consist of hurling dung 
at people that have accomplished something other than hurling dung.

Say that three times fast.
The web is full of asshats, misanthropes and social misfits with blogs.  The 
guy is an asshat.  Sending people to his website simply increases his page 
count and stokes his ego.  He has no points to address.  I didn't see any, 
anyway.

Don't worry about it.  Some people have envious natures, and will try to 
tear down those who do what they cannot or will not.  You don't worry about 
them.  They are dust; a waste of time better spent on something 
constructive.

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

Re: [

FaeLLe wrote:
Can somebody comment on this guys claims,
http://www.jroller.com/page/fate/20050507#death_to_apache
That's pretty funny, he should do more of those. Oh. He did.
Ps. warning: lot of flaming of our idealogies take place there but i would 
still like to see him shut up.
Why?
--
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: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Mohammed Al-Qaimari


It may seem a very odd idea but I believe that p[arts of the VM must be 
implemented at driver level to provide optimized solution for some bottlenecks 
in the hosting OS besides I agree that a larger part of the VM should be 
written C/C++. That's what people at Microsoft do for .NET platform.


There's NO Knowledge That is NOT POWER!
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Java Application Native Wrapper

2005-05-13 Thread Mohammed Al-Qaimari


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.


There's NO Knowledge That is NOT POWER!
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread 王在祥

I dont see any problem of writing the JIT in java. It looks very clearly, 
and even can be developed and debugged as a normal Java application.

Re: Against using Java to implement Java (Was: Java)

Mark Brooks wrote:
I hope you use C to write the VM for Harmony.

The chief objection I have to using C to write the VM is that it 
introduces a host of common errors and delays associated with using C or 
C++ for large products.  C is an excellent language for its purposes, 
but this isn't 1972.  Java was created to resolve a number of problems 
that arose from the ever-growing design of C++, which I swear is rapidly 
becoming the new PL/1.  We could use a restricted subset of C++ I guess, 
but a lot of "gee-whiz" features would have to be left out to assure 
cross-platform compatibility.  So why not use Java?
One of the reasons why not, from my POV, is because it runs so badly on 
most platforms. If you happen to use Windows, Solaris or Linux(? I 
don't, so I don't know) you may be happy developing in Java. Anywhere 
else, its a PITA.

I've tried to sell C++ in the ASF many times. Even back when it wasn't 
quite so bloated as it is now it wasn't a popular idea. Far fewer people 
can write C++ than C, and hardly any of those can write _good_ C++.

So, I think we'll end up back at C. As I've said before, I'd like to see 
a framework that _allows_ most of the VM to be run in Java (or Python, 
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.

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: [

2005-05-13 Thread Kev Jackson


http://www.jroller.com/page/fate/20050507#death_to_apache

That's pretty funny, he should do more of those. Oh. He did.
look at his site, he just rants and he attacks people in a funny way.  
look at the people/projects he attacks and then look at the comments.  
People I have a lot of respect for like this guy even after he's 
attacked them, he's obviously well known by most of the Java dev 
community, this is his hobby (ranting away about all and nothing), more 
power to him.  Even if he was a rabid anti-apache/anti-everything kind 
of person (it's obvious he isn't btw), then he would still have asked a 
legitimate question

Why do we need an open source Java?  For purists, we need it because we 
don't have it.  I just want to see what the community can come up with, 
and I'm sure he'll post more as the project progresses and I'm sure 
those will be funny too.

His writing style is ok too
Kev

Re: Against using Java to implement Java (Was: Java)

My point exactly, nothing has been decided, perhaps it's time to make some 
decisions
Agreed.
I read this as build a better VM than HotSpot under the APL, *and* write 
the class libraries.  I don't read this as take kaffe or JRVM or any other 
product and slap an Apache sticker and go faster stripes on it.  The 
proposal seems to be clear about writing from scratch if it isn't then my 
bad.
That was my original impression as well.  Besides, as a practical matter, 
rewriting an existing codebase doesn't necessarily save you time.  It can do 
the opposite, in fact, depending on the state of the codebase.  Maintaining 
somebody else's code is no picnic, and they might make assumptions in 
developing their own codebase that don't apply in your project.

So I suggest that, with regards to the VM at least, it should be our own 
cleanroom VM.  Really, Harmony is three projects.  First, we need a build 
environment.  Second, we need a conforming VM.  Third, we need a class 
library.  I suspect three will be the biggest issue.  The Java platform API 
is huge.

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

Re: Against using Java to implement Java (Was: Java)

One of the reasons why not, from my POV, is because it runs so badly on 
most platforms.
I can't comment on that.  I've used it on Solaris, Linux, and Windows.  
However, that is a VM issue, not a language issue.

I've tried to sell C++ in the ASF many times. Even back when it wasn't 
quite so bloated as it is now it wasn't a popular idea. Far fewer people 
can write C++ than C, and hardly any of those can write _good_ C++.
Agreed.
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

Mark Brooks wrote:
One of the reasons why not, from my POV, is because it runs so badly 
on most platforms.

I can't comment on that.  I've used it on Solaris, Linux, and Windows.  
However, that is a VM issue, not a language issue.
It doesn't matter where the problem lies, the point is that I can't 
develop on the platforms I need/want to develop on.

--
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: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Matthew French

Mark Brooks said:
> The chief objection I have to using C to write the VM is that it
> introduces a host of common errors and delays associated with
> using C or C++ for large products.  C is an excellent language
> for its purposes, but this isn't 1972.

Hmmm. First I would argue that a VM is not a big project. Extraordinarily
complex, yes. But not big.

Secondly, the common errors and problems related to C usually are the
result of pointers, memory management and complexity. But I don't see how
we can get away from these using Java. The whole point of using a VM is to
hide this functionality from the application, which means by definition we
have to implement it in the VM.

Then Bob said:
>>> IMHO both JITs and pre-compiling have their place.. it
>>> depends on the application whether one is definitely better
>>> than the other.
>
> This is a recipe for a bloated system that never works.

Agreed. Which is why we should try and avoid bloat. :)

But it seems to me the reason behind the wide range of alternate VM's is
because each of these has a specific niche to fill. If Harmony is intended
to bring these efforts together, then I would think that some "bloat" is
inevitable. Not performance bloat, mind you, just added complexity.

My hope is that by clamping down on this complexity early [did I mention
architecture? :) ] we will not only remove the bloat but make the task
even less complex than it is now. (FWIW: I am working on a document, but
it has taken on a life of its own. Hope to finish over the weekend)

> Also, most app
> programmers don't want to worry about the details of how their program
> is compiled.

This is dangerous territory: a person who does not know how their car
moves will eventually run out of petrol.

Java users, whether they like it or not, will eventually be confronted
with some implementation details. Our role should be to make such issues
transparent, not hide them. By doing so we would be reducing the time and
effort to resolve such issues.

This does not mean someone needs to read a 200 page tome just to run Java.
Hopefully the quick start guide will contain just one line...

Ben Laurie said:
> Mark Brooks wrote:
>>> I hope you use C to write the VM for Harmony.
>
> I've tried to sell C++ in the ASF many times. Even back when it wasn't
> quite so bloated as it is now it wasn't a popular idea. Far fewer people
> can write C++ than C, and hardly any of those can write _good_ C++.
>
> So, I think we'll end up back at C.

As much as I like C++, I would have to agree that C should be the default.

But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.

> As I've said before, I'd like to see
> a framework that _allows_ most of the VM to be run in Java (or Python,
> or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.

The bulk of a Java environment is the API/libraries. I would like to see
the  libraries written in Java as much as possible. For example, LDAP
functionality can be written entirely in Java. You just need to talk the
right binary language.

Same applies to parts of the maths API like BigDecimal, date functionality
(except some cases like getting the system date), XML classes, the bulk of
the IO classes, etc. We should rely on the VM to optimise the Java code -
I see no reason why an efficient VM cannot match C code or assembler in
most cases.

There are exceptions: for example, advanced maths like sin() or a bulk
block copy will perform much better using hardware. Even then, I think it
could be useful to have implementations of these functions written in
Java, and the ability to override them.

How is Classpath done? Is the bulk of the code implemented in C and
wrapped in Java? Or is it Java with a thin C api?

- Matthew

Re: Harmony may provide a more general VM than JVM

2005-05-13 Thread Steve Heath

won't that all be a little complicated? The JVM runs bytecode, not
Java itself. Isn't there an equivalent for .Net too? I don't know
about languages such as Smalltalk, but I think their standard is the
language itself, it's up to the interpreter to deal with it from
there. I suspect will suggest we need a

Given the gulf between the structures of these languages and bytecode
systems, is this thread suggesting a completely generic VM and having
some kinda translator to move from bytecodes to Harmony-codes?

On 5/13/05, 王在祥 <[EMAIL PROTECTED]> wrote:
> Agree.
> 
> 2005/5/12, Stefano Mazzocchi <[EMAIL PROTECTED]>:
> >
> > 王在祥 wrote:
> > > Harmony is focus on provide a Tiger compatible JVM, but i think it is
> > > possible to make it more general for other language such as .NET,
> > Haskell,
> > > Smalltalk etc.
> > >
> > > the Harmony VM may define such a VM core, such as memory management,
> > multi
> > > thread support, object layout etc, that is general for most VM. also, it
> > can
> > > define a bytecode of itself as its native bytecode. then other bytecode
> > can
> > > be translate to the general bytecode and then JITed.
> >
> > First things first. Writing a java JVM is a hard enough task. We'll see
> > what happens after we reach that goal.
> >
> > --
> > Stefano.
> >
> >
>

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Panagiotis Astithas

Ben Laurie wrote:
Mark Brooks wrote:
One of the reasons why not, from my POV, is because it runs so badly 
on most platforms.

I can't comment on that.  I've used it on Solaris, Linux, and 
Windows.  However, that is a VM issue, not a language issue.

It doesn't matter where the problem lies, the point is that I can't 
develop on the platforms I need/want to develop on.
Is it fair to assume that the problems you would be facing stem from the 
unavailability of the Sun JDK for your preferred platform? In that case 
if a Harmony build could be bootstrapped using gcj/kaffe/jcvm/JikesRVM 
you would be a happy camper, right?

Cheers,
Panagiotis
--
Panagiotis Astithas, PhD
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

Re: JIT vs. WAT

2005-05-13 Thread Panagiotis Astithas

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

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Steve Heath

Isn't it a good idea to write the first implementation in a functional
programming language (read the wizard book)? That's what these
platforms are designed for and the constructs are there to help in
designing the thing. Then when you're happy you know what's good and
bad you can re-code it in something that actually runs fast. I'm aware
of a reasonable amount of literature that talks about GC and
interpretation techniques that uses languages such as ML and Scheme.

Compiled Java initially seems as good as anything, but don't those
compilers add in their own brand of GC? Wouldn't that be an overhead
we neiter need nor want? Do we want to generate our own native
compiler? I'm thinking the best native compiler/language to use is
probably C.

I agree that most of the libraries can be written in Java, but
wouldn't that constitute a separate apache project, just like GNU
Classpath? The VM should probably be as clean as a very clean thing...
in a clean room.. (hence why I never mentioned C++ :)

On 5/13/05, Matthew French <[EMAIL PROTECTED]> wrote:
> Mark Brooks said:
> > The chief objection I have to using C to write the VM is that it
> > introduces a host of common errors and delays associated with
> > using C or C++ for large products.  C is an excellent language
> > for its purposes, but this isn't 1972.
> 
> Hmmm. First I would argue that a VM is not a big project. Extraordinarily
> complex, yes. But not big.
> 
> Secondly, the common errors and problems related to C usually are the
> result of pointers, memory management and complexity. But I don't see how
> we can get away from these using Java. The whole point of using a VM is to
> hide this functionality from the application, which means by definition we
> have to implement it in the VM.
> 
> Then Bob said:
> >>> IMHO both JITs and pre-compiling have their place.. it
> >>> depends on the application whether one is definitely better
> >>> than the other.
> >
> > This is a recipe for a bloated system that never works.
> 
> Agreed. Which is why we should try and avoid bloat. :)
> 
> But it seems to me the reason behind the wide range of alternate VM's is
> because each of these has a specific niche to fill. If Harmony is intended
> to bring these efforts together, then I would think that some "bloat" is
> inevitable. Not performance bloat, mind you, just added complexity.
> 
> My hope is that by clamping down on this complexity early [did I mention
> architecture? :) ] we will not only remove the bloat but make the task
> even less complex than it is now. (FWIW: I am working on a document, but
> it has taken on a life of its own. Hope to finish over the weekend)
> 
> > Also, most app
> > programmers don't want to worry about the details of how their program
> > is compiled.
> 
> This is dangerous territory: a person who does not know how their car
> moves will eventually run out of petrol.
> 
> Java users, whether they like it or not, will eventually be confronted
> with some implementation details. Our role should be to make such issues
> transparent, not hide them. By doing so we would be reducing the time and
> effort to resolve such issues.
> 
> This does not mean someone needs to read a 200 page tome just to run Java.
> Hopefully the quick start guide will contain just one line...
> 
> Ben Laurie said:
> > Mark Brooks wrote:
> >>> I hope you use C to write the VM for Harmony.
> >
> > I've tried to sell C++ in the ASF many times. Even back when it wasn't
> > quite so bloated as it is now it wasn't a popular idea. Far fewer people
> > can write C++ than C, and hardly any of those can write _good_ C++.
> >
> > So, I think we'll end up back at C.
> 
> As much as I like C++, I would have to agree that C should be the default.
> 
> But I am still thinking that we can make it so that we have a choice of
> multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
> or whatever other language takes the authors fancy. I can see many valid
> reasons why we would want to do this, but the trick is getting it to work
> without adding enormous complexity.
> 
> > As I've said before, I'd like to see
> > a framework that _allows_ most of the VM to be run in Java (or Python,
> > or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
> 
> The bulk of a Java environment is the API/libraries. I would like to see
> the  libraries written in Java as much as possible. For example, LDAP
> functionality can be written entirely in Java. You just need to talk the
> right binary language.
> 
> Same applies to parts of the maths API like BigDecimal, date functionality
> (except some cases like getting the system date), XML classes, the bulk of
> the IO classes, etc. We should rely on the VM to optimise the Java code -
> I see no reason why an efficient VM cannot match C code or assembler in
> most cases.
> 
> There are exceptions: for example, advanced maths like sin() or a bulk
> block copy will perform much better using hardware. Even then, I

Re: Developing Harmony

2005-05-13 Thread Panagiotis Astithas

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)
 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
Could we interpret this as a positive response to Davanum Srinivas's 
request for a JVM donation to the project?

   b) Another very different VM (kaffe?)
 . amenable to modularization
 . amenable to other components (drop in MMTk?)
Of all the options presented so far, what I find most appealing is the 
combination of a VM in Java (like JikesRVM) and a WAT approach like gcj 
or jcvm. In a sense that Harmony could enable either usage scenario, 
more or less like gcj does now. Would you think that MMTk could be used 
in say jcvm? Archie, would that make sense?

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

Re: Native Calls?

2005-05-13 Thread Steven Martin

No obviously have stacktrace.  Sun's implementation uses native calls
instead of 100% Java.


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

Third Way - implement the JVM in a new C/Java hybrid

2005-05-13 Thread David Griffiths

No, but seriously. :) I agree that C sucks as a JVM implementation
language for lots of reasons: the Java/C impedance mismatch, the lack
of ability to aggressively inline (which will be a big issue if you
every try to achieve real modularity), poor trace/debug/profiling
ability (wouldn't it be nice to have a coherent view of where your
time was being spent?).

The idea of implementing it in Java sounds nice except for all the
tricks you have to do to get round the infinite recursion problem.

So why not invent a new language that is a kind of half way house
between C and Java? It will be dynamically compiled just like Java but
won't come with a lot of the other stuff like GC and threading.
Instead it will have raw access to the platform system calls. Plus
some kind of support for C style memory pointers. The same compilation
engine would compile both the JVM parts written in this language plus
suitable converted Java bytecode.

I don't think inventing the language and writing a parser for it is
the hard part (it's pretty much Java-- with a dash of C), the hard
part is doing the optimising back-ends for all the different
platforms. But you've got to do that anyway unless you go the GCJ
route.

If it's possible to write a JVM in Java (as has been demonstrated)
then it's surely even easier to implement it in a purpose built
language. Such a language might have other system programming type
uses. Lots of existing JNI code could be converted to it.

Well that's just another thought in case you were in danger of
reaching a consensus. :)

Cheers,

Dave

Re: Third Way - implement the JVM in a new C/Java hybrid

2005-05-13 Thread Bob

So why not invent a new language that is a kind of half way house
between C and Java?
I think that GCJ gives you this "third way" already.  And it comes with 
a GC, which once explicitly managed, could be used as the Harmony GC as 
well.  (GCJ's GC has an older pedigree, I believe).

Re: Against using Java to implement Java (Was: Java)

Matthew French wrote:
Ben Laurie said:
Mark Brooks wrote:
I hope you use C to write the VM for Harmony.
I've tried to sell C++ in the ASF many times. Even back when it wasn't
quite so bloated as it is now it wasn't a popular idea. Far fewer people
can write C++ than C, and hardly any of those can write _good_ C++.
So, I think we'll end up back at C.

As much as I like C++, I would have to agree that C should be the default.
But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.

As I've said before, I'd like to see
a framework that _allows_ most of the VM to be run in Java (or Python,
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
The bulk of a Java environment is the API/libraries. I would like to see
the  libraries written in Java as much as possible. For example, LDAP
functionality can be written entirely in Java. You just need to talk the
right binary language.
I'm not arguing with that, I'm talking about the VM, not the libraries.
Same applies to parts of the maths API like BigDecimal, date functionality
(except some cases like getting the system date), XML classes, the bulk of
the IO classes, etc. We should rely on the VM to optimise the Java code -
I see no reason why an efficient VM cannot match C code or assembler in
most cases.
There are exceptions: for example, advanced maths like sin() or a bulk
block copy will perform much better using hardware. Even then, I think it
could be useful to have implementations of these functions written in
Java, and the ability to override them.
BigDecimal is an exception, too, if you want to do serious crypto. So is 
all the rest of the crypto.

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: Developing Harmony

Added your thoughts to wiki - http://wiki.apache.org/harmony

thanks,
dims

On 5/13/05, Steve Blackburn <[EMAIL PROTECTED]> 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)
> 
>   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
> 
> 


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

Re: Java Application Native Wrapper

Yes native .EXE should be a MUST :D

On 5/13/05, Mohammed Al-Qaimari <[EMAIL PROTECTED]> 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.
> 
> 
> There's NO Knowledge That is NOT POWER!
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 



-- 
www.FaeLLe.com

RE: Java Application Native Wrapper

2005-05-13 Thread Sarose Joshi

Well this intend to be another application that crash and bring more
vulnerabilities. This is against the central themes of the java. 

-Original Message-
From: FaeLLe [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 13, 2005 5:34 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Java Application Native Wrapper

Yes native .EXE should be a MUST :D

On 5/13/05, Mohammed Al-Qaimari <[EMAIL PROTECTED]> 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.
> 
> 
> There's NO Knowledge That is NOT POWER!
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 



-- 
www.FaeLLe.com

Re: Java Application Native Wrapper

2005-05-13 Thread Bob

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.

-- Bob

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Dalibor Topic

Matthew French wrote:
But I am still thinking that we can make it so that we have a choice of
multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
or whatever other language takes the authors fancy. I can see many valid
reasons why we would want to do this, but the trick is getting it to work
without adding enormous complexity.
What worked well for GNU Classpath, and in my opinion helped the 
cambrian explosion of free runtimes happen, that we witnessed within GNU 
Classpath in the last two years, was to use Java for the interfaces, and 
let the VMs do their own marshalling to whatever language they use 
internally.

I'd be interested in hearing more from Steve on how well that works 
within JikesRVM. From reading some papers on the web, it seems that the 
MMTk has been ported to other, non-Java runtimes as well, and I guess 
that this binding-vm-components-via-java-interfaces problem has been 
efficiently solved by other bright people already outside the 
pure-java-runtime space.

How is Classpath done? Is the bulk of the code implemented in C and
wrapped in Java? Or is it Java with a thin C api?
The bulk is written in Java. The largest chunk of C in classpath is 
fdlibm, I believe, which should be eventually kicked out and replaced by 
VM interfaces to let the VMs optimize Math.*() operations internally any 
way they want without having to maintiain their separate copy of 
java.lang.Math.

cheers,
dalibor topic

Re: Third Way - implement the JVM in a new C/Java hybrid

2005-05-13 Thread David Griffiths

I thought GCJ was a static compilation system? What I was thinking of
was fully dynamic JIT-style compilation. A lot of the problems with
using C as the implementation language stem from it's statically
compiled nature. Not to mention the craziness of having
platform-specific code generation and optimisation duplicated in both
the C compiler and the Java JIT. (Which admittedly GCJ avoids).

Cheers,

Dave

On 5/13/05, Bob <[EMAIL PROTECTED]> wrote:
> >
> > So why not invent a new language that is a kind of half way house
> > between C and Java?
> 
> I think that GCJ gives you this "third way" already.  And it comes with
> a GC, which once explicitly managed, could be used as the Harmony GC as
> well.  (GCJ's GC has an older pedigree, I believe).
> 
>

Where is Geir Magnusson?

So the Geir made a .gif picture and seems like
everybody said 'go go Geir'.
So Geir, what are your thoughts on the subject?
Are you still alive or what?
Regards,
Mladen

Re: Third Way - implement the JVM in a new C/Java hybrid

2005-05-13 Thread Steve Heath

I hadn't thought that to write a JIT compiler you're writing a native
compiler for Java anyway, so you might as well use this to create your
VM, obvious really!

There's a certain beauty to creating the VM in the language it is
there to interpret.

It does suggest we want to write the JIT first, then use this as our
compiler for generating the VM..?

On 5/13/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> I thought GCJ was a static compilation system? What I was thinking of
> was fully dynamic JIT-style compilation. A lot of the problems with
> using C as the implementation language stem from it's statically
> compiled nature. Not to mention the craziness of having
> platform-specific code generation and optimisation duplicated in both
> the C compiler and the Java JIT. (Which admittedly GCJ avoids).
> 
> Cheers,
> 
> Dave
> 
> On 5/13/05, Bob <[EMAIL PROTECTED]> wrote:
> > >
> > > So why not invent a new language that is a kind of half way house
> > > between C and Java?
> >
> > I think that GCJ gives you this "third way" already.  And it comes with
> > a GC, which once explicitly managed, could be used as the Harmony GC as
> > well.  (GCJ's GC has an older pedigree, I believe).
> >
> >
>

Re: Third Way - implement the JVM in a new C/Java hybrid

2005-05-13 Thread Anthony Green

On Fri, 2005-05-13 at 14:25 +0100, David Griffiths wrote:
> I thought GCJ was a static compilation system? 

Not quite.  GCJ is an ahead-of-time (AOT) compiler for the Java
programming language.  However, the GCJ runtime execution environment
supports all of the dynamic properties of the Java programming language
(run-time loading/linking/verification, reflection, all of the binary-
compatibility rules, etc) for both bytecode and AOT compiled code.

AG

Re: Third Way - implement the JVM in a new C/Java hybrid

2005-05-13 Thread Mohammed Nour

On 5/13/05, Steve Heath <[EMAIL PROTECTED]> wrote:
> I hadn't thought that to write a JIT compiler you're writing a native
> compiler for Java anyway, so you might as well use this to create your
> VM, obvious really!
> 
> There's a certain beauty to creating the VM in the language it is
> there to interpret.
> 
> It does suggest we want to write the JIT first, then use this as our
> compiler for generating the VM..?
> 
> On 5/13/05, David Griffiths <[EMAIL PROTECTED]> wrote:
> > I thought GCJ was a static compilation system? What I was thinking of
> > was fully dynamic JIT-style compilation. A lot of the problems with
> > using C as the implementation language stem from it's statically
> > compiled nature. Not to mention the craziness of having
> > platform-specific code generation and optimisation duplicated in both
> > the C compiler and the Java JIT. (Which admittedly GCJ avoids).
> >
> > Cheers,
> >
> > Dave
> >
> > On 5/13/05, Bob <[EMAIL PROTECTED]> wrote:
> > > >
> > > > So why not invent a new language that is a kind of half way house
> > > > between C and Java?

This kind of language already exists, it is called the "D" language. I
dont know much about it but it has very nice features that are
combined from C\C++ and JAVA.

But the idea of implementing the JIT in JAVA sounds much more interesting.

> > >
> > > I think that GCJ gives you this "third way" already.  And it comes with
> > > a GC, which once explicitly managed, could be used as the Harmony GC as
> > > well.  (GCJ's GC has an older pedigree, I believe).
> > >
> > >
> >
>

Re: Where is Geir Magnusson?

was alive & kicking a few mins back :) talked to him on IRC and over
the phone :) :)

-- dims

On 5/13/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> So the Geir made a .gif picture and seems like
> everybody said 'go go Geir'.
> 
> So Geir, what are your thoughts on the subject?
> Are you still alive or what?
> 
> Regards,
> Mladen
> 
> 


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

Re: Where is Geir Magnusson?

Davanum Srinivas wrote:
was alive & kicking a few mins back :) talked to him on IRC and over
the phone :) :)
Well, I was just wondering if he is still counting
those 100 Mils IMB payed him for Geronimo ;)
Regards,
Mladen.

Re: Developing Harmony

2005-05-13 Thread Archie Cobbs

Panagiotis Astithas wrote:
   b) Another very different VM (kaffe?)
 . amenable to modularization
 . amenable to other components (drop in MMTk?)
Of all the options presented so far, what I find most appealing is the 
combination of a VM in Java (like JikesRVM) and a WAT approach like gcj 
or jcvm. In a sense that Harmony could enable either usage scenario, 
more or less like gcj does now. Would you think that MMTk could be used 
in say jcvm? Archie, would that make sense?
Sure.. like someone pointed out, there are already lots of JVM cores
that fill various niches. So one of Harmony's possible strengths could
be its modularity & flexibility. Obviously, it would mean it's not the
fastest VM in every scenario (no VM is) but on the other hand it would
probably end up being the most popular anyway.
In any case, the VM core is only one piece of the puzzle, and if
Classpath is going to be used, then the entire core is basically
going to be swappable anyway. This would be a good thing :-)
The big quantity of work lies in (further) developing the
class libraries...
-Archie
__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

Help about IRC

2005-05-13 Thread Mohammed Nour

I need to know which IRC channel I shold look into ?

Best regards...

Re: Help about IRC

2005-05-13 Thread Berlin Brown

It is on "freenode.net" and mainly on #harmony with similar channels
on #kaffe and #classpath.



On 5/13/05, Mohammed Nour <[EMAIL PROTECTED]> wrote:
> I need to know which IRC channel I shold look into ?
> 
> Best regards...
>

Re: Where is Geir Magnusson?

On May 13, 2005, at 9:49 AM, Mladen Turk wrote:
So the Geir made a .gif picture and seems like
everybody said 'go go Geir'.
So Geir, what are your thoughts on the subject?
Are you still alive or what?
LOL.
Sorry - my company was acquired in the last week, and I had lots of  
responsibilities related to that.  I'm back now (today) and slowing  
digging my way out of this avalanche.  Stay tuned :)

geir
Regards,
Mladen

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

Re: Where is Geir Magnusson?

On May 13, 2005, at 10:14 AM, Mladen Turk wrote:
Davanum Srinivas wrote:
was alive & kicking a few mins back :) talked to him on IRC and over
the phone :) :)
Well, I was just wondering if he is still counting
those 100 Mils IMB payed him for Geronimo ;)
ROTFL.  Please.
They purchased my company, Gluecode Software. Lets keep the two  
worlds apart.  I certainly do.

geir
Regards,
Mladen.

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

The topic of the Java Compiler

2005-05-13 Thread Berlin Brown

The compiler seems to be a non-issue at this time with a focus on the
JavaVM.  What are your thoughts on the different compilers?  I will
throw my hat in and say that I wish you guys would decide against GCJ
or GCC connected system.  Everyone loves GCC and their hard work, but
I think their are way too many dependencies when it comes to GCC and
it is obviously more complex than something like jikes or
fill-in-the-blank with your favorite java compiler.

Any thoughts on this?  I could be wrong.

Re: Where is Geir Magnusson?

Geir Magnusson Jr. wrote:
On May 13, 2005, at 10:14 AM, Mladen Turk wrote:
Davanum Srinivas wrote:
was alive & kicking a few mins back :) talked to him on IRC and over
the phone :) :)
Well, I was just wondering if he is still counting
those 100 Mils IMB payed him for Geronimo ;)
ROTFL.  Please.
They purchased my company, Gluecode Software. Lets keep the two  worlds 
apart.  I certainly do.

My question was: What are you thoughts on Harmony, since we haerd
nothing from you since all tohose GNU/ASF licensing.
Mladen.

Re: Help about IRC

2005-05-13 Thread Dalibor Topic

Mohammed Nour wrote:
I need to know which IRC channel I shold look into ?
Hi Mohammed,
try the #harmony channel on irc.freenode.org
cheers,
dalibor topic

[I am deluged by harmony-dev email so forgive me if I cannot cite and respond
to individuals, er, individually]
Writing a VM from scratch? Making it a generic VM with it's OWN bytecode set?
Inventing a new language!?
Hold on.
I don't think this project has much chance of success at all unless it embraces the existing
communities of talented and dedicated developers that have already spent YEARS pouring effort into
existing projects. I think rewriting from scratch is a total non-starter. It's just going to
alienate the very communities which are the only fuel this project has. I don't think it is at all
"clear" in the proposal that Harmony should write everything from scratch ("We will
create directly, via inclusion of independent third-party code, or through contribution").
Instead of armchair opinions on VM architecture by idle onlookers (which includes me), I would much
rather hear from members of the communities already mentioned (and I know many have already
spoken), on what *they* would like out of the project. I think the best idea is to come to a
compromise, or middle ground (perhaps manifested by some initial set of interfaces, and donated
implementations of those interfaces), that a
ll parties can accept and work towards. In such a large project as this, I
think the limiting factor is not great ideas, or even skilled individual
coders, but community interest and devotion, and we really have to harness the
existing interest and talent out there. With such a community we can always
fix a less-than-optimal initial implementation...but without it we are going
nowhere. Even if Harmony doesn't produce one line of original code (I doubt
that will be the case anyway), I think it would be immensely useful to at least
unite the existing projects, and give them a common direction. From the links
I've followed so far, I am very impressed with the progress GCJ, Classpath,
Kaffe, and other have made, and the fact that I was not even aware of this
progress, despite having done Java development for years, I think indicates
that Harmony certainly has a large potential role to play in advocacy.
The only clear thing I see at this point is:
* Classpath should be used as the class library.
Does anybody disagree that reusing this code base is the only feasible way to
move forward? I think having to rewrite the class library from scratch would
set us back years, so hopefully that is off the table. It looks like both
parties involved are, or will be soon, coming to an amicable legal resolution,
so hopefully this is a moot issue.
I am sure discussions are happening in parallel between various projects
(especially because this list is so noisy). Hopefully we can come to some sort
of middle ground that is acceptable by all parties, and takes advantage of all
the work already done.
There already appears to be cooperation between GCJ, Kaffe, and Classpath, including
various forks thereof. Can the VM parts of GCJ and Kaffe be reconciled, or modularized
based on common interfaces? What are the fourth, fifth, and sixth largest free Java
efforts, if that can even be quantified? Are the JikesRVM architecture decisions
incompatible with GCJ and Kaffe design? Besides the class library, what portions of
existing implementations are those projects willing to "give up" to a third
party?
Aaron Hamid

class file reader

Are there existing ASL/BSD/PD liscened sources for reading Java class files?
Thank you,
-Andy
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.

Re: class file reader

java source files? or .class files?

On 5/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Are there existing ASL/BSD/PD liscened sources for reading Java class files?
> 
> Thank you,
> 
> -Andy
> --
> 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.
> 


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

Re: Where is Geir Magnusson?

Mladen Turk wrote:
Geir Magnusson Jr. wrote:
Well, I was just wondering if he is still counting
those 100 Mils IMB payed him for Geronimo ;)
They purchased my company, Gluecode Software. Lets keep the two  
worlds apart.  I certainly do.

My question was: What are you thoughts on Harmony, since we haerd
nothing from you since all tohose GNU/ASF licensing.

Also, the Sun gave a statement that you will speak about Harmony this
summer, so I just wonder what you will be speaking about?
Is the Harmony already defined project or you will be speaking
on your personal vison?
Please give us some ansvers. The discussion is going nowhere thought.
Are we ASF or ASF/GNU/Kaffe/Whatever/* project?
Regards,
Mladen.

Re: Where is Geir Magnusson?

Mladen,

Can you please join the IRC? then we can summarize what we talked to the lsit.

thanks,
dims

On 5/13/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Mladen Turk wrote:
> > Geir Magnusson Jr. wrote:
> >>> Well, I was just wondering if he is still counting
> >>> those 100 Mils IMB payed him for Geronimo ;)
> >> They purchased my company, Gluecode Software. Lets keep the two
> >> worlds apart.  I certainly do.
> >>
> >
> > My question was: What are you thoughts on Harmony, since we haerd
> > nothing from you since all tohose GNU/ASF licensing.
> >
> 
> 
> Also, the Sun gave a statement that you will speak about Harmony this
> summer, so I just wonder what you will be speaking about?
> 
> Is the Harmony already defined project or you will be speaking
> on your personal vison?
> 
> Please give us some ansvers. The discussion is going nowhere thought.
> Are we ASF or ASF/GNU/Kaffe/Whatever/* project?
> 
> Regards,
> Mladen.
> 


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

Re: class file reader

class files.
Davanum Srinivas wrote:
java source files? or .class files?
On 5/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
 

Are there existing ASL/BSD/PD liscened sources for reading Java class files?
Thank you,
-Andy
--
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.
   


 


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

Re: class file reader

http://jakarta.apache.org/bcel/
http://cglib.sourceforge.net/
http://forge.objectweb.org/projects/asm
http://serp.sourceforge.net/

On 5/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> class files.
> 
> Davanum Srinivas wrote:
> 
> >java source files? or .class files?
> >
> >On 5/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Are there existing ASL/BSD/PD liscened sources for reading Java class files?
> >>
> >>Thank you,
> >>
> >>-Andy
> >>--
> >>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.
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 
> --
> 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.
> 
> 


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

Sending native code to the processor at runtime

It has been a considerable time since I did programming at that level 
but can someone tell me how:

If you are running code, generate some binary code, how do you schedule 
it to run on the processor (and preferably in an unbounded way).  I 
believe IIRC you can copy it into the code segment.   Can someone point 
me to a good reference or better yet some reasonably well written source 
which does this?

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

Re: Where is Geir Magnusson?

Davanum Srinivas wrote:
Mladen,
Can you please join the IRC? then we can summarize what we talked to the lsit.
Perhaps I could if I would know how to join ;)
Since I'm the ASF member from the times when the things like IRC did
not exist at all, I see no purpose why.
I can either speak in public or not at all.
You can eventually find me on Skype:
callto://mladenturk

Regards,
Mladen.

Re: Where is Geir Magnusson?

2005-05-13 Thread Santiago Gala

El vie, 13-05-2005 a las 17:16 +0200, Mladen Turk escribiÃ:
> Perhaps I could if I would know how to join ;)

Pick up your favorite IRC client (gaim works for me, YMMV), select
irc.freenode.net as server and 6667 as port...

If you use mozilla or firefox and have chatzilla installed clicking on
irc://irc.freenode.net/#harmony should do.

> Since I'm the ASF member from the times when the things like IRC did
> not exist at all, I see no purpose why.

IRC predates the ASF by several years. Undernet (one of the IRC
networks) is there since 1992, for instance.

Regards
-- 
Santiago Gala <[EMAIL PROTECTED]>
High Sierra Technology, SLU


signature.asc
Description: This is a digitally signed message part

Re: class file reader

2005-05-13 Thread Stephan Michels

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.

Re: Where is Geir Magnusson?

Santiago Gala wrote:

Since I'm the ASF member from the times when the things like IRC did
not exist at all, I see no purpose why.
IRC predates the ASF by several years. Undernet (one of the IRC
networks) is there since 1992, for instance.
Sorry, for being conservative :)
I simply see no point to use the IRC. Something like that can
only rise my stress level. I even did not have a mobile phone
until to the last year.
Email is still fine by me.
Regards,
Mladen.

Re: Where is Geir Magnusson?

2005-05-13 Thread Jeremy Boynes

Davanum Srinivas wrote:
Mladen,
Can you please join the IRC? then we can summarize what we talked to the lsit.
Please, please don't put all the traffic on IRC. There are many many 
people interested in Harmony who do not have the bandwidth to sit there 
and despite best intentions summaries don't get posted often enough.

IMO using IRC too heavily too early has led to lingering community 
issues in Geronimo - please don't repeat that.

--
Jeremy

Re: Developing Harmony

Panagiotis,

MMTk is being used in SableVM (i think!)

-- dims

On 5/13/05, Panagiotis Astithas <[EMAIL PROTECTED]> wrote:
> 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)
> >
> >  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
> 
> Could we interpret this as a positive response to Davanum Srinivas's
> request for a JVM donation to the project?
> 
> >b) Another very different VM (kaffe?)
> >  . amenable to modularization
> >  . amenable to other components (drop in MMTk?)
> 
> Of all the options presented so far, what I find most appealing is the
> combination of a VM in Java (like JikesRVM) and a WAT approach like gcj
> or jcvm. In a sense that Harmony could enable either usage scenario,
> more or less like gcj does now. Would you think that MMTk could be used
> in say jcvm? Archie, would that make sense?
> 
> > 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
> 
> 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/

Two seeds (Re: Developing Harmony)

Steve,

This is great!!! I love the idea of using JikesRVM and one another JVM
(hey SableVM already uses MMTk, Kaffe's license is too difficult -
though not impossible - to change because TransVirtual is no more).

thanks,
dims

On 5/13/05, Steve Blackburn <[EMAIL PROTECTED]> 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)
> 
>   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
> 
> 


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

Re: Sending native code to the processor at runtime

Andy,

check the wiki. there are some papers of interest.

-- dims

On 5/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It has been a considerable time since I did programming at that level
> but can someone tell me how:
> 
> If you are running code, generate some binary code, how do you schedule
> it to run on the processor (and preferably in an unbounded way).  I
> believe IIRC you can copy it into the code segment.   Can someone point
> me to a good reference or better yet some reasonably well written source
> which does this?
> 
> Thank you very much.
> 
> -andy
> --
> 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.
> 


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

Re: Where is Geir Magnusson?

Mladen,

I have tried to keep the wiki up-to-date on stuff happening on the
mailing list and on IRC (get any IRC client and point to
irc.freenode.net and select channel #harmony)

I have no idea on what personally geir/sun are up-to and what geir's
plans are about public-speaking etc. that is not relevant to what's
happening here on harmony-dev.

If you find the wiki out of date from the stuff on the mailing lists,
please update the wiki or point me to the missing piece (like
yesterday i added JCVM contrib to the wiki).

If you ask specific questions about the project and what has already
been discussed, i will be happy to help.

thanks,
dims

On 5/13/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > Mladen,
> >
> > Can you please join the IRC? then we can summarize what we talked to the 
> > lsit.
> >
> 
> Perhaps I could if I would know how to join ;)
> Since I'm the ASF member from the times when the things like IRC did
> not exist at all, I see no purpose why.
> 
> I can either speak in public or not at all.
> You can eventually find me on Skype:
> callto://mladenturk
> 
> 
> 
> Regards,
> Mladen.
> 
> 

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

Re: IRC channel (s)

thanks Ben. i got the same feedback from Justin. But since we got this
rolling, let's stick to #harmony.

On 5/11/05, Ben Laurie <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > FYI,
> >
> > #classpath on irc.freenode.net
> > #kaffe on irc.freenode.net
> > #harmony on irc.freenode.net (started a minute back)
> 
> Oops. I'll shut down #apache-harmony, then!
> 
> --
> 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
> 


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

Wiki

Not sure if it is the right tool...but here it is:
http://wiki.apache.org/harmony/

Maybe we should start with a list of the sub-systems and components
drawing from existing JikesRVM and Classpath stuff.

thanks,
dims

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

Programmer Volunteering (sorry if I should read a FAQ before)

2005-05-13 Thread Nilseu Padilha JMiB

Greetings.

I am a cmomercial Systems Architect and would like to volunteer myself as a 
developer to the Harmony  Project. Sorry if I should read any FAQ before, but I 
like to know how I could contribute to the project.

Thank you.

Regards,

http://www.immediate.com.br";
association="Association for Computing Machinery - ACM"
education="Bachelor\'s in Computer Science - ULBRA"
>

And one more thing, what you choose to call hell, he calls home.


Oganza bi sasa!


Computer science is no more about computers than astronomy is about telescopes.


Son of Jor-el, kneel before Zod


We reject kings, presidents and voting. We believe in rough consensus and 
running code.


A minority of input produces the majority of results.


You\'re...You\'re despicable!


It is a painful thing 
To look at your own trouble and know 
That you yourself and no one else has made it.


John Connor, It is time.


One exam does not a (J2EE) architect make.

http://www.nerdtests.com/ft_nq.php?im";>
http://www.nerdtests.com/images/ft/nq.php?val=8792"; alt="I am nerdier 
than 97% of all people. Are you nerdier? Click here to find out!">

Re: Help about IRC

I thought we are not going to have a IRC channel for discussions as no 
archive is maintained of it

On 5/13/05, Dalibor Topic <[EMAIL PROTECTED]> wrote:
> 
> Mohammed Nour wrote:
> > I need to know which IRC channel I shold look into ?
> >
> 
> Hi Mohammed,
> 
> try the #harmony channel on irc.freenode.org 
> 
> cheers,
> dalibor topic
> 



-- 
www.FaeLLe.com

Re: Where is Geir Magnusson?

Ok. understood.

-- dims

On 5/13/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > Mladen,
> >
> > Can you please join the IRC? then we can summarize what we talked to the 
> > lsit.
> >
> 
> Please, please don't put all the traffic on IRC. There are many many
> people interested in Harmony who do not have the bandwidth to sit there
> and despite best intentions summaries don't get posted often enough.
> 
> IMO using IRC too heavily too early has led to lingering community
> issues in Geronimo - please don't repeat that.
> 
> --
> Jeremy
> 
> 


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

Re: Where is Geir Magnusson?

2005-05-13 Thread Aaron Hamid

However, as a complementary alternative to IRC, I beseech the noble souls maintaining the 
wiki, faq, and blog "digest" to continue, as constant rehashing of the same 
discussions on the mailing list is also not desirable.
Aaron
Davanum Srinivas wrote:
Ok. understood.
-- dims
On 5/13/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Davanum Srinivas wrote:
Mladen,
Can you please join the IRC? then we can summarize what we talked to the lsit.
Please, please don't put all the traffic on IRC. There are many many
people interested in Harmony who do not have the bandwidth to sit there
and despite best intentions summaries don't get posted often enough.
IMO using IRC too heavily too early has led to lingering community
issues in Geronimo - please don't repeat that.
--
Jeremy

Re: A small documentation contribution

Nick,

If you could update the wiki, we'd appreciate it. that way everyone
can contribute to keeping it uptodate. http://wiki.apache.org/harmony/

thanks,
dims

On 5/11/05, Nick Lothian <[EMAIL PROTECTED]> wrote:
> 
> One of the big problems for newcomers to the Harmony project is
> discovering what has already been discussed. I suspect this could get
> worse as the project expands.
> 
> I've started a blog to attempt to summarise the discussions on the
> mailing list and elsewhere: http://www.mackmo.com/apacheharmony/default/
> 
> The idea is that it will make it easy for people to come up to speed on
> issues. For instance, the next time someone suggests not implementing
> deprecated APIs they can be pointed at
> http://www.mackmo.com/apacheharmony/default/2005/05/11/Deprecated_APIs.h
> tml
> 
> In the future some of this could get put in a formal FAQ sometime - in
> the mean time I'll try and keep it updated. Any suggestions for it are
> welcome.
> 
> Nick
> <[EMAIL PROTECTED]>
> 
> 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: Against using Java to implement Java (Was: Java)

Sounds great Robin. So what the the problems (if any) with JikesRVM?
how would one go about making it enterprise-ready (to use a well-worn
cliche)?

thanks,
dims

On 5/12/05, Robin Garner <[EMAIL PROTECTED]> wrote:
> > I hope you use C to write the VM for Harmony.
> >
> > The reason is, that I think, that the best is, if Harmony is nearly 100%
> > compatible to Suns Java.
> >
> > If you write the VM in Java itself, then there existing some problems:
> > 1. you need a native-code compiler (like gcj) to create it. And if Harmony
> > itself is a native-code compiler it is not 100% compatible to Suns JVM.
> 
> This isn't necessarily so.  While there are bootstrapping issues, VMs like
> JikesRVM compile themselves under normal operation.
> 
> > 2. I don't know how you want to create a JNI-Interface for C, if the JVM
> > is
> > written in Java.
> 
> This has been done successfully by existing Java-in-Java virtual machines.
>  JikesRVM is open source - you could read the code and find out how it
> does it if you want :)
> 
> cheers,
> Robin
> 
> 


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

Re: Where is Geir Magnusson?

Agreed - please don't do it to IRC. Lets keep as much as humanly  
possible here.

geir
On May 13, 2005, at 11:48 AM, Jeremy Boynes wrote:
Davanum Srinivas wrote:
Mladen,
Can you please join the IRC? then we can summarize what we talked  
to the lsit.

Please, please don't put all the traffic on IRC. There are many  
many people interested in Harmony who do not have the bandwidth to  
sit there and despite best intentions summaries don't get posted  
often enough.

IMO using IRC too heavily too early has led to lingering community  
issues in Geronimo - please don't repeat that.

--
Jeremy

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

Re: Help about IRC

2005-05-13 Thread Dalibor Topic

FaeLLe wrote:
I thought we are not going to have a IRC channel for discussions as no 
archive is maintained of it
Gosh, no, please keep the discussions on the list. I
RC channels are for people to get to know each other, more or less, they 
provide a bit of social backdrop to what's otherwise just impersonal e-mail.

cheers,
dalibor topic

Re: Where is Geir Magnusson?

On May 13, 2005, at 11:03 AM, Mladen Turk wrote:
Mladen Turk wrote:
Geir Magnusson Jr. wrote:
Well, I was just wondering if he is still counting
those 100 Mils IMB payed him for Geronimo ;)
They purchased my company, Gluecode Software. Lets keep the two   
worlds apart.  I certainly do.


My question was: What are you thoughts on Harmony, since we haerd
nothing from you since all tohose GNU/ASF licensing.


Also, the Sun gave a statement that you will speak about Harmony this
summer, so I just wonder what you will be speaking about?
harmony at that point, whatever harmony is at that point.  Lets  
discuss that as the time gets closer.

Is the Harmony already defined project or you will be speaking
on your personal vison?
Please give us some ansvers. The discussion is going nowhere thought.
Are we ASF or ASF/GNU/Kaffe/Whatever/* project?
The fact that there *is* such a robust discussion is a *great*  
start.  Technically speaking, this is an incubating ASF project.  We  
are trying to bring everyone together  from * to participate in the  
architectural discussions, and we'll take it from there.

Like I said, I got totally swamped earlier this week, and am catching  
up.  My silence is only due to "the perfect storm" of the timing of  
everything.  All is well.

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

Re: Java Application Native Wrapper

On 5/13/05, Bob <[EMAIL PROTECTED]> 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.
> 
> -- Bob


Yes something of that sort is what i meant




-- 
www.FaeLLe.com

Re: Wishlist

Archie,

Cool! i missed that, sorry. Added to wiki
(http://wiki.apache.org/harmony/) under "Volunteers with
Contributions". Thanks.

-- dims

On 5/12/05, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > - Wish one or more of the existing VM's consider donating to Apache.
> 
> FWIW (probably not much :-) I've already offered to; see the end of
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/[EMAIL
>  PROTECTED]
> 
> Cheers,
> -Archie
> 
> __
> Archie Cobbs  *CTO, Awarix*  http://www.awarix.com
> 


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

Re: [

ignore him :)

On 5/12/05, FaeLLe <[EMAIL PROTECTED]> wrote:
> Can somebody comment on this guys claims,
> 
> http://www.jroller.com/page/fate/20050507#death_to_apache
> 
> Ps. warning: lot of flaming of our idealogies take place there but i would
> still like to see him shut up.
> 
> --
> www.FaeLLe.com 
> 
> 


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

Re: Two seeds (Re: Developing Harmony)

oops. operator error
(https://svn.sable.mcgill.ca/wsvn/sable/?rev=1732&sc=1) threw me off.
SableVM does not use MMTk. But still

-- dims

On 5/13/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Steve,
> 
> This is great!!! I love the idea of using JikesRVM and one another JVM
> (hey SableVM already uses MMTk, Kaffe's license is too difficult -
> though not impossible - to change because TransVirtual is no more).
> 
> thanks,
> dims
> 
> On 5/13/05, Steve Blackburn <[EMAIL PROTECTED]> 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)
> >
> >   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
> >
> >
> 
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 


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

RE: I hope the JVM implements most using Java itself

2005-05-13 Thread John Luke

Hello,
On Fri, 2005-05-13 at 14:56 +0930, Nick Lothian wrote:
>  > 
> 
> [snip - I'm not qualified to answer the first question]
> 
> > 
> > 
> In the area of VMs benchmarks like http://www.shudo.net/jit/perf/ shows
> that the Jikes RVM (a pure Java VM) is very comptitive with other open
> source VMs. 
> 
> I believe that Mono (the Open Source .NET implementation) is written
> mostly in C#, and its performance is also very competitive.
> 
The mono runtime is written in C, but it is true C# is used as much as
possible everywhere else (compiler, class libraries, apps, etc).

Re: Harmony may provide a more general VM than JVM

2005-05-13 Thread Rodrigo Kumpera

Harmony should be just a JVM. The runtime model between .NET and Java,
for example, is diferent enouth to be well harder than perform the
bytecode translation.
See IKVM, that run java bytecode on top of mono/.net. 

Rodrigo



On 5/13/05, Steve Heath <[EMAIL PROTECTED]> wrote:
> won't that all be a little complicated? The JVM runs bytecode, not
> Java itself. Isn't there an equivalent for .Net too? I don't know
> about languages such as Smalltalk, but I think their standard is the
> language itself, it's up to the interpreter to deal with it from
> there. I suspect will suggest we need a
> 
> Given the gulf between the structures of these languages and bytecode
> systems, is this thread suggesting a completely generic VM and having
> some kinda translator to move from bytecodes to Harmony-codes?
> 
> On 5/13/05, 王在祥 <[EMAIL PROTECTED]> wrote:
> > Agree.
> >
> > 2005/5/12, Stefano Mazzocchi <[EMAIL PROTECTED]>:
> > >
> > > 王在祥 wrote:
> > > > Harmony is focus on provide a Tiger compatible JVM, but i think it is
> > > > possible to make it more general for other language such as .NET,
> > > Haskell,
> > > > Smalltalk etc.
> > > >
> > > > the Harmony VM may define such a VM core, such as memory management,
> > > multi
> > > > thread support, object layout etc, that is general for most VM. also, it
> > > can
> > > > define a bytecode of itself as its native bytecode. then other bytecode
> > > can
> > > > be translate to the general bytecode and then JITed.
> > >
> > > First things first. Writing a java JVM is a hard enough task. We'll see
> > > what happens after we reach that goal.
> > >
> > > --
> > > Stefano.
> > >
> > >
> >
>

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Stefano Mazzocchi

Ben Laurie wrote:
As I've said before, I'd like to see 
a framework that _allows_ most of the VM to be run in Java (or Python, 
or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
Yes, I think this is the most sensible compromise.
I would agree in making this one of our high level requirements for 
Harmony's architecture.

--
Stefano.

Re: JIT vs. WAT

2005-05-13 Thread Rodrigo Kumpera

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
>

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/

Re: [

2005-05-13 Thread Stefano Mazzocchi

Kev Jackson wrote:
Why do we need an open source Java?
Let's analyze it on the other way: why not?
1) because it's already there. [Ask Ben how much he loves java on FreeBSD]
2) because it's hard. [Ask Linus about how easy it was to write Linux]
3) because it might fragment the space. [Ask around how many of us would 
want to rewrite millions of lines of their code]

4) because it's an academic exercise [ask Larry and Sergey about thier 
academic exercise called Google]

5) because it might hurt the java ecosystem [ask darwin and/or your 
favorite anti-trust lawyer on how concentrations increases innovation]

6) because it's not fun [ask the people that spend their time writing 
new GC algorithms!]

7) because it might take years [ask around how many are in a hurry]
Should I continue?
--
Stefano.

Re: Programmer Volunteering (sorry if I should read a FAQ before)

2005-05-13 Thread Anthony Green

On Fri, 2005-05-13 at 13:15 -0300, Nilseu Padilha JMiB wrote:
> Greetings.
> 
> I am a cmomercial Systems Architect and would like to volunteer myself as a 
> developer to the Harmony  Project. Sorry if I should read any FAQ before, but 
> I like to know how I could contribute to the project.

I have some bad news and some good news for you.   

The bad news is that there's no way for a developer to hack on Harmony
code, since there is none yet - and any decisions about what code there
might eventually be appears to be in the hands of law-talking people
(both professional and amateur).

The good news is that you can _still_ contribute to Open Source
implementations of the Java Programming Language by contributing to the
GNU Classpath project, which provides implementations of the core
libraries to dozens of free VM implementations (hopefully, this will
eventually include the Harmony project, but no guarantees yet).

Please point your browser at

  http://www.gnu.org/software/classpath/faq/faq.html#faq3_1

Thanks!

AG

RE: JIT vs. WAT

2005-05-13 Thread Patrice Le Vexier

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/

Re: [

On May 12, 2005, at 10:15 PM, FaeLLe wrote:
Can somebody comment on this guys claims,
http://www.jroller.com/page/fate/20050507#death_to_apache
Ps. warning: lot of flaming of our idealogies take place there but  
i would
still like to see him shut up.

He's a friend of mine.  He's actually a really good J2EE technologist  
and does it for fun.

Credit where credit is due - there's a grain of truth in his blog in  
general.  However, he tends to go overboard :)

In this case (and he and I have talked about this quite a bit) he's  
looking at the world from the POV of a JRE user that doesn't have  
concerns about JRE license, just performance and capability.   I keep  
trying to spin his POV around to that of distributor, vendor, free- 
software supporter, etc.  I'll let you know if we make any progress.

Read him.  Laugh if you find him funny (I usually do, and have been a  
personal target a few times...)  Then move on :)

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

Re: Against using Java to implement Java (Was: Java)

It doesn't matter where the problem lies, the point is that I can't develop 
on the platforms I need/want to develop on.
My reply wasn't intended to be dismissive.  I'm short on details.  What 
platforms are you referring to?  Even a slow base VM can be an adequate 
bootstrap VM to create the initial Harmony install, and thereafter you use 
Harmony.

I suppose that for porting issues, a C-based bootstrap VM for platforms that 
don't have an existing VM could be used, but I think that would be more of a 
future project.  For now, I suspect that the primary target platforms for 
Harmony are those currently supported by Sun, primarily *nix and Windows, 
although I think we should definitely expand to include OS X, if that is 
possible.

Again, the project leads can probably say more about what the plan is there.
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Ian Darwin

> I suppose that for porting issues, a C-based bootstrap VM for platforms 
> that don't have an existing VM could be used, but I think that would be 
> more of a future project.  For now, I suspect that the primary target 
> platforms for Harmony are those currently supported by Sun, primarily *nix 
> and Windows, although I think we should definitely expand to include OS X, 
> if that is possible.

I disagree; my main interest in Harmony is for platforms that Sun does NOT 
support.
Like all the BSD platforms.

Re: Against using Java to implement Java (Was: Java)

2005-05-13 Thread Fernando Lozano

Ian,
I guess the current state of GCJ, Kaffe and SableVM should be enough for 
bootstraping harmony on BSD. Did you tried any of these?

[]s, Fernando Lozano
I suppose that for porting issues, a C-based bootstrap VM for platforms 
that don't have an existing VM could be used, but I think that would be 
more of a future project.  For now, I suspect that the primary target 
platforms for Harmony are those currently supported by Sun, primarily *nix 
and Windows, although I think we should definitely expand to include OS X, 
if that is possible.
   

I disagree; my main interest in Harmony is for platforms that Sun does NOT support.
Like all the BSD platforms.

Re: Against using Java to implement Java (Was: Java)

Isn't it a good idea to write the first implementation in a functional
programming language (read the wizard book)? That's what these
platforms are designed for and the constructs are there to help in
designing the thing. Then when you're happy you know what's good and
bad you can re-code it in something that actually runs fast. I'm aware
of a reasonable amount of literature that talks about GC and
interpretation techniques that uses languages such as ML and Scheme.
Somebody else mentioned Erlang (because of its concurrency support?), and I 
mentioned Ocaml, which is an ML variant.

I think your idea is a good one, but I don't think that will happen.  First, 
there's an entrenched base of people who think a declarative programming 
style is just weird, period.  They don't like it and don't want to do it.  
Then there'd be the issue of what functional programming language to use.  
At the end of the day, you have to have enough hands to do the work, and you 
would be surprised how many willing workers have never had exposure to 
functional programming.

If we were to go the route of writing the prototype in a functional 
programming language, I'd suggest ANSI Common Lisp.  There are a lot of 
LISPers out there (and Schemers), and LISP has features that make bottom-up 
rapid development very doable.  There are a lot of free and open-source 
Common LISP implementations as well.  SBCL, CMU-CL, CLISP, GCL, OpenMCL, 
blah blah blah, and of course there's the commercial stuff like Allegro CL 
and LispWorks.  With its macro facility, ACL codebases can become their own 
lanaguages.

ML/Ocaml is good too.  I'd actually recommend Ocaml over ML because it has 
seen actual commercial use in Europe (although SML has been used in 
England).

I don't know enough about Erlang.  Clean looks interesting, and Mozart looks 
pretty interesting too, but then we are getting into niche languages that 
almost nobody who would be interested in this project would know that much 
about.

Heck, prototype it with Jython. :)
Compiled Java initially seems as good as anything, but don't those
compilers add in their own brand of GC? Wouldn't that be an overhead
we neiter need nor want? Do we want to generate our own native
compiler? I'm thinking the best native compiler/language to use is
probably C.
We've got people here from Redhat, so they are probably thinking that 
provide a back-end to GCJ would fit that need.

I agree that most of the libraries can be written in Java, but
wouldn't that constitute a separate apache project, just like GNU
Classpath? The VM should probably be as clean as a very clean thing...
in a clean room.. (hence why I never mentioned C++ :)
I suspect that since we need both to pass the TCK, we will have two projects 
in one.  I think that the class libraries will be the bigger part of the 
work.

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

Re: [

Hahahahahaha you da man

On 5/13/05, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> 
> Kev Jackson wrote:
> 
> > Why do we need an open source Java?
> 
> Let's analyze it on the other way: why not?
> 
> 1) because it's already there. [Ask Ben how much he loves java on FreeBSD]
> 
> 2) because it's hard. [Ask Linus about how easy it was to write Linux]
> 
> 3) because it might fragment the space. [Ask around how many of us would
> want to rewrite millions of lines of their code]
> 
> 4) because it's an academic exercise [ask Larry and Sergey about thier
> academic exercise called Google]
> 
> 5) because it might hurt the java ecosystem [ask darwin and/or your
> favorite anti-trust lawyer on how concentrations increases innovation]
> 
> 6) because it's not fun [ask the people that spend their time writing
> new GC algorithms!]
> 
> 7) because it might take years [ask around how many are in a hurry]
> 
> Should I continue?
> 
> --
> Stefano.
> 
> 


-- 
www.FaeLLe.com

Harmony Cross-Compilation

2005-05-13 Thread Daniel Qarras

Hi,

you've probably received tons of comments,
suggestions, wishes, etc so I guess one more cannot
hurt.

Summary: please make it possible to cross-compile
Harmony.

Background: I work with embedded systems and I've
learnt that Sun's slogan "Write once, run everywhere"
surely doesn't apply in the embedded world - there's
simply no JVM for platforms like Linux/MIPS or
NetBSD/ARM from Sun. Perhaps even the server side with
less popular HW suffers the same problems (Alpha,
S390, HP-PA, who knows?). So I think it would be great
if I could take Harmony and just cross-compile it for
my platform of choice, no matter what OS or HW I'm
using. I also think that it's much easier to make
build system (and the code) cross-compilable right
from the beginning than to find out later that a
painful overhaul is needed.

Speculation: People might also be intrested in using
Harmony to create J2ME runtime platform for their
embedded devices once Harmony/J2SE seems to be mature.
At that point cross-compilation support is essential.

Thanks,
Dan.




Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html

Re: Harmony Cross-Compilation

2005-05-13 Thread Ian Darwin

> Speculation: People might also be intrested in using
> Harmony to create J2ME runtime platform for their
> embedded devices once Harmony/J2SE seems to be mature.
> At that point cross-compilation support is essential.

No, it isn't, because by then, your average cell phone will have enough
computing power to compile Harmony in under five minutes.

N.B. Don't forget to attach several ":-)" to the above after reading it.

Re: Java Application Native Wrapper

2005-05-13 Thread Dmitry Serebrennikov

Mohammed Al-Qaimari 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.
There's NO Knowledge That is NOT POWER!
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
 

At the risk of creating more nise on the list, here's an opensource tool 
for this purpse that I used with great success (on Windows):
jelude http://www.sfu.ca/~tyuen/jelude/
It is in "public domain", so not a lot of licensing issues.
There are many others that are opensource and not. Just look around if 
you need one of these.

Regards
-dmitry

Summing Up

2005-05-13 Thread usman bashir

Dear fellows!
 i have been watching the discussion closely since long now, and i have 
decided to put the things in summed up version what i learnt and thought 
about this project so that i may be able to bring some harmony in the 
"harmony" project.
 first the major concerns arises why we need an open source version of java 
when we have some good examples in our hands by Big vendors. here are some 
my thoughts!
 Open sourcing java will enable us to earn the following benefits
 1. We can embed it right into the core of Linux .
 2. we have a free version (and many knows the cost value who ever need to 
deploy their applications to worl who never ready to put their penny in any 
other way)
 3. Due to open source, not only developers but companies able to verify the 
base code of the java and its efficiency and merge their changes in it (but 
sorry to say living in the Specs of sun and it should be mention in our 
specs as well , as we are not wana to create mess here , we are moving 
towards harmony ;) )
 4.it will also help the others to tap into the java and it will help the 
community to make extensions in java and at the end also to Sun as well.
  so there can be more arguments when we come to this discussion so i think 
however enough for those who are curious to know some flag.
 then it come to point how should we go on in the positive direction,
 here is my suggestion, first of all i would like to solve the issue of 
programming (as major discussion lies around this issue ) 
 for me, we should do most of work (as much as possible ) in java, which not 
only help us to write some better code but also help us to maintain it well 
and if we becomes stick some where like some guys pin out issues of memory 
management, bootstraping, GC etc , we can dig though c/c++ etc. 
 but how we will be done , i have the idea we should split the desing into 
various parts and then each team could decide well what he could do in this 
regard, for example a team working on the memory management could work in 
C/C++ if they find it easy and moduler (though i still favors java now but i 
think it should leave over them ...) 
 so it also allows us to integrate more volunteers in this project , based 
from all sources not only java.
 anohter benefit of this would be is that we can extend the VM as we need in 
future due to its moduler nature.
 i also like the idea of embedding the extension components , as it will 
realy make the sense if u look last goal of my list, as companies may decide 
to use some other component for their project suiting to their context, and 
if we go like i said X-teams then we can achieve this target as well.
 now the last thing , dont worry why are messing up at now, projects always 
took time, and dont speak loudly like developers, who only know to run thier 
hands without worrying what to come
 and at the end being junior i would like to get pardon before if any one 
minds ;)

-- 
Usman Bashir

Re: [

2005-05-13 Thread Brian Goetz

The web is full of asshats, misanthropes and social misfits with blogs.  
The guy is an asshat.  
You just wish he would call you an asshat.  Being called an asshat by 
Hani is a true badge of achievement in the Java world.  I look fondly to 
the day that I achieve the status of asshat in Hani's weltanschaung. 
But I won't bore you further with my asshat-wannabe-aspirations.

He may be abrasive (he's worked hard to become so), but there's always 
some truth to what he says.  Try and find it, its actually a worthwhile 
exercise.

Re: Harmony Cross-Compilation

2005-05-13 Thread Ravi kiran Gorrepati


So I think it would be great
if I could take Harmony and just cross-compile it for
my platform of choice, no matter what OS or HW
Cross-compiling, if I am right, works across architectures,
but not operating systems. Atleast that is what I have seen
in Jikes. You generally endup writing a different wrapper
around the compiled code(which respects the runtime conventions
for that OS), for different operating systems.
--
Ravi

Re: Harmony Cross-Compilation

2005-05-13 Thread Brett Wuth

Ravi kiran Gorrepati writes:
 > > So I think it would be great
 > > if I could take Harmony and just cross-compile it for
 > > my platform of choice, no matter what OS or HW
 > 
 > Cross-compiling, if I am right, works across architectures,
 > but not operating systems.

In the C world cross-compiling works across both HW and operating
systems.  I too would like to see this feature in Harmony.

Regards,
-- 
Brett Wuth  [EMAIL PROTECTED] [EMAIL PROTECTED]
Box 1251-U, Pincher Creek, Alberta T0K 1W0, CANADA  Tel:+1 403 627-2460
PGPKey ID=23276D81 FingerPrint=E4F8EDEECBE01AD2FA3D8B2D94B1A292
What is the meaning of life?!  Yes.

Re: The topic of the Java Compiler

2005-05-13 Thread Tom Tromey

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

Tom

Re: Harmony Cross-Compilation

2005-05-13 Thread Ravi kiran Gorrepati

On Fri, 13 May 2005 17:25:20 -0600, Brett Wuth <[EMAIL PROTECTED]>  
wrote:

In the C world cross-compiling works across both HW and operating
systems.  I too would like to see this feature in Harmony.
I should have put this more properly. My mistake. But, it is always
easier to write a cross-compiler that cheats the underlying runtime,
that it is behaving to the conventions. Write a native code wrapper,
written in your favorite lang, on your preferred OS and then just
branch to the the generated JVM compiler code, that is spit by the host
compiler(This approach even saves you from respecting the conventions
of architecture!!). Your generated code, is just a stream of instructions,
and is free from all conventions.
Though this approach is not ideal, it lets us
keep the VM simple and understandable.
--
Ravi

Wiki

2005-05-13 Thread ALEJANDRO GONZALEZ

Hi, i want to help to translate documents to spanish. How can i edit pages
in the wiki???

Sorry about wiki :P

2005-05-13 Thread ALEJANDRO GONZALEZ

I didn't see the "login" button, because my locale is setted to spanish...
Seconds after sending the mail i found a button that says "Ingresar"
("Login" in spanish...)

Re: JIT vs. WAT

2005-05-13 Thread Tom Tromey

> "Rodrigo" == Rodrigo Kumpera <[EMAIL PROTECTED]> writes:

Rodrigo> It would be great to be GCJ compatible. Leveraging they effort with
Rodrigo> the binary ABI is a smart move and will promote more harmony instead
Rodrigo> of fragmentation between the java ahead-of-time systems.

See the "pluggable jit" thread on the classpath list; I sent a pointer
here earlier.  That has a list of the issues.

This is not trivial to accomplish.  It can be done, and with some not
unreasonable implementation decisions you can get fairly close fairly
easily.

That said, finishing the task is hard.  As a concrete example, ORP was
a fairly modular VM; the JITs in ORP did not hard-code knowledge about
thing like object layout but instead asked the VM component for this
information.  Likewise they did not know about GC.  Nevertheless it
proved hard to integrate this with gcj's output (I tried as a weekend
hack and gave up) due to mismatches between exception handling
implementations.  (A similar thing applies if you look at merging
kaffe and gcj, which both Dalibor and I have done.)

Rodrigo> But this raises a question, can Harmony use GCJ's binary ABI
Rodrigo> without been GPL?

I'm sure that wouldn't be a problem.
I think it is no different from, say, replacing libgcc, which some
people do.

Tom

Re: Where is Geir Magnusson?

2005-05-13 Thread Sanjiva Weerawarana

On Fri, 2005-05-13 at 08:48 -0700, Jeremy Boynes wrote:
> 
> Please, please don't put all the traffic on IRC. There are many many 
> people interested in Harmony who do not have the bandwidth to sit there 
> and despite best intentions summaries don't get posted often enough.
> 
> IMO using IRC too heavily too early has led to lingering community 
> issues in Geronimo - please don't repeat that.

THANK YOU Jeremy! Also, using IRC seriously biases against those of us
who don't happen to be in the same timezone as the rest of you.

I try to stay connected and to scroll back and look but that's not
reliable and its certainly not archived. Defaulting to IRC is very
anti-community IMO. In Axis land we have a weekly, scheduled, IRC chat
and post the logs to the list and we rotate the time to make it
reasonable to everyone. That is acceptable IMO but certainly not using
IRC the whole time like Geronimo tends to (or let us hope used to tend
to!).

Sanjiva.

Re: Sending native code to the processor at runtime