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.hol...@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 >>>> <o...@informatik.rwth-aachen.de <mailto:o...@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 o...@informatik.rwth-aachen.de >>>> <mailto:o...@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----- >>>> >>>> >>> >
