I do all of my Java development with Eclipse. I’ve been using it for three or four years now, but I still learn new things about it. On the one hand, it’s so easy to use most features that I’ve never read any of the books or other documentation describing them. On the other, there are a great many features buried deep in configuration dialogs, or that are not immediately obvious. So sometimes I find myself confronted with a situation where I’m scratching my head, wondering whether or not Eclipse will let me do something. At that point, investigation begins.
Today, I ran into one of those situations. In a current project, I’m using the LWJGL library for direct OpenGL access. The interface to the OpenGL functions is through static methods of version-specific classes (i.e. GL11, GL12, GL13, etc…). I really like this approach for two reasons: it makes a lot more sense in this case than trying to be “proper OO” (a phrase OO purists are wont to bandy about) and instantiating GL instances, or even using singletons, because of the nature of the OpenGL API; it’s the sort of design that the static import feature introduced in Java 5 is made for, i.e. GL11.glSomeFunc(GL11.GL_SOME_ENUM) becomes glSomeFunc(GL_SOME_ENUM), making the code nearly identical to the C version. I had not used the static import feature at any great length previously, so I wasn’t prepared for the annoyances that surfaced in Eclipse.
Normally, I avoid the import somepackage.* syntax. I find it much cleaner, and less error prone, to specifically import the classes you need, i.e. import somepackage.SomeClass. Eclipse makes this very easy via its active parsing. The first time you type a class name it doesn’t recognize it searches the classpath to find it, flags the name as an error, and allows you to pop up a suggestion box with several options. If the class was found in the classpath, the fist option will be to import it (and if it is found in more than one package, you will have more than one choice of imports). One click and the import statement is added to the top of the source file, each statement grouped alphabetically with other imports from the same package. I’ve become so accustomed to this feature that I despise typing Java code in any other editor.
In the particular case of LWJGL, I decided it made more sense to use the * syntax with the static imports I was using. There’s no chance of the GL class members and methods conflicting with anything else. All was going quite well until I started refactoring. At that point, an annoying issued reared up.
Eclipse can handle all sorts of refactoring tasks automatically. Sometimes, I make small changes in specific files by hand. When manual changes are made and Eclipse notices that a source file no longer makes use of one or more imported classes, it highlights the import statement as either a warning or an error. Bringing up the options box gives two options: remove unused import, organize imports. The first will remove a single import only, while the second will remove all unused imports in the current file and make sure everything is organized appropriately. What I learned, to my frustration, is that any * imports, including static ones, are replaced with imports for the symbols used. Choosing organize imports in a module with a great many OpenGL calls was causing a huge list of import statements to be inserted, one for each static method and member I used. Ugh!
After this happened a couple of times, I started searching through the preferences dialog. I finally found the answer, but it’s one of those that is in a location that isn’t immediately obvious. I had seen the same preference sheet hundreds of times and never noticed it. The preference in question can be found in Window->Preferences->Java->Code Style->Organize Imports. At the bottom of that sheet are two options governing normal imports and static imports. Rather than explain them, I’ll just show you:
The option for the static imports was set to ‘99′ by default. Changing it to ‘1′ ensures that each time I use organize imports in this workspace, my static imports will not explode. That makes sense for the projects in this workspace, but I’m not sure it’s an option I’d use in every project. At least now I know how to control it.
Technorati Tags: Java, Eclipse, LWJGL, programming, software development, IDE
Post a Comment