Java 9 module-info Files in the Eclipse IDE

Note that this post is not intended to be a status update; it’s just a quick update based on some experimenting that I’ve been doing with the beta code.

It’s been a while, but I’m back to experimenting in Java 9 support in the Eclipse IDE.

For testing purposes, I downloaded the most recent Oxygen (4.7) integration build (I20160914-0800) from the Eclipse Project downloads the latest  Java 9 JRE build (135).

I configured the Eclipse IDE to run on the Java 9 JVM. This still requires a minor change in the eclipse.ini file: to launch successfully, you must add --add-modules=java.se.ee to the vmargs section (I expect this to be resolved before Java 9 support is officially released; see Bug 493761 for more information). I used and used the Install new software… dialog to pull in updates from the BETA_JAVA9 SDK builds repository (see the Java9 Eclipsepedia page for more information).

I created a very simple Java application with a module-info.java file. Content assist is available for this file.

screenshot-from-2016-09-14-14-27-24

Note that there is an error indicated on the import of java.awt.Frame. This error exists because the module info file does not provide visibility to that class (AWT is not included with java.base).

If we change that requires statement, the visibility issue is resolved and the compiler is happy. Well, mostly happy. Apparently not using declared variables gets you a stern warning (this is, of course, configurable).

screenshot-from-2016-09-14-14-27-51

The Eclipse Project is planning to ship support as part of an Eclipse Neon update release that coincides with the official release date of Java 9. I’ll be talking a bit about this during my JavaOne talk and demonstrating this (and more Java topics) at the Eclipse Foundation’s booth.

Conference: JavaOne
Session Type: Conference Session
Session ID: CON6469
Session Title: Developing Java Applications with Eclipse Neon
Room: Hilton—Continental Ballroom 6
Date and Time: 09/19/16, 11:00:00 AM – 12:00:00 PM

The call for papers for Devoxx US is open. Devoxx is a community conference from developers for developers. Submit your proposal now.

Posted in Java, Neon, Screenshots | Leave a comment

Eclipse Project Branding and Trademarks

As part of the project creation process, the Eclipse Foundation assumes ownership of the project’s name.  As a legal entity, the Eclipse Foundation owns all Eclipse project and corresponding product trademarks on behalf of the the Eclipse community. This prevents companies and others from misusing or misrepresenting their products as being the projects.

For a trademark assertion to hold any value, an organisation must take steps to protect that trademark. That means that care must be taken in the manner with which the name is used by the owners themselves and the community. Generally, the steps taken to protect a trademark are concerned with avoiding confusion in the community and ecosystem. The Eclipse Foundation’s publishes guidelines for the use of our logos and trademarks. This is, of course, not unique to the Eclipse Foundation: many organisations, including open source organisations, publish guidelines describing how their trademarks may be used.

A big part of the value of a project moving to the Eclipse Foundation is the Eclipse name. The value of the Eclipse name, of course, comes from the value provided by the projects. The relationship is circular: one props up the other. With this in mind, I’ve added a new Branding section to the Eclipse Project Handbook which describes the sorts of things that project teams should do to prop up their own individual brand along with the Eclipse brand (I’ll publish updates the LocationTech and PolarSys Project Handbooks shortly).

I don’t think that there is anything particularly controversial in this document. For many of our projects, there is very little (if any) additional work that needs to be done. For most projects, the full extent of the work that needs to be done will be to consistently prefix their project name with “Eclipse”. The document also attempts to provide some guidance for community websites that aren’t hosted using resources approved by the Eclipse Foundation (to conform to our Freedom of Action rule of engagement, official project websites must be hosted on EF-supported infrastructure).

Starting in July 2016, the EMO will—as part of all release and graduation reviews—review the project’s use of trademarks and help project teams conform to the guidelines.

Posted in Eclipse 101, EDP, Project Management | 3 Comments

Longest Serving Eclipse Neon Contributors

I’ve been running various queries against our Git index database. I decided to see who are our longest standing contributors. I had to draw the line somewhere, so I set the cut off at 4,000 days between their first commit and their last.

Here is the list of our longest service contributors:

