Why does this code compile, but with runtime ClassNotFoundException?

Question

I have some code that uses the proprietary sun.*.OperatingSystemMXBean, so I was being careful with it.

try {
    _osBean = (com.sun.management.OperatingSystemMXBean) java.lang.management.ManagementFactory.getOperatingSystemMXBean();
}
catch (ClassCastException e) {
    _osBean = null;
}

However, when this code runs on an IBM JVM, instead of ClassCastException, I get a runtime ClassNotFoundException. Why is this code able to compile just fine if that class is not available and how does a JVM affect something like this?

I suppose it can happen if you compile it with an oracle compiler and run it on IBM JVM. — assylias, Jan 04 '13 at 17:33
@fge - strong words. I would rather say that you have to be careful, understand your deployment environment and fall back gracefully whenever possible — Brian Agnew, Jan 04 '13 at 17:37
@fge - unfortunately sometimes youre left with no other options. i dont think this is the case here, though — radai, Jan 04 '13 at 17:37

score 4 · Accepted Answer · answered Jan 04 '13 at 17:33

4

the com.sun.* packages are private classes written by sun for the sun JVM (hotspot) and are not public API (even though your code proves they are accessible). the IBM JVM is a completely different implementation and doesnt have them (as they are not part of any java/jvm spec).
im guessing it compiles fine since youre compiling with the sun/oracle JDK
to try and resolve the issue, try casting to

java.lang.management.OperatingSystemMXBean

instead (which is a public API) and see if that works for you

answered Jan 04 '13 at 17:33

radai

23,949
10
71
115

The java.lang variant works fine of course. What I am getting from this is that Java does not include the all the classes in compiled jar and that these are left to the JVM to be dynamically loaded? I have never actually given this thought. This seems strange because languages like C will produce machine code for the standard library? – mvd Jan 04 '13 at 17:49
correct. well, it includes all the compiled classes of _your_ code in the compiled jar, not the classes for libraries which you compile againt (those are on the classpath @compile time and mostly reside in a jar called rt.jar inside the jvm lib directory, for JDK classes). also, it doesnt _load_ the bytecode of classes unless they are referenced - so if you include a compiled class in your jar that never gets used it will never be loaded. – radai Jan 04 '13 at 17:52
It actually is part of the public API https://docs.oracle.com/en/java/javase/12/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html (as part of the `jdk.management` module in Java 11/12). In Java 8, the packagehttps://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/package-summary.html was marked as `@Exported`, meaning that the _"package is an exported part of the JDK suitable for use outside of the JDK implementation itself"_. – MyKey_ Aug 26 '19 at 18:52

score 1 · Answer 2 · answered Jan 04 '13 at 17:33

You're using a Sun Javac to compile

com.sun.management.OperatingSystemMXBean

with, but an IBM Java to run with. Your IBM environment won't have anything relating to Sun. The com.sun.* classes are proprietary and should be used with caution.

As an aside, you can get this error simply by compiling against a 3rd-party jar, but not deploying with it. e.g. an Apache jar or similar. It's not an error relating particularly to proprietary jars, but rather to deployment issues in general.

score 1 · Answer 3 · answered Jan 04 '13 at 17:34

Presumably you're compiling against the Sun JDK which contains com.sun.management.OperatingSystemMXBean. That's not part of the standard JDK, which is why you shouldn't use it - it's not guaranteed to be present on other Java systems, and appears not to be present in the IBM JVM you're using.

It's the same as compiling against any other library which then isn't present at execution time.

See also:

"Why Developers Should Not Write Programs That Call 'sun' Packages"

score 1 · Answer 4 · answered May 24 '17 at 10:23

Application server operation might be reason of this error. For example in wildfly10 AP, system classes like com.sun.management can not be load automatically and you must define it for AP to be loaded. definition can be done via \modules\system\layers\base\sun\jdk\main\module.xml

<dependencies>
    <module name="sun.scripting" export="true"/>
    <system export="true">
        <paths>
        <path name="com/sun/management"/>
        </path>
        <exports>
            <include-set>
                <path name="META-INF/services"/>
            </include-set>
        </exports>
    </system>
</dependencies>

by adding above definition to mentioned file wildfly10 could load class and you can use methods of com.sun.management.OperatingSystemMXBean in run time.

score 0 · Answer 5 · answered Jan 04 '13 at 17:36

0

You're using a Sun provided compiler and JDK (which has the class), but running on an IBM JVM which doesn't. Generally, if it starts with com.sun.* are sun specific, and shouldn't be relied on if you can't guarantee what JVM will be running it.

answered Jan 04 '13 at 17:36

James

8,512
1
26
28

Why does this code compile, but with runtime ClassNotFoundException?

5 Answers5