> "Tim" == Tim Ellison <[EMAIL PROTECTED]> writes:
Tim> I read the description of CNI here:
Tim>http://gcc.gnu.org/onlinedocs/gcj/index.html
Tim> Is there some description of how this looks from the Java side? Are the
Tim> natives declared as CNI natives somehow, or does the VM go throug
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 "
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 discussion
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.
>
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?
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
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 othe
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 des
> "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
Gr
Mark Wielaard <[EMAIL PROTECTED]> wrote on 11/05/2005 05:56:59 AM:
> Hi Rodrigo,
>
> On Fri, 2005-11-04 at 17:53 -0200, Rodrigo Kumpera wrote:
> > I see 2 options here:
> >
> > -Allow for some implementation stuff to package private
> > -Have a org.apache.harmony, or something else, package tree
Darn, I wanted to add one more thing --
Dan's been doing exactly this with the bootjvm code. Subscribing to the commits
list (http://incubator.apache.org/harmony/mailing.html) hence is very
instructive,
if you're looking to get involved but don't know how yet, start reading along ;)
- LSD
On Mo
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! I thought we'd take years :-)
As an aside (I seem
Hi Rodrigo,
On Fri, 2005-11-04 at 17:53 -0200, Rodrigo Kumpera wrote:
> I see 2 options here:
>
> -Allow for some implementation stuff to package private
> -Have a org.apache.harmony, or something else, package tree where all
> implementation stuff will reside.
>
> In the first case, only truste
Hi Geir,
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 have people around here, lurking and active, that have done th
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 ye
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
[EMAIL PROTECTED] wrote:
<>
> 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
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
[EMAIL PROTECTED] wrote:
-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...
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
time to mess with java.lang.Cl
> -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
> "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
--- Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Geir Magnusson Jr. wrote:
[SNIP]
> > 3) I'm really worried about the GNU Classpath
> interface that extends
> > java.lang. We do allow participants in this
> community to look at the
> > spec license, and we won't extend the defined
> namespaces i
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 m
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 muc
25 matches
Mail list logo
