Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Removing internal JDK classes from suggested "quick fix" imports
icon9.gif  Removing internal JDK classes from suggested "quick fix" imports [message #1719568] Fri, 08 January 2016 22:10 Go to next message
J. Zufallig is currently offline J. ZufalligFriend
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 #1719570 is a reply to message #1719568] Fri, 08 January 2016 22:37 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
I haven't tried Kepler, but in a recent Eclipse installation (Mars.1 is recommended) you can tune all this to your liking in the following preferences dialog:
Window > Perferences > Java > Appearance > Type Filters

When everything is properly configured, the default of [x] Hide forbidden references should automagically take care of the internal JDK class.
For other types / packages you may manually add a filter in this dialog.

HTH,
Stephan
Re: Removing internal JDK classes from suggested "quick fix" imports [message #1719745 is a reply to message #1719570] Mon, 11 January 2016 18:58 Go to previous messageGo to next message
J. Zufallig is currently offline J. ZufalligFriend
Messages: 18
Registered: May 2013
Junior Member
Thank you for your reply!

Stephan Herrmann wrote on Fri, 08 January 2016 17:37
When everything is properly configured, the default of [x] Hide forbidden references should automagically take care of the internal JDK class.


What's required to satisfy the "when everything is properly configured" prerequisite? I installed Mars/4.5.1 and loaded up the same project as before. The default Type Filter list is empty and the "hide forbidden references" is checked, but I still get the JDK internal names appearing in the quick fix windows.

Do I need to explicitly list the JDK internal names in the filter list? It looked like that was implicit in the checkbox action.

Re: Removing internal JDK classes from suggested "quick fix" imports [message #1719776 is a reply to message #1719745] Mon, 11 January 2016 23:35 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Quote:
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.

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.

HTH,
Stephan
Re: Removing internal JDK classes from suggested "quick fix" imports [message #1719878 is a reply to message #1719776] Tue, 12 January 2016 20:06 Go to previous messageGo to next message
J. Zufallig is currently offline J. ZufalligFriend
Messages: 18
Registered: May 2013
Junior Member
Stephan Herrmann wrote on Mon, 11 January 2016 18:35
Quote:
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

Re: Removing internal JDK classes from suggested "quick fix" imports [message #1719895 is a reply to message #1719878] Tue, 12 January 2016 23:45 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Quote:
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.


It's not about standard vs. alternate JRE. It's about "Execution environment" vs. JRE.

You need to select an execution environment, because that element bundles a reference to a JRE together with the desired access rules.
Good it's working for you now.
Previous Topic:Programmatically Rename and Move a Java Class
Next Topic:Building 4k files, always crash with Out of memory after 1.5k files
Goto Forum:
  


Current Time: Thu Jul 25 00:59:59 GMT 2024

Powered by FUDForum. Page generated in 0.03936 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top