Swing by to Talk about SWT and JavaFX

Eclipse SWT support for GTK3 has improved dramatically since the Eclipse Mars release: the latest milestone and nightly builds work and look great on my Fedora 22 box. There’s still some work to do, but the progress since Mars is impressive. Fixing SWT/GTK issues requires a special set of skills: if you have those skills, you might find our work item to Improve GTK 3 Support interesting.

Or, if you just want to see how you can help, drop by the EclipseCon 2016 Hackathon and we can try and hammer out a fix or two together. A few actual Eclipse Platform committers will be at the conference, so I’m using “we” in the royal sense.

If JavaFX is more to your tastes, consider attending the two EclipseCon sessions being lead by the Eclipse community’s JavaFX expert and Eclipse e(fx)clipse open source project lead, Tom Schindl: Develop Slick Rich Client Applications with Eclipse 4 on JavaFX, and Smart, slim and good looking – Building Smart Editors with Eclipse and JavaFX.


EMF Edit UI for JavaFX allows you to view your EMF models in JavaFX TextFields, ListViews, TreeViews and TableViews with only a few lines of code.
(from the project website)

Tom can help you get started building JavaFX applications using Eclipse; he’s also the best person to help you build Eclipse Rich Client Platform applications, editors, and IDEs with JavaFX as a base.

You can also learn about some fascinating work being done in the Eclipse Integrated Computational Environment (ICE) project in the form of Adventures in 3D with Eclipse ICE and JavaFX (ICE leverages the JavaFX/SWT integration layer, FXCanvas). Speakers Tom McCrary and Robert Smith, as members of our Science Working Group, are involved in some very cool new work being done at the Eclipse Foundation.


Alex McCaskey and project lead Jay Billings running ICE on ORNL’s EVEREST Powerwall
(from Jay’s post from July of last year).

See you at EclipseCon!

EclipseCon NA 2016

Posted in EclipseCon, Hackathon, Java | Leave a comment

Connect with Eike Stepper at EclipseCon 2016

If you need to get a development environment configured just right and share that configuration with your team, you need to connect with Eike Stepper, the project lead and resident expert on our awesome (Oomph-some?) Eclipse Installer technology.


The Eclipse Installer technology, based on Oomph, excels at doing very simple sorts of installations, like pulling together and assembling the pieces of the Eclipse IDE for Java Developers. But that only scratches the surface: you can build and share a script that realizes a complete development environment that includes extra plug-ins, clones of your Git repositories, tasks from your issue tracker, specific workspace preferences configurations, and more. The Eclipse Oomph Installer Technology can get your developers up and running in a matter of minutes.

Eike will cover Oomph topics during the conference: he’s hosting a tutorial and a talk with Ed Merks. Frankly, I can’t say enough good things about Ed and Eike: just spending a few minutes in their proximity will make you smarter. Eike is also presenting some exciting updates to the very cool Eclipse Connected Data Objects (CDO) technology.

You’ll have a chance to work directly with Eike at the EclipseCon 2016 Hackathon on Wednesday, March 9 from 11:15 to 11:50 am.

EclipseCon NA 2016

Posted in EclipseCon | Leave a comment

Let’s Treat Eclipse Neon More Like a Product

It always comes as a surprise to people when I tell them that we at the Eclipse Foundation don’t consider anything that we distribute to be a product. It’s a surprise, because basically everybody in the world thinks that the Eclipse IDE is a product and has thought that way for most of the last fifteen years. We’re starting to come around.

With the Mars release, we started an Every Detail Matters initiative which was intended in part to started filling some important holes in our product story. This took the form of a new installer, some user experience improvements, better dissemination of product information (e.g. an proper new and noteworthy document), the automatic error reporter, and more.

We’re going to do more with the Every Detail Matters for Neon, introducing some bigger improvements in the overall user experience, from when the user first hits our website through to the creation their first “Hello World” application.

I’m pretty excited about what we’re doing, and I’m especially excited to be talking about it at EclipseCon 2016. Here’s the abstract for my talk titled “Let’s Treat Eclipse Neon More Like a Product“:

