You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
Regards,
Jeroen
-Original Message-
From: Aaron Hamid [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 20:44
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] How much of
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
The simpler solution is to just use class loaders as a modularization
mechanism. It is possible (since I have done it in my OSGi framework) to
create a class loader
Richard S. Hall wrote:
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
The simpler solution is to just use class loaders as a modularization
mechanism.
No, that does not solve the problem of getting access to the
Jeroen Frijters wrote:
No, that does not solve the problem of getting access to the internals
of public classes. For example, java.lang.VMThread needs to access
package private methods in java.lang.Thread.
You are correct, if your design is such that you need private access
both ways,
From a user perspective, Jikes RVM uses classpath out of the box. (It
builds with unmodified GNU classpath releases and classpath cvs head; we
don't distribute GNU classpath with Jikes RVM).
We do provide our own versions of a few classes in java.* that the build
process selects instead of
[EMAIL PROTECTED] wrote on 06/05/2005 10:48:29 PM:
- The machine code concatinating technique consumes much memory.
In my experience, generated machine code is about 10 times larger
than the original instructions in Java bytecode.
In the paper, the authors have not mentioned memory
Hi Dave,
From: David P Grove [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 06/05/2005 10:48:29 PM:
- The machine code concatinating technique consumes much memory.
In my experience, generated machine code is about 10 times larger
than the original instructions in Java bytecode.
Jeroen I think there are at least two perceived problems being voiced:
* aversion to the idea of polluting a standard library distribution (e.g.
Classpath) with VM-specific interface implementations. Although there have been
assurances that such work is trivial and the interface is
Gah. :(
So if I am to understand this correctly: Classpath java.lang.* implementation does not rely on specifics of
any given VM* interface implementation, but said VM* interface implementations MAY rely on internals of
existing Classpath java.lang.* classes? (so there is a one-way dependency
On 6/6/05, Peter Donald [EMAIL PROTECTED] wrote:
The reason being that their customers do not
want to be exposed to differences between rt.jar and GNU Classpath.
oh well aren't both implemented according to a well-designed exported
API. So how there would be differences that would hurt the
Hi,
On 6/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi Dave,
From: David P Grove [EMAIL PROTECTED]
One thing to
note is that a threaded interpreter would see something like a 2-4x
expansion over normal bytecodes when it converts from bytecodes to its
internal form (arrays of
Hi Rob,
From: Robert Lougher [EMAIL PROTECTED]
Date: Mon, 6 Jun 2005 14:58:45 +0100
One thing to
note is that a threaded interpreter would see something like a 2-4x
expansion over normal bytecodes when it converts from bytecodes to its
internal form (arrays of function pointers).
Peter Donald wrote:
I assume that if the Harmony JVM gets half as good as is hoped there
will be companys who want to adopt the JVM but continue to use Suns
class library so that differences in libraries don't hurt their customers.
If that is a goal of Harmony then we've just made things a
On Mon, 2005-06-06 at 10:01 -0400, Aaron Hamid wrote:
Gah. :(
So if I am to understand this correctly: Classpath java.lang.* implementation
does not rely on specifics of any given VM* interface implementation, but said
VM* interface implementations MAY rely on internals of existing
Geir Magnusson Jr. wrote:
Doesn't this imply that the GNU Classpath interface should add a
second API that *it* should comply with for symmetry? That way you
don't get dependencies on GNU Classpath internals?
I've been a bystander in this discussion as I know very little about the
class
A useful standard bibligraphy for many
Java topics:
http://www.topcoder.com/pl/?module=Staticd1=javaone04d2=book_titles
including all your favorites.
Dan Lydick
Hi,
Ahmed Saad wrote:
oh well aren't both implemented according to a well-designed exported
API. So how there would be differences that would hurt the clients of
this API (assuming that the GUN Classpath got completed and they are
both might be retrofitted to be easily installed in this
Hi,
Consider the following class libraries:
[A] Suns rt.jar and derivatives (such as IBMs) class libraries
[B] GNU Classpaths class libraries
[A] has a proprietary VM interface that is not publicly documented and
some people fear looking at the implementation because of possible taint
(IMHO
On Tue, 2005-06-07 at 12:36 +1000, Peter Donald wrote:
[A] Suns rt.jar and derivatives (such as IBMs) class libraries
[B] GNU Classpaths class libraries
[..]
In an ideal world Harmony VM would be able to use either [A] or [B]
with a small adapter layer. Much like MMTk can be used in multiple
19 matches
Mail list logo
