Home » Language IDEs » Java Development Tools (JDT) » Removing internal JDK classes from suggested "quick fix" imports
 Removing internal JDK classes from suggested "quick fix" imports [message #1719568] |
Fri, 08 January 2016 22:10  |
 J. Zufallig
Messages: 18
Registered: May 2013 |
Junior Member |
|
|
We're using Kepler SR2, no other plugins. I'm trying to figure out what combination of changes I need to make to Build Path and Organize Imports to get Eclipse to stop being silly.
Say that I write "ListIterator<String> foo = .....", save, and compile. Now, the Save Actions will organize the import statements, but in some cases (like this one) it doesn't know what to import. So the compilation fails because ListIterator is unknown. When hovering over the red squiggle on ListIterator, the "quick fixes" popup contains:
- Import ListIterator (com.sun.xml.internal.bind.v2.runtime.reflect)
- Import ListIterator (java.util)
- ...the usual Create/Change options...
- Fix project setup...
Since I started using Eclipse, I've just been clicking on "java.util", sighing, and going on about my day. Today I was feeling persnickity.
The com.sun gibberish is clearly nonsense; there's no reason why I would ever want that. And the name makes it obvious this is an implementation class leaking out (from the JDK, in this case, not Eclipse). And I'm pretty certain that if the com.sun.blargleblurblebaloney wasn't showing up, the correct name would have been found by Eclipse automatically without ever making noise and requiring human intervention.
So I go poking around in Organize Imports, which lets me rearrange things, but not exclude any names/prefixes from automatically being considered for import.
Next, I hover over the "quick fixes" window and try clicking the "Fix project setup", which opens my project's Java Build Path window, onto the Order and Export tab. I'm not certain what I'm supposed to change here. The name is clearly coming from the JDK/JRE system libraries, but there's nothing that would let me filter out packages.
What's the magic involved to make the suggested imports a little bit smarter?
|
|
| | | |
| Re: Removing internal JDK classes from suggested "quick fix" imports [message #1719878 is a reply to message #1719776] |
Tue, 12 January 2016 20:06  |
J. Zufallig
Messages: 18
Registered: May 2013 |
Junior Member |
|
|
Stephan Herrmann wrote on Mon, 11 January 2016 18:35Quote:What's required to satisfy the "when everything is properly configured" prerequisite?
I guess you configured your buildpath to use an "alternate JRE" as your JRE System Library?
Try selecting the appropriate "Execution Environment" instead.
No, as far as I can tell, it's using a standard JRE. If you tell me where in the config to look for an alternate JRE, I'm happy to double-check.
In the main preferences > Java > Installed JREs, all the ones we're using are listed with their correct names/versions/locations. In the Execution Environments subsection, the "JavaSE-1.7" entry has the appropriate "perfect match" JRE checked. (This particular project can't use Java 8 yet, but we have some installed there also, and JavaSE-1.8 has its appropriate perfect match.)
In the project Java Build Path, the libraries are things like LogBack and SLF4J, then just "JRE System Library" with the same name as in the JavaSE-1.7 execution environments list.
Quote:After that, still using the "Java Build Path > Library" tab, drill into "JRE System Library > rt.jar". You should see a tree node like "Access rules: 162 rules defined - non modifiable".
Those rules are defined per execution environment, and tell the compiler which are "forbidden" references.
Ah. I see "Access rules: No rules defined" here.
Was this not a thing for the Java 7 JRE support? If this isn't supposed to work for JREs <8.0 then that's fine, I'll just add that to our "list of reasons why this project really should be brought up to use Java >= 8.0".
But if the access rules are supposed to Just Work for a default Java 7 execution environment, then something else is amiss here.
UPDATE: doing some googling for "execution environment forbidden list" turned up a StackOverflow post with instructions. Turns out the "JRE System Library" entry was neither an execution environment, nor an alternate JRE, but instead a "workspace default". Removing it and re-adding it from the execution environment list produced a "JRE System Library" entry with the exact same name, but (apparently) with magically different settings behind the scenes, including the access rules mentioned above.
I feel like I've learned something from all this, I just don't know what it is yet. :-)
[Updated on: Tue, 12 January 2016 20:30] Report message to a moderator |
|
| |
Goto Forum:
Current Time: Sun Sep 24 21:44:16 GMT 2023
Powered by FUDForum. Page generated in 0.02571 seconds |
] 
Search
Help
Register
Login
Home
