That was probably a stunningly unclear reply. Let me be a little clearer: The list of classes you actually need is not very long. You can grep through the Hotspot code to figure it out. Mostly, it consists of things in java.lang.* and java.lang.*.*.
I'm not a lawyer, but it is my understanding that you can ship whatever you want, as long as you abide by the GPL and don't claim that what you are shipping is "Java". Jeremy On Sat, Aug 22, 2009 at 9:54 AM, Jeremy Manson<jeremyman...@google.com> wrote: > 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----- >>>>>>> >>>>>>> >>> >> >
