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 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.
