Hi Tim,
Thanks for your thoughtful comments on the architecture of VM
accessors.
Ellison, Tim wrote:
These are a helper set of singleton Java classes to support
Classlibrary
implementation. We can instantiate them through an Accessor factory
interface ( Modular JVM diagram ). They
usman bashir wrote:
i am looking the same sort of things from IBM guys, as if i am not wrong
they claim to do same sort of things before :)
and it will really help full if we can have two baselines to work on.
This would work better with a diagram, ...
IBM has a set of class libraries (only
Hi Rana,
Dasgupta, Rana wrote:
I would like to invite discussion and comments from the community on the
VM Accessor component in the Harmony Modular JVM diagram, on its
functionality, design and implementation. Here are some initial
thoughts.
These are a helper set of singleton Java
Hi Mladen,
I am curious about 'light-weight' native calls for primitive array
type you mentioned below. In the general case, a GC might move the
primitive array while the native method is operating on the array.
Can you tell us how the light-weight interface would deal with this
situation?
I would like to invite discussion and comments from the community on the
VM Accessor component in the Harmony Modular JVM diagram, on its
functionality, design and implementation. Here are some initial
thoughts.
These are a helper set of singleton Java classes to support Classlibrary
i am looking the same sort of things from IBM guys, as if i am not wrong
they claim to do same sort of things before :)
and it will really help full if we can have two baselines to work on.
On 8/29/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And on the wiki after posting here, please?
And on the wiki after posting here, please? :)
geir
On Aug 19, 2005, at 12:33 PM, Tim Ellison wrote:
Weldon Washburn wrote:
On 7/11/05, Tim Ellison [EMAIL PROTECTED] wrote:
Recently, within IBM, we have been defining the interface between
IBM's
class library and the J9 VM. We
Weldon Washburn wrote:
On 7/11/05, Tim Ellison [EMAIL PROTECTED] wrote:
Recently, within IBM, we have been defining the interface between IBM's
class library and the J9 VM. We deliberately haven't looked at the GNU
Classpath/VM interface specification.
The principal goals are to enable the
On Aug 15, 2005, at 11:48 AM, Weldon Washburn wrote:
On 7/12/05, Tim Ellison [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
On Jul 11, 2005, at 12:14 PM, Tim Ellison wrote:
Recently, within IBM, we have been defining the interface
between IBM's
class library and the J9 VM. We
Hi Weldon,
Weldon Washburn wrote:
On 7/12/05, Tim Ellison [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
On Jul 11, 2005, at 12:14 PM, Tim Ellison wrote:
Recently, within IBM, we have been defining the interface between IBM's
class library and the J9 VM. We deliberately haven't looked
On 7/12/05, Tim Ellison [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
On Jul 11, 2005, at 12:14 PM, Tim Ellison wrote:
Recently, within IBM, we have been defining the interface between IBM's
class library and the J9 VM. We deliberately haven't looked at the GNU
Classpath/VM
On Jul 20, 2005, at 7:02 PM, Mark Wielaard wrote:
Hi,
On Tue, 2005-07-19 at 12:38 -0400, Geir Magnusson Jr. wrote:
The reason nobody answered this question is because we are still
debating how to accept code that is both GPLv2 and ASLv2 compatible.
I'm not sure that's the issue exactly -
Hi Geir,
On Tue, 2005-07-19 at 12:32 -0400, Geir Magnusson Jr. wrote:
If there are non-trivial pieces of code, they can be posted here if
or should be submitted into a JIRA, choosing to contribute under the
apache license, and then post a message here.
On Mon, 2005-07-18 at 19:40 +0200,
Hi,
On Tue, 2005-07-19 at 12:38 -0400, Geir Magnusson Jr. wrote:
The reason nobody answered this question is because we are still
debating how to accept code that is both GPLv2 and ASLv2 compatible.
I'm not sure that's the issue exactly - I think it's about dual
licensing.
No it is
Hi Johnson!
it is really good, some what like COM (querying IUknown ,sorry for having
some term from nonjava ;) ), yeah i think so this way not only promote the
interop as well as we can replace the each trianger side (VM, OS layer and
class library).
though i suppose the efficieny can be a
On Jul 18, 2005, at 12:48 PM, Zsejki Sorin Miklós wrote:
The mailing list is probably not the right forum for posting non-
trivial pieces of code. Geir: What's the right forum for this sort
of discussion?
I am checking every day to see if the answer to this has popped up,
but no luck
On Jul 18, 2005, at 1:40 PM, [EMAIL PROTECTED] wrote:
The mailing list is probably not the right forum for posting non-
trivial
pieces of code. Geir: What's the right forum for this sort of
discussion?
I am checking every day to see if the answer to this has popped
up, but
no luck so
The mailing list is probably not the right forum for posting non-trivial
pieces of code. Geir: What's the right forum for this sort of discussion?
I am checking every day to see if the answer to this has popped up, but
no luck so far. In case I missed something, could someone point me into
The mailing list is probably not the right forum for posting non-trivial
pieces of code. Geir: What's the right forum for this sort of discussion?
I am checking every day to see if the answer to this has popped up, but
no luck so far. In case I missed something, could someone point me into
the
Akhilesh Shirbhate [EMAIL PROTECTED] wrote on 07/12/2005
05:18:20 AM:
Can we have a look at the vmi.h and the list of 18 classes, and
specially the two classes required for integration ?
As a follow-up to Tim Ellison's response let me provide more detail on
J9's VM Interface (VMI) and Kernel
Can we have a look at the vmi.h and the list of 18 classes, and
specially the two classes required for integration ?
Besides, I would also like to know the changes/extensions you have
thought till date for 1.5 spec.
To me, it seems that there should be a lot of extensions given the
fact that 1.5
Geir Magnusson Jr. wrote:
On Jul 11, 2005, at 12:14 PM, Tim Ellison wrote:
Recently, within IBM, we have been defining the interface between IBM's
class library and the J9 VM. We deliberately haven't looked at the GNU
Classpath/VM interface specification.
The principal goals are to
Tim Ellison wrote:
Recently, within IBM, we have been defining the interface between IBM's
class library and the J9 VM. We deliberately haven't looked at the GNU
Classpath/VM interface specification.
snip/
If there is an interest, we can share the interface we are using and
evolve it as part
On Jul 10, 2005, at 5:21 PM, Archie Cobbs wrote:
Geir Magnusson Jr. wrote:
Ok, from the school of Storming the Gates! Take 2, lets again
examine the question of VM/classlib interface as this is an
important aspect to address and our first run at it wasn't so
successful.
The questions
3. Don't worry about inlining Java code: assume the VM can do 'easy'
inlining like invoking static methods.
How does that aspect matter to the VM/classlib interface?
It matters in that when defining the VM/classlib interface you
should assume that adding a level of easy to
Geir Magnusson Jr. wrote:
Ok, from the school of Storming the Gates! Take 2, lets again
examine the question of VM/classlib interface as this is an
important aspect to address and our first run at it wasn't so
successful.
The questions I have are all around the different ways has this
Recently, within IBM, we have been defining the interface between IBM's
class library and the J9 VM. We deliberately haven't looked at the GNU
Classpath/VM interface specification.
The principal goals are to enable the class libraries to be hosted on
different versions of a virtual machine, and
Geir Magnusson Jr. wrote:
- what were the architectural goals
- what mistakes made in the past did you try to avoid
- what are the known limitations
- does the interface support our target version of 1.5
Anyone who has experience, please post it here, describing the
particulars
Mladen Turk wrote:
The major problem is the way how the native OS abstraction layer is
called. JNI is used as a single native interface from the ground up
and didn't change much for all those years.
Almost all VMs have their own proprietary non-JNI native method
interface that is much more
Archie Cobbs wrote:
Mladen Turk wrote:
The major problem is the way how the native OS abstraction layer is
called. JNI is used as a single native interface from the ground up
and didn't change much for all those years.
Almost all VMs have their own proprietary non-JNI native method
On Jul 11, 2005, at 11:36 AM, Archie Cobbs wrote:
Geir Magnusson Jr. wrote:
The API is private to the VM implementation, so the only effect
it can
have on application code is how efficient it is.
The API isn't private to the VM implementation, is it? The
_implementation_ of the API
Geir Magnusson Jr. wrote:
The API is private to the VM implementation, so the only effect it can
have on application code is how efficient it is.
The API isn't private to the VM implementation, is it? The
_implementation_ of the API is, but not the API itself - that's a
contract between
Ok, from the school of Storming the Gates! Take 2, lets again
examine the question of VM/classlib interface as this is an important
aspect to address and our first run at it wasn't so successful.
The questions I have are all around the different ways has this been
done. So far we know
Hi,
I also agree,
but I'm trying to find the time to read through all the ClassPath VM
object interfaces and the stub objects to see if I can workout what is
happening currently, especially what the package private methods are
doing. I'm hoping this will make it clear why implementing the
Nor do I disagree...
I /love/ modularity too.
RB
Qui ne dit mot consent
(who tells nothing agrees)
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 09, 2005 7:13 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] VM/Classlibrary
Richard S. Hall wrote:
To me, this is the point. I would like to see all of the libraries built
on to of the JVM to be packaged in a more module-like fashion, so that
their exports and imports are explicit. There would be many benefits if
this were done, rather than relying on the current
Apparently, only you and I agree. ;-)
Dalibor Topic wrote:
Richard S. Hall wrote:
To me, this is the point. I would like to see all of the libraries
built on to of the JVM to be packaged in a more module-like fashion,
so that their exports and imports are explicit. There would be many
On Jun 3, 2005, at 7:18 AM, Peter Edworthy wrote:
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
I agree, but ClassPath has its interface classes in Java.lang
On Jun 3, 2005, at 1:06 PM, Sven de Marothy wrote:
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
By writing _only_ java.lang and java.lang.*,
we can
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
I agree, but ClassPath has its interface classes in Java.lang and while we
can and probably should implement these
-dev@incubator.apache.org
Date: 6/3/05 5:18:47 AM
Subject: Re: [arch] VM/Classlibrary interface
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
I agree
Hello,
And you can circumvent the language protection (package private...)
if you work hard enough too, I believe...
Keeping out of java.lang seems wise if we can arrange it...
By writing _only_ java.lang and java.lang.*,
we can truly speak of a separate implementation.
Adding
Peter, Dan,
Sorry to jump into the middle of the conversation :-)
On Fri, Jun 03, 2005 at 10:40:13AM -0500, Dan Lydick wrote:
Peter,
Some good thinking here. In your _next_ e-mail
you wrote,
How clean are the separations between packages/groups of packages in
ClassPath?
i.e. how
On May 28, 2005, at 11:26 AM, Richard S. Hall wrote:
Ulrich Kunitz wrote:
On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
Well, can't the VM just prevent non-kernel code from using them?
Maybe
overhead too high?
You could play
On May 29, 2005, at 6:35 PM, Peter Edworthy wrote:
Sadly I've left my copy of the Java 2 security model book at work, but
basically my understanding is ClassLoaders restricting access is the
correct solution. It provides the interface independence we are
looking
for, i.e. changes to the
Rodrigo Kumpera wrote:
There is a long track of incompatibilities between JVMs and most of
then are subtle, poor specified behavior. A good example is
java.util.ConcurrentModificationException, this exception is thrown in
a best-effort way by the Collection classes. This means that JVMs will
You could play class loader games, however those could be
circumvented by just another customized class loader.
Doug Lea discussed the general issue in a message to this mailing
list already. IMHO the problem is, that you can make a class only
public, package-private or visible for a single class
Rodrigo Kumpera wrote:
Last time I checked, no one, nether me or you, is developing code agains the
TCK, but to a real JVM. And as hard as we may try, sometimes we end with
software that depends on unspecified behavior. So it's better try to be bug
compatible too.
If you end up with software
Rodrigo Kumpera wrote:
Last time I checked, no one, nether me or you, is developing code agains the
TCK, but to a real JVM. And as hard as we may try, sometimes we end with
software that depends on unspecified behavior. So it's better try to be bug
compatible too.
No, I don't agree on
Tor-Einar Jarnbjo wrote:
Rodrigo Kumpera wrote:
Last time I checked, no one, nether me or you, is developing code
agains the TCK, but to a real JVM. And as hard as we may try,
sometimes we end with software that depends on unspecified behavior.
So it's better try to be bug compatible too.
Ulrich Kunitz wrote:
On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
Well, can't the VM just prevent non-kernel code from using them? Maybe
overhead too high?
You could play class loader games, however those could be
circumvented
On 5/28/05, Dalibor Topic [EMAIL PROTECTED] wrote:
Rodrigo Kumpera wrote:
Last time I checked, no one, nether me or you, is developing code agains
the
TCK, but to a real JVM. And as hard as we may try, sometimes we end with
software that depends on unspecified behavior. So it's better
I think that this is a good topic that many around here have
experience with and can get involved in.
I think that it's not breaking new ground to say that we'll need a
standard interface between the VM and the classlibrary, to let people
integrate the various VMs and class libraries that
Geir == Geir Magnusson [EMAIL PROTECTED] writes:
Geir 4) RMI stuff
On irc Geir said that he meant JNI here.
Basically what this means, I think, is that Classpath has an
implementation of jni.h, but the VM has to provide certain typedefs,
e.g., jint.
Geir 2) Are there things that the GNU
Geir Magnusson Jr. wrote:
2) Core classes implemented by the VM for class-library usage
- standard - things that you expect in java.lang (java.lang.Object)
- non-standard - extension to java.lang (java.lang.VMObject)
3) I was uncomfortable with extending java.lang. I understand the
Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
It doesn't seem so. The SSL code has been in Tomcat versions 4.1.x to
5.5.9 and I just saw that also the LDAP code in Tomcat 5.5.9 uses
classes in com.sun.
Well, can't the VM just prevent non-kernel code from
On May 27, 2005, at 6:25 PM, Tor-Einar Jarnbjo wrote:
Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
It doesn't seem so. The SSL code has been in Tomcat versions 4.1.x
to 5.5.9 and I just saw that also the LDAP code in Tomcat 5.5.9
uses classes in
On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
Well, can't the VM just prevent non-kernel code from using them? Maybe
overhead too high?
You could play class loader games, however those could be
circumvented by just another customized
Geir Magnusson Jr. wrote:
I meant execution context. Is there a clear boundary between code
thats executing in the context of the VM and code that's executing in
the context of the 'user' app?
Usually not, but it might be possible to emulate something similar using
several classloaders
On 5/27/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On May 27, 2005, at 4:34 PM, Rodrigo Kumpera wrote:
We should provide wrappers to classes for the sake of
compatibility. Are
there any legal problems with doing so?
Why would we do that? We don't want to encourage such
60 matches
Mail list logo
