Which classes need to be supplied by any JVM?

[Jeremy Manson]

To be fair, it isn't really all that much compared to the size of the
platform.  You can grep through the sources to find out - it is mostly
just the stuff in java.lang.* and java.lang.*.*, with some additional
bits and bobs.

I suspect you can actually do this, too - isn't it fine as long as you
don't call it Java?

Jeremy

On Sat, Aug 22, 2009 at 2:43 AM, Stephen Colebourne<scolebourne at joda.org> wrote:
> Interesting. I guess I'd naively assumed that the 'bytecode engine' would
> have some mechansim of "registering" certain classes to act as the key
> classes it requires. (My hypothetical setup here is the tuned hotspot engine
> but no java.* class files whatsoever)
>
> What we've learnt however is that its going to be very hard to create a
> lightweight platform built on the hotspot JVM. Anyone trying to do this is
> going to need to ship a fair chunk of the Java SE class libraries.
>
> Splitting the Java SE platform like that would also break the JCP/platform
> rules, again making it less likely. Thus, it seems we will always be
> shipping the entire Java SE platform even for a new language that
> essentially wants to use none of it.
>
> I guess that modular Java helps a little bit here in minimising the required
> class file list?
>
> Stephen
>
>
> Jeremy Manson wrote:
>>
>> Even with just a bytecode execution engine, you would need pretty much
>> all of the Throwables in java.lang - NullPointerException,
>> OutOfMemoryError, ArithmeticException, VerifyError, ClassFormatError,
>> IndexOutOfBoundsException and the like.
>>
>> The flip side of "what classes does the VM need" is "what VM support
>> do the classes need".  You can't actually implement a compliant
>> version of Java without special VM support for a bunch of the classes.
>>  You would have to know what all of those requirements were, too.
>>
>> Jeremy
>>
>> On Fri, Aug 21, 2009 at 1:24 AM, David Holmes - Sun
>> Microsystems<David.Holmes at sun.com> wrote:
>>>
>>> Stephen,
>>>
>>> Stephen Colebourne said the following on 08/21/09 18:14:
>>>>
>>>> If you wanted to code from scratch a JVM, but not include the rest of
>>>> the
>>>> Java SE platform (such as the .class files), what would you need to
>>>> include?
>>>> Is Object.class mandatory for a pure JVM? Anything else?
>>>>
>>>> The answers given imply that the JVM is not an isolated well defined
>>>> component. Yet that argues against being able to write a new programming
>>>> language for the JVM that has no integration whatsoever with the Java
>>>> language and just emits 'pure bytecode' for a 'pure JVM'.
>>>
>>> I think you would need to separate the bytecode-engine part of the JVM
>>> from
>>> the "Java runtime platform" part. The bytecode engine has few
>>> dependencies
>>> on classes, perhaps not even Object, while the runtime environment has
>>> many
>>> dependencies.
>>>
>>> David Holmes
>>>
>>>> I, like Carsten, find it odd if this isn't well-defined.
>>>>
>>>> Stephen
>>>>
>>>> David Holmes - Sun Microsystems wrote:
>>>>>
>>>>> As Martin stated what you are looking for is not part of the JVMS nor
>>>>> the
>>>>> JLS, but the platform specification, which is essentially the entire
>>>>> set of
>>>>> Java API's as found for example here:
>>>>>
>>>>> http://java.sun.com/javase/6/docs/index.html
>>>>>
>>>>> But the implementation of those classes will then have dependencies on
>>>>> other implementation specific classes, so I'm not sure that you will be
>>>>> able
>>>>> to establish a transitive closure of required classes that is
>>>>> independent of
>>>>> the JVM in question.
>>>>>
>>>>> If you were thinking about this from a basic language perspective - eg
>>>>> we
>>>>> must have Object, and we must have Class, and array implies
>>>>> Serializable
>>>>> etc, then there is a core set of classes that form the transitive
>>>>> closure of
>>>>> the JVM bootstrap process. If you are interested in that then
>>>>> -XX:+TraceClassLoading (might need a debug VM) will give you the set
>>>>> used by
>>>>> a particular VM. But again this list is dependent on how those classes
>>>>> are
>>>>> implemented themselves, so the list is JVM dependent.
>>>>>
>>>>> HTH
>>>>>
>>>>> David Holmes
>>>>>
>>>>> Martin Buchholz said the following on 08/21/09 03:32:
>>>>>>
>>>>>> The set of all public APIs that must be part of the java se platform
>>>>>> are tested by the platform tck, in particular by the "signature test",
>>>>>> and you can get the sources for that test (for research only)
>>>>>> and from that it should be possible (with work) to get a list of
>>>>>> all required classes.  But that's a very large list, so is probably
>>>>>> not
>>>>>> what you want.  In practice, the subset of rt.jar of public classes
>>>>>> matching java.* or javax.* is a pretty good approximation.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On Thu, Aug 20, 2009 at 08:26, Carsten Otto
>>>>>> <otto at informatik.rwth-aachen.de
>>>>>> <mailto:otto at informatik.rwth-aachen.de>>
>>>>>> wrote:
>>>>>>
>>>>>>   Hello,
>>>>>>
>>>>>>   I am working on automated termination analysis of Java Bytecode and
>>>>>> I
>>>>>> am
>>>>>>   missing an important bit of information in the Java Virtual Machine
>>>>>>   Specification (JVMS). I'd be happy to get some help from you!
>>>>>>
>>>>>>   Every JVM needs to provide certain classes including code for their
>>>>>>   native
>>>>>>   methods, e.g. java.lang.Object (obvious) and java.io.Serializable
>>>>>>   (because
>>>>>>   every array implements it). The list of such classes can easily be
>>>>>>   extended, but I have huge problems finding a lower bound to keep
>>>>>>   this list
>>>>>>   as small[1] as allowed according to the JVMS.
>>>>>>
>>>>>>   Is there some part of the specification that states which classes
>>>>>>   need to
>>>>>>   be provided? I can only see references to the API (e.g. "reflective
>>>>>>   APIs"),
>>>>>>   but no clear definition of the classes that need to exist. In the
>>>>>>   current
>>>>>>   draft for JVMS 3rd edition, the necessity to include
>>>>>>   java.io.Serializable
>>>>>>   is not even part of the JVMS, this is only visible by looking at the
>>>>>>   definition of arrays in the Java Language Specification (JLS).
>>>>>>
>>>>>>   Some hints in this direction are also appreciated. So far I can only
>>>>>>   guess,
>>>>>>   that sun.awt.* is not part of the language defined in the JVMS - but
>>>>>> who
>>>>>>   knows?
>>>>>>
>>>>>>   [1]: Sadly, just using whatever Sun or OpenJDK provide in rt.jar
>>>>>>   does not
>>>>>>   work.
>>>>>>
>>>>>>   Thanks a lot,
>>>>>>   --
>>>>>>   Carsten Otto           otto at informatik.rwth-aachen.de
>>>>>>   <mailto:otto at informatik.rwth-aachen.de>
>>>>>>   LuFG Informatik 2      http://verify.rwth-aachen.de/otto/
>>>>>>   RWTH Aachen            phone: +49 241 80-21211
>>>>>>
>>>>>>   -----BEGIN PGP SIGNATURE-----
>>>>>>   Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>
>>>>>>   iEYEARECAAYFAkqNaygACgkQjUF4jpCSQBTSEwCaA+MU0U73Cx1QS3Mgvr/6ZRET
>>>>>>   4vcAnicKi99CFGZe1kE+jcUXD3bz9m4J
>>>>>>   =Brg8
>>>>>>   -----END PGP SIGNATURE-----
>>>>>>
>>>>>>
>>
>