Community
Participate
Working Groups
Created attachment 279127 [details] Movie showing the bug. Developing a Class and write a method who logs an exception let me not inspect javadoc of a public-static-final field. The Javadoc tooltip opens up successfully and appears legit. The contents of the Javadoc is not telling the Javadoc from the Java. Instead a error-lookalike message replaces the Javadoc. Expected: On hover the rendered Javadoc should be shown. Instead: On hover a javadoc-lookalike errormessage is shown having the content: "The properties file could not be detected". Please notice the attachment.
I cannot reproduce, the constants of java.util.logging.Level correctly show javadoc in my workspace. Please tell us the exact version and origin of the JRE used in your project. Some part of JDT seems to recognize that class as an accessor for an NLS bundle, but then the expected .properties file is not found. I have no idea, how j.u.l.Level could be recognized as such an accessor class. The detection heuristics are implemented starting in method internalGetHoverInfo() of class https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/text/java/hover/NLSStringHover.java At the latest, the following method should return null and end attempts for detection: org.eclipse.jdt.internal.corext.refactoring.nls.NLSHintHelper.getResourceBundleName(CompilationUnit) AFAICS, one of the following elements must be present: - invocation of java.util.ResourceBundle.getBundle(..) - invocation of org.eclipse.osgi.util.NLS.initializeMessages(..) - a field named BUNDLE_NAME or RESOURCE_BUNDLE or bundleName I see none of these in j.u.l.Level.
Exact version of jdk. JDK Vendor is Oracle. Eclipse build 4.11.0.I20190307-0500. java version "1.8.0_212" Java(TM) SE Runtime Environment (build 1.8.0_212-b10) Java HotSpot(TM) 64-Bit Server VM (build 25.212-b10, mixed mode) Origin at: C:\Program Files\Java\jdk1.8.0_212 Eclipse installed at: C:\Program Files\eclipse Other JRE versions are neither installed nor located at /eclipse/jre/. Log sais nothing related: - egit sais he miss HOME-env-variable - conflicting shortcut ALT+CTRL+T What may be guide us to a NLS problem is the locale "OS=win32, ARCH=x86_64, WS=win32, NL=de_DE"
OK, previously I was trying with recent JDK versions which did not have the problem, but at 1.8.0 I can see some code inside method Level.computeLocalizedLevelName() that confuses JDT, in particular some invocations of ResourceBundle.getBundle(..); This is recognized by JDT as an indication that indeed Level were an NLS accessor. JDT then finds the argument 'defaultBundle', which is a string constant for "sun.util.logging.resources.logging", so we think that this must be the name of the properties file, but JDK only contains .class files with corresponding names. I tried this in the debugger: java.util.ResourceBundle.getBundle("sun.util.logging.resources.logging", java.util.Locale.getDefault()) to be greeted with java.util.MissingResourceException! So, I'm not understanding some aspect of localization in JDK, but JDT should probably refine it's heuristic to *not* recognize this as NLS accessor. I wouldn't give high priority to this, though, since this is a malfunction of hovers on fields of only a single JDK class, which no longer happens in Java 9+ due to the redirection via JavaUtilResourceBundleAccess. Workaround: use the Javadoc view.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
