Eclipse Key Binding: Select Enclosing Element

Here’s a Eclipse command that’s pretty handy: Select Enclosing Element  (key binding: Shift+Alt+Up on Linux).


Every time you hit the key combination, it expands the selection to the enclosing element. In this example, it starts with the method selector, and expands to include the parameters, the receiver, the statement, the block, the method, … all the way up to the entire compilation unit.

To go the other way (back towards the original selection), use the Restore Last Selection command (key binding Shift+Alt+Down on Linux).

It is, of course, up to you to decide what to do with the selection once you have it just right: Maybe use Alt+Up or Alt+Down to move selection around in the file…

You can find this and more commands by hitting Ctrl+3 and just typing a bit of what you’re looking for, or hit Shift+Ctrl+L to open a pop-up with the full list of key bindings.

Posted in Eclipse 101, Mars, Screenshots | Leave a comment

Eclipse IDE on JDK 9 Early Access with Project Jigsaw

I wrote a few weeks ago about getting Eclipse Neon running on Java 9 (though, I had mistakenly and embarrassingly left “Mars” in the title of the post). It’s worth noting that the steps that I laid out also apply to the JDK 9 Early Access with Project Jigsaw (Java modularity) builds. Eclipse Neon works on Jigsaw. I’ve been using this combination for real development on some new plug-ins that I’ve been tinkering with (more on that later).

Eclipse Neon running on JDK 9 + Jigsaw

Developing some new plug-ins using Eclipse Neon M2 running on JDK 9 + Jigsaw.

In its current form, Jigsaw provides a well-defined visibility model that manages what pieces of a module are accessible from other modules. As part of this, it prevents you from accessing internal code. We’ve been warned for years, for example, that using com.sun.* packages is verboten and Jigsaw aims to do something about it. The modularized JDK hides these internal packages from dependent modules and throws a fit when you try to access them (both the compiler and runtime).

As a “legacy” Java application running on the classpath, Eclipse IDE runs as what’s called an unnamed module (Voldemodule? the module that must not be named?) Unnamed modules have a special status in the runtime, but are still subject to the visibility restrictions. I’ll save a more detailed discussion of this for another post. My point today is that the Eclipse IDE just works on JDK 9 Jigsaw builds. This is true, at least, on the Fedora 22 and Windows 8 systems I’ve tested; I’m interested to learn of your experience.

The Jigsaw builds come with a handy tool, jdeps, which does all sorts of things related to module dependencies (note that this tool is only included with the Jigsaw builds). Included with the functionality is the ability to scan Java code to determine if it violates any of the restrictions enforced by the modularity model.

I ran jdeps on the Mars.1 repository to get a sense for how much work we might have ahead of us and was delightfully surprised by how few references Eclipse Project code has to internal APIs. Perhaps my biggest concern is that there is a reference to an internal class in the SWT_AWT bridge (bug 482318). I’ll open additional bugs as I investigate the other hits.

In the meantime, if you want to check out your own code for violations you can run jdeps yourself. The JDK 9 Early Access with Project Jigsaw builds are just archive files that you can decompress into the directory of your choice (it doesn’t update any paths or configuration on your system) and execute:

~/jdk1.9.0> bin/jdeps -jdkinternals /path/file.jar

