Mark Wielaard wrote:
Right. It might be instructive to participate in the discussion started
this week about the newly proposed network VM interface classes
suggested by Ingo and Roman on the classpath-patches mailinglist.
http://lists.gnu.org/mailman/listinfo/classpath-patches
(Subject RFC:
On Nov 12, 2005, at 10:23 AM, Mark Wielaard wrote:
Hi Geir,
On Sat, 2005-11-05 at 11:56 +0100, Mark Wielaard wrote:
On Fri, 2005-11-04 at 11:24 -0500, Geir Magnusson Jr. wrote:
We have to address this. We started a while ago and it didn't go
well
Could you give a summary of the
Hi Geir,
On Sat, 2005-11-05 at 11:56 +0100, Mark Wielaard wrote:
On Fri, 2005-11-04 at 11:24 -0500, Geir Magnusson Jr. wrote:
We have to address this. We started a while ago and it didn't go
well
Could you give a summary of the discussion and why you thought it didn't
go well?
We
Hi Tim,
On Wed, 2005-11-09 at 14:14 +, Tim Ellison wrote:
Mark Wielaard wrote:
On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote:
Split-class (ClassX VMClassX) or customized-class solutions (Tim E's
Kernel classes) are different approaches to solving the same problem.
Not
Hi Graeme,
On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote:
Split-class (ClassX VMClassX) or customized-class solutions (Tim E's
Kernel classes) are different approaches to solving the same problem.
Not completely. I think they complement each other. The ClassX
VMClassX split
Mark Wielaard wrote:
Hi Graeme,
On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote:
Split-class (ClassX VMClassX) or customized-class solutions (Tim E's
Kernel classes) are different approaches to solving the same problem.
Not completely. I think they complement each other. The
On Nov 9, 2005, at 9:14 AM, Tim Ellison wrote:
Mark Wielaard wrote:
That can be an issue indeed. But by marking the VMClasses package
private and final (or just have list in the jit/compiler) all
calls to
them should be able to be optimized away if needed.
Agreed. What you are pointing
Graeme == Graeme Johnson [EMAIL PROTECTED] writes:
Graeme Split-class (ClassX VMClassX) or customized-class solutions (Tim E's
Graeme Kernel classes) are different approaches to solving the same problem.
Graeme Of the two approaches I believe that the customized-class solution
Graeme
On Fri, Nov 04, 2005 at 10:50:33AM -0600, [EMAIL PROTECTED] wrote:
I've been evaluating Jean-Frederic's configuration proposal and finishing up
on the core JVM code. I should have a _complete_ code base by the end of
next week.
Whoah, cool! jokeI thought we'd take years/joke :-)
As an aside
My favorite subject...
We have to address this. We started a while ago and it didn't go
well, but we now have two VMs to work with, bootVM and jcheVM, and we
need to get going here in a serious way. We're about to finish up
the legal framework with the bulk contributuion rules, and as
Geir Magnusson Jr. wrote:
We have to address this. We started a while ago and it didn't go well,
but we now have two VMs to work with, bootVM and jcheVM, and we need to
get going here in a serious way. We're about to finish up the legal
framework with the bulk contributuion rules, and as
Matt == Matt Benson [EMAIL PROTECTED] writes:
I don't understand this (sorry if I wasn't paying attention
earlier). If extend means defining public API's in those
packages, then Classpath doesn't purport to do that. The
java.lang.VMClass, etc. stuff are all internal API's not meant for
-Original Message-
From: Geir Magnusson Jr. [EMAIL PROTECTED]
Sent: Nov 4, 2005 10:24 AM
To: harmony-dev@incubator.apache.org
Subject: VM/Class Library Interface (or Storming the Gates! Take 3!)
My favorite subject...
... snip...
1) I didn't look at how jcheVM does
Tom Tromey wrote:
Matt == Matt Benson [EMAIL PROTECTED] writes:
I don't understand this (sorry if I wasn't paying attention
earlier). If extend means defining public API's in those
packages, then Classpath doesn't purport to do that. The
java.lang.VMClass, etc. stuff are all internal API's
[EMAIL PROTECTED] wrote:
snip
Probably the _first_ thing that will need to be tested will be the built-in
implementations
of the java.lang classes Object, Class, String, and Thread. They are partly
done, but
will need to be tested and any remaining holes filled in. (See also comments
Rodrigo Kumpera wrote:
I cannot see how adding package private classes can possibly be
classified as 'extend the defined namespaces'. This makes perfect
sense and allow implementation classes easier access the guts of spec
classes (eg, org.apache.harmony.ClassLoaderStuff will have some hard
Tim Ellison wrote:
Matt Wasn't one of the issues here the theoretical What
Matt happens when Sun defines a public VMClass class in
Matt java.lang?
There's no bad (i.e., security violating) situation that can arise
from this. It is no different from Sun adding any other class that is
not yet
17 matches
Mail list logo
