You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/11/04 17:24:06 UTC
VM/Class Library Interface (or "Storming the Gates! Take 3!")
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 much as
I am going to miss the process creation phase, it's time to get focused.
1) I didn't look at how jcheVM does it - although I assume that it
uses the canonical GNU Classpath approach - and I'm not sure that
bootVM code is there yet for that. I hope that Archie and Dan can
chime in with a summary of where things are.
2) I'm really interested in interoperability with other projects, so
however we do it, it should have this factor as one of the major
design goals.
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 in the spec.
So where does that leave us? We'll, IMO it means we don't use the
GNU Classpath interface as it is now (but I'd want to be sure that we
do interoperate, so that means whatever we come up with we also
contribute to GNU Classpath so people can plug that in....). We have
people around here, lurking and active, that have done this in anger,
so speak up...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 and why you thought it
>> didn't
>> go well?
>>
>>> We have people around here, lurking and active, that have done
>>> this in anger,
>>> so speak up...
>>
>> Did you study the VM Integration Guide:
>> http://www.gnu.org/software/classpath/docs/vmintegration.html
>> We have updated and clarified it and if you read the NEWS file we
>> distribute with every release you will see updates and requests for
>> feedback on various parts. See the latest release or:
>> http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/NEWS?
>> rev=HEAD
>> (Look under the headings "Runtime interface changes:")
>>
>> There are more then 20 different compiler/runtime/tools projects that
>> use this for various different situations be it interpreter, jit,
>> ahead
>> of time compilers, real time, or byte code transformation
>> frameworks. I
>> am sure it can be refined and improved (since we do that for every
>> release), but it should be very flexible already. Please give
>> feedback.
>
> Please do try to answer these questions. It would be instructive if
> you
> could explain this in some detail since I am not sure we hit the right
> technical spot yet with respect to your suggestions for
> improvements to
> the model we are currently using. And you seem to have the feeling
> that
> take 1 and 2 didn't go well and I do like to know what I missed back
> then.
Me too :)
I'll review and try to post something later this week.
g
eir
>
> Thanks,
>
> Mark
>
> --
> Escape the Java Trap with GNU Classpath!
> http://www.gnu.org/philosophy/java-trap.html
>
> Join the community at http://planet.classpath.org/
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Mark Wielaard <ma...@klomp.org>.
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 have people around here, lurking and active, that have done this in anger,
> > so speak up...
>
> Did you study the VM Integration Guide:
> http://www.gnu.org/software/classpath/docs/vmintegration.html
> We have updated and clarified it and if you read the NEWS file we
> distribute with every release you will see updates and requests for
> feedback on various parts. See the latest release or:
> http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/NEWS?rev=HEAD
> (Look under the headings "Runtime interface changes:")
>
> There are more then 20 different compiler/runtime/tools projects that
> use this for various different situations be it interpreter, jit, ahead
> of time compilers, real time, or byte code transformation frameworks. I
> am sure it can be refined and improved (since we do that for every
> release), but it should be very flexible already. Please give feedback.
Please do try to answer these questions. It would be instructive if you
could explain this in some detail since I am not sure we hit the right
technical spot yet with respect to your suggestions for improvements to
the model we are currently using. And you seem to have the feeling that
take 1 and 2 didn't go well and I do like to know what I missed back
then.
Thanks,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Mark Wielaard <ma...@klomp.org>.
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 this in anger,
> so speak up...
Did you study the VM Integration Guide:
http://www.gnu.org/software/classpath/docs/vmintegration.html
We have updated and clarified it and if you read the NEWS file we
distribute with every release you will see updates and requests for
feedback on various parts. See the latest release or:
http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/NEWS?rev=HEAD
(Look under the headings "Runtime interface changes:")
There are more then 20 different compiler/runtime/tools projects that
use this for various different situations be it interpreter, jit, ahead
of time compilers, real time, or byte code transformation frameworks. I
am sure it can be refined and improved (since we do that for every
release), but it should be very flexible already. Please give feedback.
Thanks,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Graeme" == Graeme Johnson <Gr...@ca.ibm.com> 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> delivers simpler code and shorter call-paths as it avoids the need for
Graeme> any runtime redirection.
Graeme> Also, if you ever need to change class shape (e.g. add an extra long
Graeme> field to point at a C structure) you're basically forced into the
Graeme> customized-class solution. Why not stick to one technique?
FWIW we continue to do both approaches in Classpath -- different VMs
do different things. In particular in gcj we replace some of the core
classes like Class and String with our own versions. The difficulty
here is that bug fixes to the shared code must be manually merged.
This turns out to be more work than we originally thought it would be;
in general these days I try to push us to follow Classpath more
closely for this reason.
Tom
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Tim" == Tim Ellison <t....@gmail.com> 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 through the
Tim> regular JNI dispatch (building a JNIEnv, function name mangling etc) to
Tim> call the CNI method. Once in the native code I see how the unified
Tim> object model works.
The java side is plain old java, with the 'native' modifier for a
native method.
The choice of CNI or JNI is made at compile time. The default is
CNI, you pass gcj the '-fjni' flag when generating object code to
request JNI. -fjni causes gcj to emit special JNI-calling stubs -- the
calling convention everywhere is CNI-ish, these stubs do the required
translation (and call into libgcj to do the runtime linking required
by JNI).
The libgcj interpreter can only use JNI. So, there is no need to
solve the "what does 'native' mean at runtime?" problem.
Tim> How does the existence of this calling convention affect the choice of
Tim> kernel types? I agree there will be different characteristics for
Tim> kernel types written in JNI, CNI or Java, but since we agree that the
Tim> replacement is at a Java class level then I don't yet see how this is so
Tim> relevant.
Yeah, CNI is largely orthogonal to, say, where the 'native' keyword
appears in the Classpath sources. Generally speaking in libgcj we
used to use native pretty liberally -- where ever it made life more
convenient. The folks usually pushing a more strict separation into
'VM' classes are those with nontraditional VMs, where native has a
different meaning, i.e. IKVM, or Jaos, or the oberon-based VM (I
forgot the name of that one, sorry).
Tom
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tim Ellison <t....@gmail.com>.
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: new VM interface for Socket impls")
Thanks for the pointer -- I read the thread and still think that whether
the VM classes are a customized class replacement or a customized class
delegate makes little difference.
> To give you a quickstart let me explain the design criteria. The VM
> interface class has to be high-level enough to be usable/optimizable for
> a runtime that doesn't use C/Posix/JNI (as preferred platform/runtime
> interface).
Sure.
> GCJ for example uses CNI which provides a ABI bridge between
> c++ and java classes (which has a completely different performance
> trade-off then JNI. Class field accesses are cheap with CNI since they
> are just direct references, while in JNI they are expensive). IKVM.NET
> for example would wrap the System.Net.Sockets classes to implement the
> above VM interface.
I read the description of CNI here:
http://gcc.gnu.org/onlinedocs/gcj/index.html
Is there some description of how this looks from the Java side? Are the
natives declared as CNI natives somehow, or does the VM go through the
regular JNI dispatch (building a JNIEnv, function name mangling etc) to
call the CNI method. Once in the native code I see how the unified
object model works.
How does the existence of this calling convention affect the choice of
kernel types? I agree there will be different characteristics for
kernel types written in JNI, CNI or Java, but since we agree that the
replacement is at a Java class level then I don't yet see how this is so
relevant.
> Besides that there has to be at least one concrete
> vm/reference implementation based on C/Posix/JNI (which is hopefully
> properly autoconfed to make it portable across most modern GNU/Unix-like
> platforms). This reference implementation should in principle work out
> of the box for runtimes implementing JNI and that don't want to make any
> specific platform/runtime optimizations.
Right, and I'm guessing that the CNI is equally applicable in any area
of the class library that uses native code, so people are free to choose
JNI or CNI at any place (assuming gcj/G++).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Tim,
On Wed, 2005-11-09 at 14:14 +0000, 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 completely. I think they complement each other. The ClassX &
> > VMClassX split describes at a high (java) level what the
> > responsibilities of an runtime/execution-model are. Then the VMClasses
> > are more like the customized-class solutions in case you have a
> > traditional execution-model that is based on JNI/Posix like platforms.
>
> I'm assuming that ClassX and VMClassX are quite closely coupled, so that
> other types in the package don't make internal API calls on VMClassX
> directly? If that is true it's also worth pointing out that the (ClassX
> + VMClassX) combination will simply look like a kernel version of ClassX
> to the rest of the classlibrary code -- it's a pretty minor difference
> at that level.
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: new VM interface for Socket impls")
To give you a quickstart let me explain the design criteria. The VM
interface class has to be high-level enough to be usable/optimizable for
a runtime that doesn't use C/Posix/JNI (as preferred platform/runtime
interface). GCJ for example uses CNI which provides a ABI bridge between
c++ and java classes (which has a completely different performance
trade-off then JNI. Class field accesses are cheap with CNI since they
are just direct references, while in JNI they are expensive). IKVM.NET
for example would wrap the System.Net.Sockets classes to implement the
above VM interface. Besides that there has to be at least one concrete
vm/reference implementation based on C/Posix/JNI (which is hopefully
properly autoconfed to make it portable across most modern GNU/Unix-like
platforms). This reference implementation should in principle work out
of the box for runtimes implementing JNI and that don't want to make any
specific platform/runtime optimizations.
> >>Of the two approaches I believe that the customized-class solution
> >>delivers simpler code and shorter call-paths as it avoids the need for
> >>any runtime redirection.
> >
> > 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 out is that the JIT will roll the code
> defined in two classes into the moral-equivalent of one class anyway ;-)
>
> Most JITs will do the method inlining out of the box, and the same thing
> could happen for storage too if the VM/JIT is aware of the pattern --
> the VM/JIT could allocate storage for the common code and delegate
> contiguously; and make that assumption. Without such an awareness you
> would require two objects, with a read-barrier to access the delegate,
> and may suffer from data locality probs if they end up miles apart.
Yes, but note that not all free runtimes/compilers do this class/vmclass
inlining yet (gcj for example doesn't do it and the various interpreters
also don't do it). And except in some contrived micro-benchmarks it
doesn't even seem to show up in the profiling data. So it is an
optimization to keep in mind because it could impact performance, but it
isn't the first optimization you need to implement to get good
performance in most real world applications (except probably for
Object/VMObject and Class/VMClass but those are often handled specially
inside the runtime/execution mechanism anyway).
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 out is that the JIT will roll the code
> defined in two classes into the moral-equivalent of one class
> anyway ;-)
<joke>
Now, if this is GPL-ed code, wouldn't that be a derivative work, thus
requiring the entire application to be re-licensed under the GPL?
</joke>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tim Ellison <t....@gmail.com>.
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 ClassX &
> VMClassX split describes at a high (java) level what the
> responsibilities of an runtime/execution-model are. Then the VMClasses
> are more like the customized-class solutions in case you have a
> traditional execution-model that is based on JNI/Posix like platforms.
I'm assuming that ClassX and VMClassX are quite closely coupled, so that
other types in the package don't make internal API calls on VMClassX
directly? If that is true it's also worth pointing out that the (ClassX
+ VMClassX) combination will simply look like a kernel version of ClassX
to the rest of the classlibrary code -- it's a pretty minor difference
at that level.
>>Of the two approaches I believe that the customized-class solution
>>delivers simpler code and shorter call-paths as it avoids the need for
>>any runtime redirection.
>
>
> 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 out is that the JIT will roll the code
defined in two classes into the moral-equivalent of one class anyway ;-)
Most JITs will do the method inlining out of the box, and the same thing
could happen for storage too if the VM/JIT is aware of the pattern --
the VM/JIT could allocate storage for the common code and delegate
contiguously; and make that assumption. Without such an awareness you
would require two objects, with a read-barrier to access the delegate,
and may suffer from data locality probs if they end up miles apart.
[thinking aloud:
I don't think you could use subclassing to solve the problem, since if
the common code is declared as the supertype (Object>Thread>VMThread)
applications would need to call the constructor on the VM-type, and if
it was the other way around (Object>VMThread>Thread) that would break
the spec. for the common type.]
>>In either case I think we want to determine how to build customized
>>versions of a reference implementation without resorting to cut'n'paste
>>duplication. IMO making the build process responsible for creating
>>customized versions of VM-dependent classes from a master version puts
>>the complexity in the right place (build-time vs runtime).
>
>
> Yes, that is mostly how it works with GNU Classpath based runtimes. At
> build time each runtime overrides/changes the few VMClasses for which it
> cannot use the vm/reference version. This seems to work nicely and makes
> it possible to share almost all of the glibj.zip classes as is.
I'd claim that we both have the same goals of a small set of customized
types. One solution was formulated at build-time and the other at
runtime. Seems like a small distinction though, and the interop is
simple enough.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Mark Wielaard <ma...@klomp.org>.
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 describes at a high (java) level what the
responsibilities of an runtime/execution-model are. Then the VMClasses
are more like the customized-class solutions in case you have a
traditional execution-model that is based on JNI/Posix like platforms.
> Of the two approaches I believe that the customized-class solution
> delivers simpler code and shorter call-paths as it avoids the need for
> any runtime redirection.
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.
> In either case I think we want to determine how to build customized
> versions of a reference implementation without resorting to cut'n'paste
> duplication. IMO making the build process responsible for creating
> customized versions of VM-dependent classes from a master version puts
> the complexity in the right place (build-time vs runtime).
Yes, that is mostly how it works with GNU Classpath based runtimes. At
build time each runtime overrides/changes the few VMClasses for which it
cannot use the vm/reference version. This seems to work nicely and makes
it possible to share almost all of the glibj.zip classes as is.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Graeme Johnson <Gr...@ca.ibm.com>.
Mark Wielaard <ma...@klomp.org> 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 where all
> > implementation stuff will reside.
> >
> > In the first case, only trusted code will be allowed to access such
> > code by using reflection. Otherwise the SecurityManager will stop it.
> >
> > In the second case, we will need some classloading hacks to forbid
> > application code to access public classes on the org.apache.harmony
> > tree.
>
> Indeed. And it is most convenient to use both. You use the first (VM
> package private classes) when you need to have a tight coupling between
> the helper/vm class and the public implementation class. You use the
> second if you only need a helper class that doesn't need tight coupling
> with the public implementation class.
[snip]
The VM will always have representation dependencies on a small portion of
the class library. I think that most of us would agree that keeping the
the number of these classes to a minimum benefits all VM implementers.
Given that we need these classes the challenge becomes:
#1) Giving VM implementers the ability to modify class shape and
customize individual methods without copying a ton of boilerplate
Java code around.
#2) While minimizing runtime cost and complexity.
Split-class (ClassX & VMClassX) or customized-class solutions (Tim E's
Kernel classes) are different approaches to solving the same problem.
Of the two approaches I believe that the customized-class solution
delivers simpler code and shorter call-paths as it avoids the need for
any runtime redirection.
Also, if you ever need to change class shape (e.g. add an extra long
field to point at a C structure) you're basically forced into the
customized-class solution. Why not stick to one technique?
In either case I think we want to determine how to build customized
versions of a reference implementation without resorting to cut'n'paste
duplication. IMO making the build process responsible for creating
customized versions of VM-dependent classes from a master version puts
the complexity in the right place (build-time vs runtime).
Graeme Johnson
J9 VM Team, IBM Canada.
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Mark Wielaard <ma...@klomp.org>.
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 trusted code will be allowed to access such
> code by using reflection. Otherwise the SecurityManager will stop it.
>
> In the second case, we will need some classloading hacks to forbid
> application code to access public classes on the org.apache.harmony
> tree.
Indeed. And it is most convenient to use both. You use the first (VM
package private classes) when you need to have a tight coupling between
the helper/vm class and the public implementation class. You use the
second if you only need a helper class that doesn't need tight coupling
with the public implementation class. As it turns out you don't need
class loader hacks to forbid "application code" to access these public
classes. A user defined class loader loadClass() method needs to handle
SecurityManager.checkPackageAccess() when a security manager is
installed. And since any class can only access another class through
loading the class directly or indirectly through its own class loader
this can be used to deny any access to classes not loaded by the
bootstrap class loader. See the GNU Classpath ClassLoader
createSystemClassLoader() method for an example of how this works.
See the various classes in vm/reference for examples of the first. The
gnu.classpath package contains some of the "public but inaccessible"
classes like StackWalkers, System property accessors, etc.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tim Ellison <t....@gmail.com>.
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
> time to mess with java.lang.ClassLoader insternals, but
> java.lang.ClassLoaderStuff won't).
>
> I see no point in been nicer than Sun on this matter, as there are
> many package private classes around java.* - nice guys finish last ;-)
>
> 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 trusted code will be allowed to access such
> code by using reflection. Otherwise the SecurityManager will stop it.
>
> In the second case, we will need some classloading hacks to forbid
> application code to access public classes on the org.apache.harmony
> tree.
We'll just talk to the guys in Felix :-)
Regards,
Tim
> Given a full j2se implementation, which one will require less effort
> and code to be running ok?
>
> Rodrigo
>
>
>
>
> On 11/4/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>>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 much as
>>I am going to miss the process creation phase, it's time to get focused.
>>
>>1) I didn't look at how jcheVM does it - although I assume that it
>>uses the canonical GNU Classpath approach - and I'm not sure that
>>bootVM code is there yet for that. I hope that Archie and Dan can
>>chime in with a summary of where things are.
>>
>>2) I'm really interested in interoperability with other projects, so
>>however we do it, it should have this factor as one of the major
>>design goals.
>>
>>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 in the spec.
>>
>>
>>So where does that leave us? We'll, IMO it means we don't use the
>>GNU Classpath interface as it is now (but I'd want to be sure that we
>>do interoperate, so that means whatever we come up with we also
>>contribute to GNU Classpath so people can plug that in....). We have
>>people around here, lurking and active, that have done this in anger,
>>so speak up...
>>
>>geir
>>
>>--
>>Geir Magnusson Jr +1-203-665-6437
>>geirm@apache.org
>>
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Rodrigo Kumpera <ku...@gmail.com>.
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.ClassLoader insternals, but
java.lang.ClassLoaderStuff won't).
I see no point in been nicer than Sun on this matter, as there are
many package private classes around java.* - nice guys finish last ;-)
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 trusted code will be allowed to access such
code by using reflection. Otherwise the SecurityManager will stop it.
In the second case, we will need some classloading hacks to forbid
application code to access public classes on the org.apache.harmony
tree.
Given a full j2se implementation, which one will require less effort
and code to be running ok?
Rodrigo
On 11/4/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> 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 much as
> I am going to miss the process creation phase, it's time to get focused.
>
> 1) I didn't look at how jcheVM does it - although I assume that it
> uses the canonical GNU Classpath approach - and I'm not sure that
> bootVM code is there yet for that. I hope that Archie and Dan can
> chime in with a summary of where things are.
>
> 2) I'm really interested in interoperability with other projects, so
> however we do it, it should have this factor as one of the major
> design goals.
>
> 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 in the spec.
>
>
> So where does that leave us? We'll, IMO it means we don't use the
> GNU Classpath interface as it is now (but I'd want to be sure that we
> do interoperate, so that means whatever we come up with we also
> contribute to GNU Classpath so people can plug that in....). We have
> people around here, lurking and active, that have done this in anger,
> so speak up...
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Archie Cobbs <ar...@dellroad.org>.
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 implemented in Classpath.
>
> There would be a namespace collision though (I'd guess the risk is small
> tho')
Not an issue: code that relies on Sun's new class wouldn't compile
or run properly with the yet-to-be updated Classpath in either case!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tim Ellison <t....@gmail.com>.
Tom Tromey wrote:
>>>>>>"Matt" == Matt Benson <gu...@yahoo.com> 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
>>>public consumption.
>
>
> 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 implemented in Classpath.
There would be a namespace collision though (I'd guess the risk is small
tho')
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Matt" == Matt Benson <gu...@yahoo.com> 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
>> public consumption.
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 implemented in Classpath.
Tom
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Matt Benson <gu...@yahoo.com>.
--- Archie Cobbs <ar...@dellroad.org> 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 in the spec.
>
> 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 public
> consumption.
Wasn't one of the issues here the theoretical "What
happens when Sun defines a public VMClass class in
java.lang?"
-Matt
>
> -Archie
>
>
__________________________________________________________________________
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Posted by Archie Cobbs <ar...@dellroad.org>.
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 much as I am going
> to miss the process creation phase, it's time to get focused.
>
> 1) I didn't look at how jcheVM does it - although I assume that it
> uses the canonical GNU Classpath approach - and I'm not sure that
> bootVM code is there yet for that. I hope that Archie and Dan can
> chime in with a summary of where things are.
Right now I'm working on getting jchevm to work with a completely
"stock" unmodified version of Classpath. Then it won't need to contain
any modified versions of Classpath source files.
> 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 in the spec.
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 public consumption.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com