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