Silenio Quarti, Grant Gayed, Carolyn MacLeod, Dani Megert, Steve Northover, Olivier Thomann, John Arthorne, Dejan Glozic, Doug Schaefer, Mikhail Khodjaiants, Pascal Rapicault, Markus Keller, Mike Wilson, Thomas Watson, Chuck Bridgham, Nitin Dahyabhai, Stefan Xenos, Bogdan Gheorghe, Ed Merks, Susan McCourt, Kenn Hussey, Nick Boldt, DJ Houghton, David Williams, Gorkem Ercan, Scott Lewis, Peter Nehrer, Yulin Wang, Wei Yan, Greg Watson, Keith Chong, Rick Lu, Atsuhiko Yamanaka

Note that this is restricted to only those developers who are (or have been) committers on projects that are participating in the Eclipse Neon release. This, and all of the other caveats that I mentioned yesterday apply.

The list is ordered by the number of days between the date of the first commit and the last. Counting this way, Silenio Quarti is our longest serving contributor (beating Grant Gayed by just one day). There are a few people who have earlier commits than Silenio, but nobody has stuck with it longer.

Posted in Neon | Leave a comment

Eclipse Contributors Since the Beginning of Time

In my last post, I made reference to all the people named Dave that have contributed to Eclipse over the years. I thought that I’d share a little more information about the query behind that.

We maintain a database that indexes all of the commits in all of our Git repositories. This includes the repositories that are on Eclipse Foundation servers and those that are hosted on GitHub. The index includes repositories from Eclipse, LocationTech, and PolarSys projects.

The database records that 2,344 software developers have contributed at least one commit to at least one open source project that is included in the Eclipse Neon release since the beginning of time.

This includes projects that are listed on the release page as well as any subprojects that release with parents that are listed. The Web Tools project, for example, is a single entry on the Eclipse Neon project list, but actually represents ten separate project teams.

The database does not record commits against SVN. Those projects that once used SVN but migrated to Git are included, but the solitary project that remains in SVN, Subversive, is not included in the the number of contributors.

According to the database, the very first commit happened on May 2/2001. I know that there was work done before that, but that’s the first commit that we record. This almost certain masks some of the original contributors.

Way back in the beginning of time, all of our open source projects used CVS which has an important limitation: CVS (and SVN for that matter) only records the identity of the committer, not the author. Author information is tracked elsewhere and I haven’t sorted out a way for the query to take this tracking into consideration, so many non-committer contributors from the CVS era are not represented.

It’s also possible that there is some duplication. We have pretty complete data on changing email addresses, so I have the ability to multiple email addresses, as well as committer IDs and other identifiers from the the CVS days into actual committer names, so I’m absolutely confident that the number is in the right ballpark.

So maybe let’s just say ~2,300 people have got us to where we are today.

FWIW, there are 16 contributors named Mike, 27 named Michael, 10 others with variations of Michael (e.g. Mickael and Mikael), and one Mik. I’m trying really hard to sort out a “drop the Mic” pun, but nothing’s coming to the surface. A little help?

Posted in Neon | 1 Comment

These Are the Daves I Know

Over the years, many people have contributed to Eclipse projects, including some thirty-nine software developers (39) named Dave or David. This list includes everybody who has ever made a least one contribution to one of the many projects that have opted to participate in the Neon Simultaneous Release since the beginning of time as recorded in our Git commit logs.

It’s important to note that prior to our adoption of Git, we didn’t record contributor names in commit records. So some Dave contributors from the early days may not be present in this list. Also, there are probably a Dave or two in the single SVN repository that we still maintain for the Subversive project.

So… without further adieu, here are the Daves I know (some of them are David, but most of them are Dave): David North, Davy Landman, Dave Lerner, David Akehurst, David Berger, David Meng, David Slater, David Nemeth, Dave D, David E. Narváez, David King, David Ostrovsky, David Pletcher, David Kaspar, David Sciamma, David Salinas, Dave Locke, David Dubrow, Dave Stevenson, David Soto Setzke, David Servat, David Lauzon, David Daoust, David Pursehouse, David Kelsey, David Wootton, David Borowitz, David Michonneau, David Springgay, Dave Orme, Dawid Pakula, David Dykstal, David Inglis, David Audel, David Green, David Carver, David Steinberg, David McKnight, and David Williams.

