The oracle-jdk-bin/oracle-jdk-bin-1.8.0.60-r1.ebuild removes the Java usage tracker from the JDK, see https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-java/oracle-jdk-bin?id=8946e2fb40081557aa12b6e39cf2b2852376eea7 While this is generally desirable, tampering with the rt.jar turns out to cause minor trouble when launching Java apps. While developing apps with Eclipse each start of the debugger stops at an exception breakpoint in sun.misc.PostVMInitHook, complaining about missing classes, namely the deleted sun.usagetracker.UsageTrackerClient. While the launch can be resumed and the debugger works as normal, it's extremely painful to perform extra steps for each application start.
I can confirm this behaviour. When I saw the -r1 commit I considered how removing the classes would not create more problems, but since normal apps run fine I let it slide. Clearly a better course of action is to provide an empty dummy class with the correct method signature which does nothing: sun.usagetracker.UsageTrackerClient.run(java.lang.String, java.lang.String) Wrangling that into the jar after deleting the other classes should suffice for now.
(In reply to Holger Hoffstätte from comment #1) > Clearly a better course of action is to provide an > empty dummy class with the correct method signature which does nothing: > > sun.usagetracker.UsageTrackerClient.run(java.lang.String, java.lang.String) > > Wrangling that into the jar after deleting the other classes should suffice > for now. Yep that works. I tried it locally. A simple Java class like package sun.usagetracker; public final class UsageTrackerClient { public void run(final String paramString1, final String paramString2) { // does nothing } } compiled and fiddled into rt.jar makes my local dev setup behave again.
Sorry about that, folks. My gut feeling was that icedtea doesn't include this so it must be okay. I held back marking it stable despite needing an account to download the older version because I still thought I should give it some air time just in case. Good thing I did. Your mention of sun.misc.PostVMInitHook made me curious and sure enough, icedtea doesn't include that either. I thought deleting that too might be a step too far but I figured I may as well see what it does. % javap -classpath /opt/oracle-jre-bin-1.8.0.60/lib/rt.jar -c sun.misc.PostVMInitHook Compiled from "PostVMInitHook.java" public class sun.misc.PostVMInitHook { public sun.misc.PostVMInitHook(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return public static void run(); Code: 0: invokestatic #2 // Method trackJavaUsage:()V 3: return } The first part is just the default constructor so all this literally does is call the tracker. Between that discovery and the fact that this is also missing from icedtea, I'd now be happy to remove this too. What do you think? Care to give it a try for me? I don't have Eclipse handy.
To be doubly sure, I extracted rt.jar and grepped the tree for "usagetracker". sun/misc/PostVMInitHook.class was the only result.
(In reply to James Le Cuirot from comment #3) > Between that discovery and the fact that this is also > missing from icedtea, I'd now be happy to remove this too. What do you > think? Care to give it a try for me? I don't have Eclipse handy. We discussed this. Simply removing will probably just throw up another CNF somewhere else again (and probably worse since it's then in the bootstrap/main thread - unlike the tracker which runs in its own, swallowing the exception). I'd rather see the hook stay in place and the tracker dummied out, as future JDK versions might still do useful things in the hook that we'd then add back/rewrite/whatever. Disable the action, not the call site.
(In reply to Holger Hoffstätte from comment #5) ..alternatively don't remove the hook, but dummy it out with an empty class just like I demonstrated for the tracker. As for future maintenance.. ¯\(ツ)/¯
(In reply to Holger Hoffstätte from comment #5) > We discussed this. Simply removing will probably just throw up another CNF > somewhere else again. I > I'd rather see the hook stay in place and the tracker > dummied out, as future JDK versions might still do useful things in the hook > that we'd then add back/rewrite/whatever. Disable the action, not the call > site.
Sorry, hit the wrong button there. (In reply to Holger Hoffstätte from comment #5) > We discussed this. Simply removing will probably just throw up another CNF > somewhere else again. I can at least put that concern to bed. I have found that PostVMInitHook isn't an Oracle-specific thing but present in icedtea as well. In both cases, there is a reference to it in libjvm.so so it must be called from the VM itself, as you would expect for something like this. Given that icedtea has a reference to it but no definition, it must be safe to leave out. > I'd rather see the hook stay in place and the tracker > dummied out, as future JDK versions might still do useful things in the hook > that we'd then add back/rewrite/whatever. I'm not sure what useful thing Oracle could possibly add that icedtea wouldn't but I'll agree that stubbing the tracker would be safer, if a little more awkward to implement. I'll see what I can do.
I was going to have it call javac within the ebuild but then I realised this would not work for the JRE package. I could precompile it but I don't really want to stick a precompiled class in the files directory. Who's to say the method signature won't change anyway? I'd feel more comfortable just removing PostVMInitHook. I solemnly vow to check it with javap on every bump. In fact, I'll stick a JAVA_PKG_STRICT check in there so that developers will see the javap output every time. If you do encounter any further issues then by all means, please reopen this bug.
Fixed in -r2. In the end, I only deleted the PostVMInitHook and not the tracker itself, therefore keeping the change to a minimum.
It's not in OpenJDK/IcedTea. This code is in OpenJDK's HotSpot in both 7 & 8 and indicates that removing sun.misc.PostVMInitHook is safe: // General purpose hook into Java code, run once when the VM is initialized. // The Java library method itself may be changed independently from the VM. static void call_postVMInitHook(TRAPS) { klassOop k = SystemDictionary::PostVMInitHook_klass(); instanceKlassHandle klass (THREAD, k); if (klass.not_null()) { JavaValue result(T_VOID); JavaCalls::call_static(&result, klass, vmSymbols::run_method_name(), vmSymbols::void_method_signature(), CHECK); } } Note the "klass.not_null" check. It comes from: changeset: 2070:8f8dfba37802 user: kevinw date: Wed Jan 12 15:44:16 2011 +0000 summary: 6994753: Implement optional hook to a Java method at VM startup. http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8f8dfba37802 That's the technical side. On the legal side, I'm an not a lawyer, so this does not constitute legal advice, but I think doing this removal may be a violation of the Oracle binary license, which prevents modification.