Where /path/file.jar points to one or more files (e.g. ~/.p2/plugins/*.jar).

Correction: jdeps is included in Java 8 and 9 builds.

While I have your attention: be sure to propose a talk for EclipseCon 2016!

Posted in Java | Tagged , , | Leave a comment

A bit of Fun from the EMO Mailbag

I get a lot of email from all sorts of people looking for all kinds of help. I recently received, what I believe is the funniest one to date:

I have a friend named redacted. He is evidently a master programmer, because he says so. However, his code keeps turning up errors, about 5 to 10 per class. I have determined that, since his code is flawless, the error must be in Eclipse MARS. I believe you should speak with him to collaborate, and, instead of him fixing what the program incorrectly calls errors, you should change your program and the language of Java such that his “errors” will be guidelines. Thank you very much.

I had a delightful bit tongue-in-cheek back and forth with the sender.

Posted in Cranky Old Programmer | Leave a comment

The “Projects into Workspace” Import Wizard

I broke Marcel’s language parser yesterday with what turns out to be an oddly-worded tweet.


It probably doesn’t help that I mistyped it: I wrote “is” when I meant “in”. Specifically,

Use the “Projects into Workspace” import wizard to build an environment to develop Eclipse Platform UI in as long as it takes to download.

The Oomph > Projects into Workspace import wizard is included in most of the Eclipse IDE downloads. You can use this wizard to create a complete development environment that contains required plug-ins, Git repositories, target environment, tasks, etc.

"Projects into Workspace" Import Wizard

The thought behind my tweet is that the complete development environment can be realized in the amount of time that it takes to download the constituent components and—maybe—a restart if new features are added, meaning that you can be up and running in a few minutes (depending, of course, on the speed of your connection).

This is the same functionality provided by the installer when you run it in advanced mode.

I wrote the tweet after achieving success with the project import to build an environment to contribute to the Platform UI project. I may have been a bit hasty, however. While the import wizard is very handy in most cases, the projects included in the Eclipse SDK are a bit special in that integration builds are their own up-to-date build target: you really should download the latest integration build from the project’s download page and then clone the source code you need directly from Gerrit. This way, you have the best build target for the latest version of the code.

But for everything else, you really should use the import wizard. I used this during a recent presentation at JavaOne to build a ready-to-run-tests development environment for OpenHab over conference WiFi in about 15 minutes (which included adding the Plug-in Development Environment to my Eclipse IDE for Java Developers). If you want contributors for your open source project, you really should consider building and maintaining a Setup Project Model.

Posted in Eclipse 101 | Tagged | Leave a comment

Version 1.6.0_65 of the JVM is not suitable for this product

I’ve had few people ask me about this error recently.

Java 1.7 Required

So far, everybody who’s asked is using a Mac running OS X and they all seem to be running El Capitan 10.11. I’m not a Mac user myself, so narrowing down the exact symptoms was a bit of a challenge.

The message is pretty clear, assuming that you haven’t already installed a newer version of Java, but it’s darned confusing if you already have a Java 7 (1.7) or Java 8 (1.8) JRE or JDK installed. My immediate (validated) assumption was that Eclipse was having trouble finding the right JRE. It was not, however, immediately obvious how to solve it (perhaps it might have been if I had ever actually used Java on a Mac).

It took a few iterations before I was able sort out the magical search terms, but I did eventually find a promising StackOverflow article.

The short version is this… Execute /usr/libexec/java_home from a command line. It should tell you which version of Java is being resolved as the default and allow you to change it. You can also use this utility to find the path of a particular JRE that you can use to configure the -vm option in your eclipse.ini file.

The folks that I’ve been working with report that this fixes things nicely. Again, however, I’m not a Mac user, so your mileage may vary.

Posted in Eclipse 101 | Tagged , , | Leave a comment

Ctrl+1 in the Eclipse XML Editor

The XML Editor is included in several of the Eclipse IDE downloads. It has two view modes: in design mode, you can edit your XML as a tree; in source mode, you edit as text. By default, it opens in design mode, which may seem a little weird (I’ve added Bug 480036 to the list of EclipseCon Europe 2015 Hackathon bugs to consider changing this).

I use the XML editor infrequently, but it is based on the same technology as the HTML and PHP Editors (which has embedded HTML support) that I use pretty regularly. All three of these editors have a cool feature that I didn’t know existed until today.

Ctrl+1 in the XML Editor

Put the cursor in—or highlight the text of—a tag (either the open or the close tag), and hit ctrl+1. Select “Rename in file” and type a new tag. Both the open and close tags are updated in one. Just like the similar functionality provided by the Java development tools, this is sensitive to context (i.e. it will change the right closing tag).

This is certainly more handy for XML editing, but I did manage to shave a few seconds off my day using it to convert <ol>..</ol> to <ul>..</ul> in some HTML. #littleVictories

For completeness, the XML Editor is already included in  the following Mars Eclipse IDE Packages:

  • Eclipse IDE for Java EE Developers
  • Eclipse IDE for Java Developers
  • Eclipse IDE for PHP Developers
  • Eclipse IDE for Java and DSL Developers
  • Eclipse IDE for RCP and RAP Developers
  • Eclipse IDE for Automotive Software Developers
  • Eclipse IDE for Java and Report Developers
  • Eclipse IDE for Parallel Application Developers

You can add the XML Editor to any Eclipse IDE by adding the “Eclipse XML Editor and Tools” feature from the Mars repository.

Thanks to Konstantin Komissarchik for compiling the list of IDEs and to Nitin Dahyabhai for highlighting the functionality.

Posted in Eclipse 101, Hackathon | Tagged , | 1 Comment

Eclipse Java™ 9 Support (BETA) for Neon

I’ll admit to a certain amount of shame that it’s taken me this long to try out the Beta Java™ 9 support in Eclipse. It’s a work-in-progress, but certainly shows that progress is being made.

Here’s what I did.

I downloaded the early access version of Java 9 JDK from in the form of a tar.gz file that I decompressed into a local directory: /home/apps/jdk1.9.0. I made no other changes to my system.

I downloaded the Eclipse SDK 4.6 (Neon) M2 from the Eclipse Platform downloads and decompressed it into its own directory. I made a small change to the eclipse.ini file to make the new configuration run using the Java 9 runtime.


Note that this change occurs before the -vmargs line.

I launched Eclipse and opened the p2 installer using the Help > Install new software... menu option. I pointed the p2 installer at the Java 9 Beta software site and installed both features (one is the feature and the other is the corresponding source code).

Insta Java 9 Beta support from the software repository.

Insta Java 9 Beta support from the software repository.

I restarted Eclipse.

From there, I created a very simple “Hello world” application (using the JavaSE-1.9 Execution Environment), saved, and ran. It worked exactly as expected. There was much rejoicing (Perri brought brownies).

Next step: tinkering with Java 9.

If you’d like to see the Java 9 support in action, visit the Eclipse Foundation booth at JavaOne next week. Or better yet, drop by the Hackathon at EclipseCon Europe the following week and connect directly with committers from the development team.

EclipseCon Europe 2015

Update: I had mistakenly titled this “Mars”. Eclipse Mars does run on JDK 9, but to actually build Java 9 applications, you need to start from Neon. Note also that these instructions apply for both the JDK 9 EA and the JDK 9 EA with Jigsaw.

Posted in Eclipse 101, Java | Tagged | 2 Comments