Hi Kelly, On Mon, 2010-11-29 at 14:44 -0800, Kelly O'Hair wrote: > Need reviewers and comments: > 6989472: Provide simple jdk identification information in the > install image > http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release/webrev/
CCing distro-pkg-dev since we were recently discussing runtime identification on irc wrt the various IcedTea supported runtimes (hotspot client, server, zero, shark and cacao). > With JDK6 Updates we purposely resisted many rebranding changes that > could impacted > customers, however at one point we had accidently changed the Windows > DLL/EXE > COMPANY value thinking that no one would be looking at it. > We were wrong and this change cause Eclipse failures, so we are > looking for a solution, see: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=321390 > So we went back and change JDK6 Updates back the way it was, and > learned a valuable lesson. > > But we have and will change JDK7 in this regard, so we wanted a better > way for an app to > know what it had it's hands on without using platform specific > information in the binary files. > > The above change creates a small text file called "jdk.release" at the > top of the install image > with some basic values that could help direct any app using the jdk in > constructing a command > line or even being assured that this jdk install image will even work > on your existing system. > In the Eclipse case it was looking for "Sun", but I suspect it really > wanted to know if the VM was > "Hotspot" because I think it was trying to set a Hotspot specific > PermGen option. If so, then I would leave out the confusing vendor strings from the jdk.release file. Because that isn't what people want to know. And might reintroduce the confusion. The os, arch, version of class library and runtime is what is selected on. Maybe this should be extended with the versions of jaxp, jaxws, corba and langtools that are included. > In any case I think this jdk.release file should provide the necessary > answers in the future. But I don't think this is specific enough yet. Hotspot comes in some variants (at least server and client), which might or might not be available on the platform. You can know which ones if you look at the jre/lib/<arch>/jvm.cfg file. [IcedTea then extends this with shark, zero, cacao as alternatives]. The problem with that approach is that to get at this file you need to know the arch mapping/dir in use. Would it be possible to somehow merge or at least reference the jvm.cfg file with/in the jdk.release file? > The make variable COMPANY_NAME determines the vendor name during a > build, > so a Linux 64bit build from a make command line like: > make COMPANY_NAME="Test Company Name" > should result in a jdk.release file that looks something like: > > os.name = Linux > os.version = 2.6 > os.arch = amd64 > java.vendor = Test Company Name > java.version = 1.7.0-internal > java.vm.vendor = Test Company Name > java.vm.name = Hotspot(TM) > java.vm.version = 20.0-b02 > > A formal Oracle jdk7 EA build on Linux 64bit should look something like: > > os.name = Linux > os.version = 2.6 > os.arch = amd64 > java.vendor = Oracle Corporation > java.version = 1.7.0-ea > java.vm.vendor = Oracle Corporation > java.vm.name = Hotspot(TM) > java.vm.version = 20.0-b02 > > Comments are welcome. Although, polite constructive comments are > probably more what I'd like to see. ;^)
