A Few Days With Eclipse Juno
On June 27, Eclipse released the new version of their IDE, named “Juno” (v4.2 for those that prefer numbers). For those familiar with previous releases, the transition should be pretty seamless. It looks a little different, but not so different that a comfortable user will become uncomfortable. It has some new features, but doesn’t seem to have lost or moved too many old features. There’s a great bit of detail on the Eclipse documentation, but here’s a quick shot of what this (presumably) average user experienced.
The look is noticeably different. I use Eclipse on Windows, Mac, and Linux, and have enjoyed that minor hot-key differences aside, they look and work the same way. The same is true for Juno; it looks the same on all of the platforms, allowing for the platform differences like font rendering, corner curving, and window buttons; the things we accept when we work on multiple desktop environments. While the general layout is the same as previous releases, some striking differences come in the icon bars, tabs, and window separators. Also, the way some of these things function have changed enough to make them noticeable.
Straight out of the archive, everything is a calm grey blending into white. It seems a little more soothing at first glance, and is easy to get used to. One thing that’s a little noticeable at first is that the inactive tabs blend in with the panel content a bit. Also, the only slightly dimmer areas for the rulers and scrollbars and such are a little tough to distinguish at first, but after a while that blending helps them disappear into the background. Of course, there are a few themes and myriad options for configuring as desired.
Tabs act inconsistently in that some must be active before being allowed to close. Closing a view is different than closing an editor, for example, as an editor tab will display the close icon when hovered, while closing a view requires first activating the tab. A simple action, but an extra mouse click and sometimes momentarily frustrating delay.
Dragging windows to reorganize is also more frustrating than before. The “preview” is now a green border suggesting the placement, but the preview frequently fades before allowing the selection, or has a hard time indicating when it’s splitting a panel or the window. Sometimes it happens that the “drag” will continue or act on a click that also has a subtle drag, making for a reorganization that doesn’t require holding the mouse button, but instead waits for the next click. It takes a little getting used to it, and even then it can be a little sneaky and not do quite what it seems it should.
They didn’t break dragging completely, though. One slick thing about the dragging to reorganize is that any view can be dragged into any panel. This allows combining editor windows with panels such as the console, for when the console needs to be really big. Also, this allows separating source windows, including dragging them to detached windows or tucking them in the other panels. Further, the intersections of panels can be grabbed which will affect both splitters at the same time.
Shrinking panels to just titles or tabs no longer works. I often configure my working space so that the console and some other panels are at the bottom. Rather than minimizing them, I’ll drag their dividing line so that only those panels’ tabs are visible. This stops the occasional pop-up of the console, like when alerts occur, without compromising too much screen space. Now that resizing seems to be limited to show one or two lines of content (at the default font size) in most of the views; some do shrink down to just the tab. Still not a lot of real estate to give up, but enough to notice they’re there.
The last visual thing I’ve noticed, and the only one I really don’t like, is that the area on the tool bar at the top that allows quickly switching between perspectives (e.g., Java EE and Debug and Synchronizing) seems to have lost its ability to be resized. I used to shrink that down so that it would show only the “Open Perspective” button and a little drop-down indicator that would still allow selecting the perspective. Further, it displays the whole name of the perspective instead of truncating the really long ones.
Next to the perspective area is one of the new features that I haven’t gotten into the habit of using, but think might get useful if one gets used to using it. The “Quick Access” search box provides an “auto-complete” search for the IDE commands, preferences, and windows. It isn’t project or source-aware, so it doesn’t replace the search boxes for finding classes or resources, but it does speed the search for changing preferences in the project or workspace. It also provides a quick search for open editor windows, which is handy for when there are more editor tabs open than will show.
There are other changes too, like updating Ant to v1.8, reorganizing the tool bars, and some of the dialog boxes. There are additional filters in some views and more visibility to control in others. The editor windows offer preferences in the context menu giving quick access to the preferences for that kind of editor.
Working With Juno
As with Helios and Indigo, Juno includes the Eclipse Marketplace, as well as the old-fashioned “Install New Software” items in the Help menu. There isn’t a built-in Subversion or Git team connector. Neither are Groovy or Maven tools included by default. All of these can be added in the Marketplace.
Starting a new project in Juno is not really any different than in older versions of Eclipse. There are a number of ways to select “new project,” and a number of project types to select. I find I’m almost working in plain “Project,” a “Java Project,” or “Dynamic Web Project,” so there may be additions or losses I’m not noticing. Once created, files are found and created and opened the same ways they’ve been before.
I did find a few issues when opening an existing workspace, however. First, it seems that some of the workspace settings, like the layouts, aren’t respected or updated by Juno. The positioning of panels and views in my perspectives all reverted to the defaults, meaning I had to close the Snippets and Outline and Tasks and other ones I don’t typically use, and then had to muster through dragging them around to get them where I wanted them.
Also, the Subversive plug-in I use for SVN access has an updated connector, which results in a failure to connect already checked-out project to its repository. This also happens in the other versions of Eclipse if the connector gets updated and no longer works with the previous files. The Subversive plug-in saw and remembered the repository configurations, but did forget any saved usernames and passwords or SSH configurations.
The correction is pretty straight forward. The trouble is that SVN artifacts need to be cleaned-out, however, when the failure occurs, Eclipse believes the project has been disconnected, so the option to disconnect the project is unavailable. To correct this, choose “Share Project” from the Team context menu, reselect the correct SVN repository, and the kit will warn that the project already exists on the server; continue through the warning and the check-out will occur. In every case, any changed file I had remained on my workstation and appeared instantly as a change to what was in the repository; at this point I could revert to the repository version or continue my work, as was appropriate.
However, in most cases, the SVN files are incorrect, and the project won’t interact with Subversion, giving errors that the files have an unsupported format. Now do the Team menu disconnect action, choose to delete the meta-information. Then repeat the “Share Project” process. It’s tedious and probably isn’t worth the trouble if the project is very large, or no changes have been made.
Checking-out a project from Subversion is just as easy as it was before. Set up a repository, check-out, and start working. This worked in new and old workspaces, with new and old repositories.
Once the project is up and running, everything worked like I expected. The editors edited, the run and debug shortcuts and dialogs worked, and I could even see and use my servers in the old workspaces.
I didn’t notice any changes to the actual editors. Except for the visual bits around the windows and the way the tabs work, the syntax highlighting and auto-complete seemed to be the same. Navigation is enhanced a little with the “Quick Access” search, but otherwise familiar keystrokes and mouse buttons all work the same.
There does seem to be a little bit of a delay when switching views or editors. Some of this seems to be related to other synchronized views, for example if the Project Navigator needs to change to reflect a new editor selection. It’s particularly noticeable if there are several projects open, and filters (such as the Markers or Problems views) limit their contents to the current project or folder or such. While I’ve noticed it, I’ve not been impacted enough to avoid the IDE, but I could see where some users might be.
One of the first things I do is turn on the Heap Monitor, and I did notice that switching between tabs causes great leaps in memory, both consumed and freed. Perhaps they’ve added something to the platform that is trying to take advantage of an apparently acceptable time to delay to try to trigger some memory management.
As I mentioned, a comfortable user of Helios or Indigo should become quickly comfortable with Juno. The frustrating things I’ve found are the way dragging views around gets tricky, and the inability to completely lower a view to just the title tabs. Everything else just blends in to minor differences one can expect with an upgrade.
I was concerned about working with other versions of Eclipse, but I haven’t seen any settings or other workspace files that wanted to be committed, so I don’t think there are fundamental changes in the properties or classpath files. I’m sure if I changed some project settings or preferences that some of the settings files would change, but I’m not sure how much they would, or how compatible those changes would be with older versions of the IDE, in case other developers or other workstations haven’t yet updated.
I haven’t opened a workspace in Juno and then again in Indigo to see what happens. I’ve avoided this mostly because I don’t have any workspaces with projects that aren’t attached to Subversion, though, not because of any fear of ruining a workspace.
In all, it seems a mostly visual update. There are a few differences, that some may find to be annoyances, but it is the first major version change in a while (Helios was v3.6 and Indigo v3.7, now Juno is 4.2).
If things work in your Eclipse now, and you’re using Indigo, I’d say you’ll probably be OK waiting to update to Juno. Except for some of the enhancements to the
There are likely to be bug fixes or other changes for some of the performance things. If nothing else, the SR1 release is “scheduled” for September, so that might have a better and big enough experience change to warrant an upgrade.
I’d definitely update to Indigo from Helios, though.