harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Date Sun, 05 Jun 2005 17:14:21 GMT
>>>>> "Geir" == Geir Magnusson <geirm@apache.org> writes:

>> What do you mean by "extending java.lang"? GNU Classpath does not
>> extend java.lang (for any reasonable definition of extend). Having
>> package private classes is not extending.

Geir> Why do you say that?   Suppose for J2SE 6, the EG adds the public
Geir> class java.lang.VMObject.  then what?

I already explained how this can't cause a user-visible problem.
Maybe you could explain what problem you see arising.


As I see it there are a few cases here:

* Someone takes code that uses this 1.6 feature and:

  1. Compiles it against our library.
     -> this fails as our VMObject is package-private
     -> This is no different from using any other unimplemented class

  2. Compiles it against 1.6 and runs it against our library
     -> this fails as our VMObject is package-private
     -> This is no different from using any other unimplemented class

* Someone takes a part of our java.lang, which uses our VMObject, and
  runs them on a 1.6 VM
  -> Yes, this fails.  But this is not supported either upstream
  (there is no supported way to override parts of the class library,
  other than those parts mentioned in the endorsed dirs spec) or by
  us (since it is a silly thing to do)

* Note that user code can't use our VMObject as it is not user-visible

Renaming our VMObject in our next release causes no problems for any
code.  The VMs have to change, but then the VMs have to change with
each major release anyway, since ordinarily new features are added
which require new VM glue.

Tom

Mime
View raw message