Every year, the Eclipse simultaneous release brings together the hard work of dozens of open source projects into a single coordinated release. But you probably already know that. You probably already live that.

While most Eclipse committers don’t tend to think of the simultaneous release as a product, most of our users do. For millions of software developers, the the installer and many flavours of Eclipse IDE are products. While it’s important that we carefully manage expectations, it’s also important that we understand and respect the expectations of our massive user community.

We’ll start this session with a quick overview of where we are now with regard to Eclipse-as-a-product and survey the current state of the Eclipse user experience. We’ll discuss some of the little things that project teams can do to improve the user experience, how we fit product features into our project structure, how we improve our support channels, and how to tap into the funding available to work on Eclipse IDE improvements.

There’s all sorts of related content in the conference sessions,and opportunities to get involved in the process. Be sure to visit me at the Hackathon.

EclipseCon NA 2016

Posted in Conferences, EclipseCon, Hackathon, Mars, New and Noteworthy | 1 Comment

Council Meetings at EclipseCon 2016

We’re going to host the Architecture and Planning Council meetings during the conference (on Thursday) at EclipseCon 2016. This will be a great opportunity for the councils to connect and plot how to make the Eclipse community even better.


We’re still in the early stages of planning, but one idea that I’ve floated is to have the councils each use some of the time to host panel discussions to connect formally with the community and answer some questions.

The Eclipse Architecture Council (AC) serves the Community by identifying and tackling any issues that hinder Eclipse’s continued technological success and innovation, widespread adoption, and future growth.

The Eclipse Planning Council (PC) is responsible for the simultaneous release (Neon). They are further responsible for cross-project planning, architectural issues, user interface conflicts, and all other coordination and integration issues.

Of course, you can connect with members of the councils at any time during the conference (e.g. over lunch). Chances are that you’ll find members of both councils hanging around the hackathon as well.

Oh, and there’s also lots of great sessions. I’m particularly excited to be part of Let’s Treat Eclipse Neon More Like a Product.

See you at EclipseCon 2016!

EclipseCon NA 2016

Posted in Community, Conferences, EclipseCon, EDP | Leave a comment

The 2015 Revision of the Eclipse Development Process

The Eclipse Foundation Board of Directors approved a new revision to the Eclipse Development Process in its meeting on November 2/2015. It took effect—replacing all previous versions—on December 2/2015. This is a minor revision that primarily updates the document to reflect the evolving reality of how our open source projects operate. We made, for example, some changes to the section on reviews to reduce wordiness and reflect the lighter weight process that we’ve adopted over the past few years. We have also generalized the use of the term “frameworks and tools” to “frameworks and applications” to acknowledge the fact that our project teams are creating deliverables that expand on our traditional focus on tools.

Perhaps the most potentially controversial change in the formal of “Freedom of Action” as a principle of the Eclipse Development Process. This addition formalizes the implied requirement that project teams engage in practices that ensure the continued viability of the project, independent from the continued availability of external resources and services, or continued participation on any single individual, organization, or group. This effectively formalizes the requirement that project teams must use only those resources that have been approved by the Eclipse Foundation for critical project operations.

Finally, we’ve decided to change how we mentor new projects. New projects now only require a single mentor from the Eclipse Architecture Council (where they had previously required two). To ensure that new projects have access to the information and resources that they need to be successful, we’ve set up new mailing list, incubation@eclipse.org, that incubating project team members can join to participate more directly with each other and mentors from the Eclipse Architecture Council. Participation in this list is optional, but encouraged for all committers working on projects in the Incubation Phase. Please do feel free to subscribe to the list even if your project is not in the Incubation Phase: this list provides an excellent opportunity to share hard-earned wisdom and generally make our projects stronger.

Note that there is both a list of issues that were addressed in this revision at the bottom of the document and a link to a “diff” document should you be interested in gaining a more complete picture of all of the changes.

Posted in EDP | Leave a comment

Running Eclipse Neon on a Custom Java 9 Image

I’ve started tinkering with the creation of custom Java binary runtime image files. An image file is a configuration of modules packaged up as a runtime platform. The default image contains, basically, everything that makes up the Java runtime. A custom image can contain some subset of that.

