Eclipse/IntelliJ: static imports of members - eclipse

I'm refactoring something affecting many bits of my code (huge), and I ended up in needing to organise the import of my project so it can add a static import of a member in a class..
After having spent a full day trying to figure out how to do that, I can't find the way. It's not working neither in IntelliJ or in Eclipse.
In Eclipse I have added it to the Favorites settings, just like it is explained here:
Eclipse Optimize Imports to Include Static Imports
But, it only works on the Control + space, not on Control+Shift+O (to rearrange imports)
In Eclipse 4.2 at least it draws the line red and propose me the suggestion to add the import, but it still doing nothing on the "Organise Import" trigger.
In IntelliJ it is the same, adding the package and the class to the setting, fixes the Control+Alt+Space, but it doesn't deal with the "Optimise Import" feature.
I can't believe this. Has anybody had to deal with this?

You don't want to perform import static on just everything; if the class contains class members that are too general, then an import static will only make your code unreadable. Besides that, there may be name clashes (e.g. two classes having a static getInstance() method would be quite common.
With IntelliJ 13.1.3 you can hit Alt-ENTER, then choose to do a static import (older versions may require one or more CTR-Space before the Alt-ENTER. If you do this on a static member then only the static member is statically imported. If you do it on a class you can do to statically import everything (e.g. import static some.package.SomeClass.*). In the latter case it will remove the class in front of the static imports, unless there is a name clash.
Beware, even if there is no name clash, doing things like SomeInterface someInstance = getInstance() - where getInstance() was statically imported - will get your colleagues very nervous.

Please re-read the question you referred to. You missed the answer mentioning Ctrl + Shift + M. There is a difference between the commands "Organize Imports" and "Add import".

Related

How to keep import * for specific package when organizing imports in Eclipse

For some imports, I may want to keep a * import even I am currently using only 1-2 classes/methods. For example, I may want to import org.mockito.Mockito.* even I am currently using only a few of them, because when my test grows, I will need to use more static method under Mockito. However Organize Imports function in Eclipse always break down my import to import individual methods (which is the preferred behavior in most case).
Is there a way to let me control such behavior in package basis? i.e. I want to keep importing * for some packages (or disabling auto-break-down feature), but for other packages, I would want to use Eclipse's default behavior (deciding * base on number of classes/methods used)
You can't change the policy for individual imported packages or classes, but you can set the overall threshold lower so that Organize Imports won't convert the wildcard import to individual ones. Go to Preferences > Java > Code Style > Organize Imports and then edit the Number of static imports needed... value to something small, like 2.
With it set to a small number, you can manually add a wildcard import and as long as the class uses at least the threshold number of methods, Eclipse will leave it alone.
This doesn't appear to be possible at present, but as it's clearly a useful idea I've added a feature request to eclipse bugzilla for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=506826

Newbie IDE (IntelliJ IDEA) issue: .class files not all usable

I'm working on a school project right now, and every time I have in the past, I always make a new Project in IntelliJ IDEA. However, this time she gave us some .class files that have methods in them that we can't see (she described what they do so we know how to use them) but need to use, so they have to be in the same folder, obviously.
SIDENOTE: I'm also new to using Macs, which is what I'm on at the moment.
Anyways, I put the .class files in my src folder that I found in the Project8 folder. I just made an array of the Book objects, which was one of the .class files I moved, and now I need to use a method from the other .class file, named BookInventory.class. I put that file in the src folder just like the other, but it won't let me use the only method in that class, which is LoadBooks.
Here is the LoadBooks signature:
public static void LoadBooks(Book[] b)
And here's the description of it that she gave to us:
"For each element in the array, accepts user input for the book, creates the Book object, and stores the object into the array."
So, when I made the array of Book objects, IDEA made an import statement up top all by itself, I didn't type it:
import java.awt.print.Book;
So why does IDEA recognize the Book.class file and allow me to use it in this .java file for my project, but it doesn't seem to notice the BookInventory.class file?
Any help appreciated, thanks ahead of time.
What is happening is when you first typed the line with LoadBooks(Book[] b), IntelliJ could not "see" your class files (you have subsequently loaded them in "class files" and added that as a project library, I presume).
IntelliJ however searched for and found a Book class in the internal java libraries, java.awt.print.Book. Note that this is a different class to the one your teacher gave you, which might have been e.g. edu.myschool.homework.Book.
Firstly, try to delete the line including the import statement, or manually change it to the correct package (your teacher can inform you what it is).
If the same import comes back automatically, you can go into Settings -> Editor -> General -> Auto Import and untick Add unambiguous imports on the fly - this will cause intellij to prompt you before adding imports.
Also, I would ask your teacher to give you the class files in a jar file, since that's the usual approach.
Good luck.

Without #import, does Swift have its own easy way to detect circular dependencies?

#import "whatever.h"
...wasn't perfect, but it was very handy for diagnosing circular dependencies, not to mention enforcing modularity.
You could be certain which classes knew about other classes--with the flick of a finger.
If you had to, you could comment out all the import statements, and add them back one at a time, in order to diagnose a dependency issue. It wasn't necessarily fast but it was dead simple.
And if a class didn't import anything other than the obligatory headers, Son, that's one modular class you had there!
If your project had ten classes that didn't import anything, then you knew that they were ten modular classes--you didn't have to package each class into its own Framework or anything like that. Easy.
But now, with Swift's policy of "everybody knows about everything all the time", it seems like it's just down to personal vigilance to sustain modularity. Personal vigilance is the worst kind!
Am I missing something? Is there a way to do these things easily in Swift?
If you want to modularize your Swift code, you should be using modules!
Creating a new module is pretty simple.
Add a new target to your project by clicking the plus sign here:
Select "Framework & Library" for the appropriate platform (iOS/OS X):
Choose "Cocoa Framework" (or Cocoa Touch, platform dependent) and click Next:
Give your module a name and change the language to Swift (or leave it as Objective-C, it doesn't matter, you can use both).
Add a Swift file to your module:
Add some code to your Swift file. Note, the default access level for Swift is internal which means it can be accessed from anywhere within the module but not from outside the module. Any code which we want to use outside the module must be given the public access level.
public class ModularSwift {
public init(){}
public var foo: Int = 0
}
Be sure to build your module (Cmd+B):
Go back to your original target, import the module and start using its code:
import MyModularSwiftCode
let foo = ModularSwift()
Xcode is perfectly happy:
Now, comment out the import statement and notice the errors:

Eclipse optimize imports to include static members and methods

Long user of eclipse and Java. One issue that i've found with Eclipse, is it seems that there is no easy way to import static members and methods.
Namely, the jUnit fail() method from org.junit.Assert
I create several classes a day, and manually add
import static org.junit.Assert.fail;
to the import statements. This is quite annoying. I absolute LOVE using Ctrl+Shift+O to organize my imports, but it still doesn't find static members and methods.
Also, the import does not show up in eclipse.
Funny thing is, is that i've seen it work previously, but i cant recall the variables.
So to my question:
Does anybody know what I need to do to ensure that this static import is always recognized and can be found using Ctrl+Shift+O?
Thanks #qqilihq.
Note:
The answer that was accepted does not work with the Organize Imports keyboard shortcut that I preferred in eclipse, but does work for the "hover over" suggestion.
You can use Ctrl + Shift + M, for example you want to import verify method from Mockito class then
Mockito.verify() // select verify and press Ctrl + Shift + M
This will import verify static method from Mockito class.
Did you have a look at Preferences > Java > Editor > Content Assist > Favorites? You can define candidates for static imports there. Result:
For less used classes you can lower the value of Preferences > Java > Code Style > Organize Imports > Number of static imports needed for .* but beware that you may get .* for classes that contain generically named methods such as getInstance. This in turn may lead to confusion and/or naming conflicts.
You can add the classes that you statically import from Preferences > Java > Editor > Content Assist > Favorites page in Eclipse. Then, Ctrl+Space shortcut lists all the static members of your favourite classes in the content assist menu.

Is there a way to tell Eclipse how to resolve ambiguous java names?

My eclipse is configured so that when I save the java source file, it automatically inserts the missing import declarations. Except when the reference is ambiguous. Fpr instance, the most annoying ambiguity is with List<T> - both java.util and java.awt declare it. Here eclipse demands manual resolution.
I was wondering if it was possible to configure somewhere that whenever List<T> is used then java.util should be imported. Or alternatively, since I am not using java.awt, I could just remove it from the list of possible suggestions.
Any ideas?
Thanks.
This sounds like a possible duplicate of Exclude packages from Eclipse's organize imports.
Basically, you want to change your Type Filters preference to exclude java.awt.* packages. Keep in mind that doing so will make things harder/confusing if you ever try to write AWT/Swing code.
One thing that pops into my mind is altering the class template in the preferences to include the line:
import java.util.List
Unless you are going to use the AWT version of a List, or care about unused import statements, that should solve this annoying issue ..
Manually invoke Organize Imports and it will ask you when an ambiguity is found.