Which classes need to be supplied by any JVM?

[Stephen Colebourne]

I was actually interested in the thrust of the original question, let me 
rephrase it.

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