Thank you, Daves, for your contributions!

Bonus points if you can identify the Dave that I’ve known since my university days…

For those of you who don’t get the title reference, let me introduce you to some early 1990s Canadian humour…

If you’re keeping score, there’s only one Gunnar.

Posted in Uncategorized | 1 Comment

Eclipse Platform on Java 9 b118

I’d taken a little break from testing Eclipse Platform on Java 9 Jigsaw builds. A few nights ago, I pulled down the latest builds of both and gave them a spin.

I pulled down build 118 of the 64 bit Linux version of the Java 9 JDK. The last time I did this, the Jigsaw builds were separate, but they’ve since replaced the Java 9 builds, so when you download Java 9 you now get Jigsaw. It’s currently delivered as a .tar.gz file, so I extracted it into a directory on my system.

I then turned my attention to the Eclipse Installer which has a handy feature that hunts down JREs installed on your system and lets you pick the one that you want to use. It also has a handy feature that lets you manually add JREs to the list. The installer includes some logic to help the user avoid making a poor choice, and changes in the way that the JRE reports its version means that the installer doesn’t recognise this particular version of the JRE as a JRE and won’t let you select it (see Bug 493759). I decided to install the latest Neon M7 build anyway using a Java 8 JRE. I launched my newly-installed configuration.

I added the Java 9 Support (Beta) feature from the Eclipse Marketplace. You can install it yourself by simply dragging and dropping the “Install” button below onto your Neon version of Eclipse Platform:

Drag to your running Eclipse workspace to install Java 9 Support (BETA) for Neon

The last time I tested this, I needed to have Eclipse JDT run on the Java 9 JRE to use the Java 9 support; but now, the Java 9 support seems to work just fine when running the Eclipse JDT on a Java 8 runtime. The JDT team has done some significant work, it seems, since I last looked.

I added the Java 9 JRE to the Installed JREs page in the preferences and was able to create and run a Java 9 application.

InstalledJREs

The bits that I tested all seem to work as expected; e.g. the Package Explorer lists modules.

Java9App

I only spent a few minutes poking around before moving on to the next task: I wanted to get the Eclipse Platform itself running on this Java 9 build.

I tweaked the eclipse.ini file to point to the Java 9 JVM, by adding the path to the JVM at the top of the file:

-vm
/home/apps/jdk-9/bin

I launched the Eclipse Platform and got as far as selecting the workspace before it died with a message to check the log. I opened Bug 493761. The JDT team engaged within hours. Tom Watson (from the Equinox project team) determined that a change in the boot classpath configuration is the cause and suggested as a workaround to add some additional configuration to the configuration file (after the -vmargs line) to ensure that the necessary modules are available.

-addmods
java.se.ee

For more information, see JEP 261. With that modification, everything works as expected.

The workaround is not optimal. For one, the Eclipse Platform fails to launch with this option when you launch under Java 8. The JDT team is looking for a better solution.

Your help is appreciated. If you have the time, please test this yourself and report any new information that you discover.

Posted in Java, Neon, Screenshots | 3 Comments

Git Staging View

I’ll admit that I never bothered much with the Git Staging View before now, preferring instead to make all of my commits from the Commit dialog.

The milestone seven (M7) builds of the Neon versions of the various Eclipse IDE downloads now all bring the Git Staging view to the top instead of opening the Commit dialog when you invoke the “Commit…” command.

Screenshot from 2016-05-16 15-33-08

This is configurable in the preferences (on by default).

Screenshot from 2016-05-16 15-46-51

Using the view requires a bit of a change in my habits, and so it will probably take a few iterations before it starts to get comfortable, but it’s a change that I think is worth making: probably every other time I open the Commit dialog, I have to close it to go and copy some bits of a comment that I want to put into the commit message, before opening it again. The non-blocking nature of views makes this problem go away.

Dragging and dropping between unstaged and staged changes is also darned handy.

The Eclipse Neon Simultaneous Release is scheduled for June 22/2016. Milestone (developer) builds of the Eclipse IDEs for this release are now available as Developer Builds on the Eclipse download site.

Posted in Neon, Screenshots | 8 Comments