java.lang.IllegalStateException in getSavedProperty when properties is empty

[David Holmes]

Hi Max,

On 9/09/2016 3:40 AM, Max Schulze wrote:
> Hello,
>
> I am trying to implement my own virtual machine and making use of the
> rt.jar .

Difficult, because rt.jar is not a stand-alone implementation that can 
be mixed-and-matched with arbitrary VMs. The initialization sequence is 
very intricate and delicate and tightly coupled between the VM and the 
core classes involved. The Java classes know about specific VM entry 
points, and the VM knows about specific Java classes and methods 9and 
exactly what they do).

> I am following the language and vm specification and currently have not
> come across formalities that require implementation/prefill of
> java.lang.System*props.
>
>
> When the IntegerCache is being initialized, it calls getSavedProperty
> which doesn't like savedProps.isEmpty() at all
> (jdk/src/share/classes/sun/misc/VM.java:255) and throws the exception
> java.lang.IllegalStateException.
>
>
> 1) What are the minimal properties that have to be initialized for the
> runtime to be functioning? I found sun.misc.Version.init(), but is there
> any specification of what the bare minimum would be?

All of the properties specified as standard properties in the 
System.getProperties() method are supposed to be pre-filled to comply 
with the platform specification.

> 2) There is a function initializeSystemClass()
> (jdk/src/share/classes/java/lang/System.java:1152) that calls
> initProperties(props).  This will be called by the JVM at
>
>> hotspot/src/share/vm/runtime/thread.cpp:1048:
>> JavaCalls::call_static(&result, klass,
>> vmSymbols::initializeSystemClass_name(),
>
> Shouldn't it be part of the JVM Specification to call this
> initializeSystemClass on thread setup then, if at all it wants to be
> able to run the rt.jar?

No because this is just an implementation artifact of The OpenJDK 
implementation of the Java platform specifications.

The initialization dance between the VM and library code is even more 
intricate in JDK 9 with the new module system.

David
-----

>
> Thanks,
>
> Max
>
> PS : talking about 1.8.0_91
>
>
> (On a side-note, there is activity around moving sun.misc.VM to
> jdk.internal.misc for JEP 260/JDK9, but which doesn't change above
> mentioned problems)
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037853.html
>