I created, for example, an image that includes only the “compact 3” profile, configured a JRE in the Eclipse preferences and specified it as the JRE System Library on a Java project. Eclipse Neon handles the custom profile exactly as expected.


Note the abridged list of modules under the JRE System Library in the project, and the somewhat simpler Module Dependencies view (as compared to the similar but somewhat more disturbing view for all modules).

Creating a custom image is easy. Just use the jlink command in the Java 9 + Jigsaw builds. I used the command as below, to create a custom image that contains just what I need to run Eclipse.

$ bin/jlink --modulepath jmods/ --addmods java.desktop,java.logging,java.sql --output /home/java9/runtimes/desktop

This creates  directory named desktop that contains everything needed to run the defined subset of Java (i.e. the java.desktop, java.logging, and java.sql modules). I’m a little disappointed that Eclipse requires the java.desktop module; I had hoped that I might get away without including Swing and AWT in the image, but there are at least a small number of references to AWT classes in the Eclipse Platform and to include them I need to pull in the entire desktop module.

I’m probably missing a module, since I haven’t poked in all of the corners in all of the Eclipse features yet. I got this far by resolving the ClassNotFoundExceptions as I encountered them. Eclipse will be more helpful at identifying missing modules if pull in the source code. The jdeps utility may also be helpful.

Note that in order to debug, you need to add the jdk.jdwp.agent module in the image so that the debugger can actually connect to the runtime.

The resulting image file (~40MB) is about 30% of the size of the full JDK image (~140MB) and 60% of the size of a Java SE image file (~67MB). The runtime binaries and resources are more-or-less the same size for every configuration (~180MB on my Fedora 22 system), but there are some differences depending on the modules that are included: my desktop configuration includes some libraries and fonts that are not included in the compact3 configuration, for example.

I’m not quite sure what this means yet with regard to running Eclipse on custom Java 9 images, but it’s certainly clear that with this early beta of Java 9 support for Eclipse Neon, the Eclipse IDE already does a pretty good job of helping you write plain-old-Java applications using Java 9.

Note that I’m a couple of builds behind on JDK 9 + Jigsaw, so my file size numbers may be a bit bogus. I’ll update to the latest and greatest for my next instalment.

EclipseCon NA 2016

Posted in Eclipse 101, Java | Tagged , , | 2 Comments

Visualizing Java 9 Module Relationships

As I stated in an earlier post, I’ve been running Eclipse Neon on the Java 9 + Jigsaw builds for a little while and haven’t had any issues. I spent a few hours over the weekend tinkering with some modularity tool ideas. I wrote a little plug-in for Eclipse Neon that visualizes the connections between the various modules.


The implementation is a little rough right now as I was focused on just sorting out how to get the various bits of technology to work. The Modules Dependencies View updates whenever the user highlights a Java project (e.g. in the Package Explorer, Project Explorer, or Navigator): it queries the Java runtime associated with the project for its list of modules and readability associations between them, and then uses Eclipse GEF Zest to visualize the results.

The part where I query the Java runtime is a huge hack right now, but the good news is that in playing with the visualization, I may have sorted out a better less hacky way of getting this done. More on this later.

I’m also just relearning how to use Zest (not that I was ever much of an expert with it), so there’s probably more that I can do with the layout algorithm. One thing that I did do was make it so that you can drill down into any single module with a double-click.


While I was at it, I threw together a quick tree view that lets you drill down through the reads relationships between modules.


It’s all very ugly of course, but it’s been pretty helpful for me see all the parts. I need to test this with a custom jimage (perhaps I’ll build one based on one of the compact profiles).

It would also be cool to include full build path of the Java project (e.g. workspace contents and JAR files) in the visualization. I also completely disregarded layers and should probably put some thought into representing them.

I haven’t pushed out the code yet; it will appear in Eclipse Labs when it’s a little more fully-baked.

Note that JDK 9 is going to slip a bit: with less than two weeks to go before the “feature complete” deadline, a proposal has been put forward to extend the release date by six months.

Posted in Java, Uncategorized | Tagged , | 1 Comment