My Journey to Mars, Eclipse Mars

Wow, Eclipse Mars is almost finished and it’s been very busy for me and those I’ve been working with. We have a lot of exciting new features coming and I can’t wait to get them into the community’s hands and see where they take them.

I’m going to write more over the next few weeks on each of these, but I thought I’d give an overview of what you can expect for Mars. They all stem from a common theme, make Eclipse easier to use and lower the barrier to entry for new users, especially those writing C and C++ as a hobby, the new breed of hobbyist computer engineers using $10 computers to build amazing electronics projects. New users mean a growing and vibrant community.

Here are the highlights.

Serial Port Library

CDT has a pretty interesting native library that provides interfaces to native tools that the Java run-time doesn’t. This includes a Process subclass called Spawner that can send Unix signals, a Pseudo TTY interface (PTY) that can be used to set up terminal like interfaces to processes, and access to the Windows Registry.

One thing that is really common with these new $10 computers, especially the microcontrollers like Arduino is that you need to connect to them with a serial port to see what’s going on. For whatever reason, the serial port libraries out in the open were all GPL/LGPL and the main one, rxtx, has disappeared. Serial port programming isn’t rocket science, so I wrote my own library and added it to the CDT native feature. My first use is with the Arduino CDT covered below.

Remote Target Management

As I was building the LaunchBar (coming up next), I needed a way for the user to select which system to launch on. I made one that was pretty simple that adapted the targets such as those we were using for QNX and BlackBerry. I then started adding features, like a View to interact with the targets and then thought about a services architecture that would add command shells, remote launching, remote file access, i.e., a full blown target management system.

Well, that reminded me of Greg Watson (from PTP fame)’s talk from a few years ago about the fact we have too many target management systems, and none of them do everything we need. So he started one that does. I decided instead of writing my own, I’d add my vision to Greg’s and come up with an uber flexible, services oriented target management system. The beauty is that it’s easy to adapt to any existing TM system. And we’ll continue to build out features and make it a suitable replacement for RSE in upcoming releases.

Screen Shot 2015-05-18 at 1.56.06 PM

The LaunchBar

The LaunchBar has been the focus of my team at QNX’s efforts to fix up one of the biggest usability issues we see with Eclipse, the whole mechanism to launch the applications you’re building with the IDE. There’s been some work to improve that over the years, such as the launch shortcuts, but frankly, other IDEs do a much better job at this.

We felt it was important for the user to know exactly what was going to happen when they hit the run button. And that’s accomplished by showing the current selection, i.e. What you’re going to launch, Where you’re going to launch it to, and How you’re going to launch it. How is simply the launch modes we’ve had in the past but make more accessible. The Where relates to my work with the Remote TM system. In this day with embedded targets and cloud servers, we’re often building software that’s going to run somewhere else than our desktops.

The most important aspect what helping the user define What they’re going to launch. And really, my objective here was to make it so that the user never needs to go the the launch configuration dialog for the most common cases. To help with that, we have an automated system the populates potential What’s. By default, launch configurations are a What, obviously, and that makes the launch bar usable with existing launch configurations. But the system is flexible, and What’s can be anything, for example, Arduino projects.

Screen Shot 2015-05-18 at 2.00.03 PM

Arduino C++ IDE

My first foray into the hobbyist computer engineer world was with Arduino. I bought an Arduino Uno and built a little system with a sensor and a wifi shield that was a kind of Internet of Thing. But after years of using professional IDEs, the last many being Eclipse, I wasn’t very excited about the standard Arduino IDE. Also, Arduino programming is done through this language called Wiring which, come on!, it’s so close to C++, why not teach hobbyists those last two or three concepts and “Program Your Arduino in C++ Like a Pro”.

And, hey, I know this great C++ IDE they can use. So, and this is the self serving part, I set out to build an integration for the Arduino toolchain for CDT. And it turned out pretty nice and I enjoy using it for my Arduino projects. And as a bonus, I get to use the same IDE, hell, same workspace, to program the server side of my Internet of Thing project. For me, that has always been the promise of Eclipse: One IDE to rule them all!

I have the plug-ins in CDT and they’ll be coming out in Mars. It’s really only a preview at the moment and you’ll need to have the standard Arduino IDE installed for it to work. As I was wrapping up the Mars work, Arduino released their 1.6 version and with it and pretty nifty library and BSP management system with an open data format. I plan on adding support for that system to the Arduino CDT plug-ins as well and that should eliminate the need to install the Arduino IDE if you so desire.

The Journey Continues

As I mentioned, I’ll write a lot more about these features in the upcoming weeks. It’s going to be hard to try them without a little documentation and that will come here on my blog for now until things mature. There’s a lot more ahead as I get feedback from the community and people try to use these things in different configurations. I already have great feedback from the Red Hat JBoss guys who are trying to use the LaunchBar for WTP that’s resulted in a pretty big last minute change. But this stuff is only successful if people use it and contribute back so I’m more than willing to listen.

Also my journey into the computer engineer hobbyist world continues beyond Arduino. I have a Raspberry Pi B and I have been able to build an ARMv6 hardware float toolchain for it. We’ll likely make this the first official embedded target support provided by the CDT as an example for the embedded vendors to follow. We should have done that a long time ago.

I’ve also just purchased a couple of ESP8266 chips. They’re little microcontrollers inside a wifi chip with a healthy number of GPIO pins, all for $10 or less. The Chinese company that makes them has put out a pretty good SDK and the toolchain is again standard GCC. I need a CDT integration for these too :).

I mentioned in my note about EclipseCon that I think this is probably the most exciting time to be in the Eclipse community since they early days. So many new features and great work being done by a diverse team of really smart people has breathed some much needed new life into our favourite IDE.

EclipseCon 2015, the Ship Tacks

I’ve been to all 12 EclipseCon North Americas. I especially love coming to this year’s venue, the Burlingame Hyatt, because it hosted the second one in 2005 which has been one of my favourites. It was a very different EclipseCon back then. There were probably more product and marketing managers than developers and the buzz was incredible. We had two of the greats in the modelling industry going head to head, IBM Rational and Borland, and it was a fun spectacle to watch from our CDT viewing rooms on the periphery. I’ll never forget it and I always take a pause when I get there to soak it all in again.

In recent years, EclipseCon has become a developer’s conference, and frankly we developers prefer it that way. You don’t get the same numbers or the same marketing buzz, but we build some very important relationships that carry us throughout the year and we wouldn’t survive without it. I’ll never forget our last time in Santa Clara and Kai Toedter still working away at the e4 challenge as we closed the bar at 2 in the morning. We developers know how to have our own fun.

It’s been a hard few years for Eclipse though, at least for the IDE. It’s been kind of sad, but we spent a lot of time complaining and worrying as more and more of our friends from the Platform started working on Jazz and Orion and not on the Eclipse platform. Having been there, I know the business decisions behind such things and it’s pretty easy to understand the need. But it didn’t make us happy, and we were somewhat counterproductive fussing about it.

This year, though, was totally different. We talked very little about that past. It was replaced by discussions and demos of the cool things we are working on now to revitalize the Eclipse IDE that we all know and love. My feeling of worry in the last few years has been replaced with feelings of hope and energy to continue on the fight to save it. And we have new leaders in the community driving it: Lars, Mickael, Sergey on the Platform, Max on Web development, Eike providing us some Oomph, Greg and myself on revitalizing target management with a new look at the Terminal and my new LaunchBar, plus all the great stuff still happening in the DSL and modeling space. Even the Orion guys seem open to working with the JSDT guys to bring the two technologies together and provide a great JavaScript experience in the IDE.

I’ll be writing about the things I’m working on over the next few weeks, including some new energy we got out of the CDT Summit and an interesting chance meeting that will bring some interesting tooling for Arduino fans. We have a lot of work ahead and it’s important we communicate and work with the community to make it right.

Eclipse solved a problem we had 15 years ago over the need for an industry standard and open platform where we could install all our tools and have them interact with each other to make a greater whole. 15 years later, we still need that. And as Eclipse jumps back to life, I’m excited for great things again and am working with a great group of developers who are all intent on making it happen. EclipseCon gives us that much needed face-to-face and the opportunity to show the community what we’re doing and invite them to join in on the fun. I can’t wait until the next one.

Making a UX splash for Mars

Over the last few weeks, I’ve been putting the finishing touches on our LaunchBar contribution to Eclipse. It started out of work we did for BlackBerry Momentics. Our goal was to simplify Eclipse as much as possible so new developers wouldn’t be so intimidated by it. One of my pet peeves has always been the launch experience. The poor new users who have to dive into the fire and figure out what all those settings in the Launch Configuration dialog are, let alone learn what a launch configuration is.

After looking around at how other IDEs handled launch UI, we built a sort of “best of” and put all the great ideas together into a uniquely Eclipse LaunchBar. The LaunchBar provides selectors for launch mode, thing to launch, and place to launch it. It also provides buttons to build the projects for that launch, to actually launch, and a button to stop all current launches. You always know what’s going to happen yet easy for new users to understand but with all the power of launch configurations only a click or two away.

Screen Shot 2014-03-14 at 10.08.11 AM

I’ll write more about the LaunchBar and how you can use it in your environment over the next few weeks. I’ve retargeted the release to Mars so that I can integrate it with the PTP’s org.eclipse.remote target management system, which I’ll also blog about soon. But to give a teaser, I thought I’d show what I’m using it for today.

I’ve become a fan of Arduino and similar microcontrollers (I have my Spark Photon order in too). My next project is to produce some sort of wearable that lets you put RGB NeoPixels over you’re body along with the microcontroller and a microphone so that the pixels flash and change color to the music you’re listening too. My prototype board looks like this:


Now, I could use the Arduino IDE to build this, but given the title of this blog is CDT Doug, you know I want to use the Eclipse CDT and things like the LaunchBar and Remote framework. And here’s what it looks like so far:

Screen Shot 2015-01-11 at 12.54.56 PM

As you can see, the LaunchBar is pretty natural. Click the Play button to “Run” “ArdunoTest” on “Uno”. Run is the launch mode, ArduinoTest represents the project for which a launch configuration will be automatically generated, and Uno is my Remote Connection to the Arduino board hanging off my USB serial port.

There’s much more to come but I’m totally excited how this is working out. I use the LaunchBar every day to launch various Eclipse run-time workbench configs and Maven jobs and now C++ project launches for my microcontroller. I can’t wait until I can get it into more people’s hands and hopefully it can help get more people excited about using Eclipse again.

CDT in the New World

An interesting thing happened the other day which I think shakes some of the foundation I’ve had in my mind about the CDT. My vision was always for CDT to support C, C++, and related languages on every platform. And that has always included Windows. Mind you, we’ve never really done a great job there but we do have lots of users using it with Cygwin or MinGW and you can argue how well they support Windows application development.

The big news was Microsoft’s Visual Studio Community Edition which is a free version of their complete IDE for individuals and small teams. This is different from their Express editions which were severely limited in the end, including lack of 64-bit support, and the inability to install plug-ins into the IDE. No, the community edition is the full thing and is a pretty important step for Microsoft as they try to keep developer interest in their platform.

As long as Microsoft charged money for Visual Studio, I always thought CDT had a play. I’ve done a little work on supporting integration with their Windows SDK (which includes a 64-bit compiler) at least for build. Debug was always a big hurdle since you’d need to write a complete debugger integration that is very different from gdb. So, really, this integration barely worked. And now that VS is essentially free to the market we serve, there’s little point at continuing that effort. The same is essentially true with Objective-C support with Xcode on Mac, which even they are drifting away from to focus on their new language Swift.

But you know, despite giving up on a dream, I think CDT has an important role to play in it’s field of strength, i.e. support for the GNU toolchain, especially as used for embedded development with it’s new found focus as a pillar in the Internet of Things. As I’ve talked about on Twitter and on CDT forums, I am working on a CDT integration to support building C++ apps for Arduino. Once that’s done, I’ll shift focus to a more complicated environment around Raspberry Pi which I hope to add better remote debug support to CDT. Yes, I know everyone loves to talk about using scripting languages on the Pi, but I want to expose these hobbyists to the real world of embedded which is almost exclusively C and C++, and get them started using CDT.

I still haven’t given up on the desktop, at least desktop support with Qt. I really want to make CDT a first class alternative for Qt development. We have a good start on it and will continue with things like a project file editor, easier setup of builds, and import of projects from Qt Creator. The great thing about Qt is that it also is truly cross platform, allowing you to write your app to run on the desktop and then migrate it to your embedded device, such as the Raspberry Pi. And supporting both of these with the same project is one thing CDT is pretty good at, or at least will be once we fix up the UX a bit.

In the past, much like the rest of the Eclipse IDE, I think we on the CDT have focused a lot on being a good platform, almost too much. While vendors have done a great job at bringing the CDT to their customers writing for their platform, including my employer :), aside from the Linux community, few of us work on supporting the direct user of the Eclipse C/C++ IDE. I think focusing on CDT’s areas of strength and targeting specific open environments and not chasing dreams will help me contribute to the CDT in ways that will actually help the most people. And that’s most satisfying anyway.

I have a dream, an Eclipse UI dream.

Humour a madman for a second :).

A few months ago, I was pretty excited about the prospect of Eclipse running against a modern UI framework such as JavaFX. Modern applications have a flow or liveliness to them. They aren’t just a bunch of toolbar buttons and menus that take umpteen clicks to do the things you want to do. They move with animations and effects that make your app feel alive. Not everyone agrees that’s what an IDE needs, but I’d like someday to take the time and experiment to see if it does.

And I’ve seen some of what’s possible. Cole Markham’s talk at EclipseCon this year on using the JavaFX e4 renderers for the RCP apps he was building showed the potential. His apps are beautiful and much thanks to the CSS capabilities and animations in JavaFX. It can be done and it can be good.

But what of the Eclipse IDE? Originally I thought we could port SWT to JavaFX and then introduce JavaFX slowly into the vast collection of IDE plug-ins. From Tom Schindl’s great work on this and his experience with it, I’m not sure either of us, or anyone for that matter, thinks it’ll really work. The paradigms are just too different. Maybe JavaFX can evolve to make it closer (and it is indeed still a young API), maybe not.

Where to then? I sometimes go down a dark path looking to too see where the next revolution in IDEs would come from. Eclipse was quite disruptive back in 2000 and had great success. But have we reached a stagnation point forced on by the architecture and tragedy of commons it has brought onto us (without standards and with uber flexibility, every plug-in has been free to implement their own UX and many have)? Will IDEA lead the way with it’s better funding? Will QtCreator take over the C++ world? Or is everyone just happy with their text editors and command line tools that we’ll regress back to the 1990’s?

Well, if there is to be a revolution, a new IDE framework that will fix all that’s broken with the existing ones, I’d actually like to look back at Eclipse. Often when I explain why we have Core and UI plug-ins for all our projects, I’ll bring up that maybe one day we’d like to replace the UI with something else, something not SWT. And maybe this is it. Reuse the valuable Core plug-ins we have that support build and debugging and static code analysis and source control integrations, and replace all their UI plug-ins with new ones that use a new UI framework based on JavaFX.

Am I insane or naive to think that would work. Maybe I don’t think that would work. But I can dream. And maybe someone with the resources will think it’s a good idea and make that dream come true. Or maybe not.

Motion Sensor to Phone App – an IoT-kinda Project

My son Alex is autistic. That presents a lot of challenges for my wife and I and, of course, for him. He’s generally at peace, but suffers from a lot of anxiety in situations that are new and he really wants everything to work out OK. We also have a very nice backyard with a gazebo on the deck and days like today, my wife and I love to sit out there. But from there we can’t see if someone comes to the front door and we don’t want Alex to have to deal with solicitors or what have you giving him a situation he can’t handle.

So that was the germ of an idea, which of course for me, has grown to a pretty big hobby project (with work implications, of course). Searching for possible solutions, I ran into the Adafruit website which has some great tutorials on how to build gadgets for this very type of problem. They sell a motion sensor for $10 that I could place on the front porch somewhere to detect when someone came up (not everyone rings the door bell and the motion sensor is more interesting).

Now, I want the motion sensor to raise a notification on my phone when someone triggers it. Very cool problem for we architects to have to solve. First do I go Arduino, Raspberry Pi, or BeableBone? Given the simplicity of the hardware, a single sensor, doing a board that has a GPU and HDMI out seems like ridiculous overkill. So I’ve gone Arduino and bought an Uno as well. I love the Arduino because it gets you into the core of the embedded world. There’s no OS, just bare metal and your code, and a few library functions to get you going. Everyone with a computer science degree should have had to do something with an Arduino. It’s the absolute core of what computers are.

Next up, I have this web site,, which I host on DigitalOcean. It has an nginx front end to WordPress for this exact purpose, to host web apps as well. So I want my phone to connect to it, and the motion sensor so I can find out when it gets triggered. Adafruit sells a wifi shield for $40 which is supposed to be good. But to start, I’ll just use the serial port on the Arduino to send messages on my laptop and have a node.js server that forwards it to the server.

On the server, I’m going to use vert.x. I notice a few Internet of Things type projects that are using it. The plan is to have a vert.x vertical to watch for REST calls coming from node.js and eventually from the Arduino itself with the wifi shield. Phone apps will connect to the server using websockets managed by another vertical so that when the sensor triggers, it can send in a REST call which gets forwarded over the vert.x event bus to the websocket server which can the forward it to the phones. It’s beautiful in it’s simplicity and in the minimal amount of code I need to write to actually get this to work.


So it’s projects like this that feed my passion for the Eclipse IDE. I want to be able to do all of this from a single workspace. CDT to do the Arduino code, Nodeclipse to do the node.js server, m2e and JDT to do the vert.x server, and ADT for the Android app and Thym for Cordova. If I’m missing pieces, I will build them and make them available. A proper Arduino CDT port is first on the list. I’m also curious how easy it is to do vert.x development in Eclipse. And everything needs a good debug solution from end to end (which may be a challenge on the Arduino since it doesn’t have an OS). This would be a great showcase for the Eclipse IDE and it’s place in the Internet of Things. I’m going to do my best to get this working. More in future posts.

P.S. I hesitated to call this an Internet of Things project. Designs like this have existed forever. They were just industrial automation systems with reporting to a central server. But if it gets me noticed, then while in Rome…

Who are you building this for? A UX Story.

We had a great day yesterday at the Eclipse Day Montreal. The program was a perfect reflection of the diversity of Eclipse. Everything from IDE to RCP to IoT and beyond.

David Cummings, my partner in crime here at QNX, and I gave a talk on our work improving the user experience of our Momentics IDE, a lot of which we are now working on contributing to Eclipse. At the end of it we had a great discussion with the audience about how we enact change and make the improvements we need.

During that discussion I had one of those moments I treasure, when the words that explain what I’m thinking finally come and it links everything together. The question arose about how you deal with conflicting requirements. When you have features that people are used to and that advanced users appreciate but are things that overwhelm beginner users and make for a bad experience for them. Who wins?

My thoughts go like this. When you piss off an advanced users, well, they’re pissed off. They make a lot of noise, raise bugs, etc. When a beginner user gets pissed off, he stops using your tool because the barrier to entry is too painful. I chose the beginner. If you can get a new user to see all the greatness that we’re bringing with Eclipse, they get interested in it. They learn how to make plug-ins, and they eventually contribute to fix the things that bug them. The become the next generation of Eclipse committer, and it’s that next generation we desperately need right now.

I’m not saying we do things to deliberately piss off advanced users. We learned that with our work on the Launch toolbar. We make it great for beginners but advanced users found it useless and turned it off. In the latest iteration, we’ve fixed that and made it easy for advanced users to get at the properties pages to make the tweaks they want. It’s a balance, but if you don’t make the best attempt at reaching that balance, it actually harms the community. I wish more community leaders would understand that.

Anyway, I have had a couple of experiences now that confirm this actually works. On the CDT today, we have a fantastic young committer who started using CDT in a previous job and loved it. He was so excited he spent his personal time learning about it and got deep into the code, something that is so awesome about open source. It’s all there. He eventually started contributing patches to the CDT to fix things that bugged him. He did so many that he eventually earned his commit rights and is one of our top committers at getting things done. He was so good, one of our other committers convinced him to go work with them and now he works for an Eclipse IDE group and contributes to Eclipse as his day job.

And he isn’t the first. A number of our committers past and present came that way. I love these people, because they did it because of their passion for making great tools, not because they’re employers told them to. And it’s more committers like that who will help us keep Eclipse alive and well and on top.

So when you’re looking at a user experience problem, think carefully about how you solve it and how you treat the people who raise it. Every one of those people are potential contributors. Make them happy.

CDT goes Dark – as in Theme

With the helpful push from Lars Vogel, and the great color work from Andrea Guarinoni, CDT now has support for the new dark them coming in Eclipse Luna.

I’ve wondered whether dark was good or not and the UX gang that we worked with at BlackBerry were pretty adamant that it was not a good thing. I’ve also read research that said that dark themes were OK, but not for people with strong astigmatism, such as I. For example, I can never use VGA monitors again since they’re totally blurry to me.

When I turned on the Eclipse dark theme for the first time today, it was everything I feared. But after a while, my eyes adjusted to the scheme and wasn’t bad. I think you have to be really careful how bring or dark you make the text, and some of the editors right now have a little to dark a grey for the text for me to focus on. But In general, I like it a lot. In fact, I switched to my current Momentics environment and felt blinded by all the white. “Once you go dark, it’s hard to go back.” (me on Twitter shortly after that).

There’s still other plug-ins that need to do the same change we’ve done for CDT. JDT, in particular which has a lot of black on black text making it unusable. But once it’s all together, I can’t wait to set it and leave it. And I can’t wait to try it with Momentics. I think embedded developers would love a dark theme. Most of the command line gang I see at QNX are all using dark theme terminal windows. Not that it’s a driver at all, but it might help the IDE feel more natural for them.

For now, here’s a peak at the CDT going dark :).

Screen Shot 2014-05-06 at 3.18.54 PM

Tutorial – A Simple Approach to Writing JavaFX Eclipse RCP Apps

I love the architecture of JavaFX. It has a simple and self consistent API that lets you build scene graphs of your UI layout and send it off to the GPU to render. That should give our apps snappier performance and allow for some pretty cool transitions and effects. I can see it replacing both Swing and SWT one day. Hardware accelerated user interfaces are where we need to go to make apps feel alive.

However in it’s current state, it’s tricky to set up your development environment in Eclipse, at least it is today. Tom Schindl does have his e(fx)clipse tooling, but I’ve come up with a simpler way that uses the standard Eclipse Java 8 support. For me, it’s always important to have a development environment that’s easy to set up and understand. Being able to use the base Eclipse tools for building JavaFX RCP apps lowers the barrier of entry for those who want to try out this new world.

This tutorial shows a fairly simply way to build an Eclipse RCP application using JavaFX for it’s user interface. It’s a simple Hello World similar to the standard JavaFX Hello World tutorial. To make it Ecipse-y, I created an extension point that creates JavaFX buttons. In the end, there are two plug-ins. The main one implements the entry point and the second one adds the Hello World button. I also show how to build an Eclipse product for all this so you can use Maven and Tycho to create an distribution you can hand out to people.

Screen Shot 2014-04-21 at 10.06.46 AM

public class EFXApplication extends Application implements IApplication {
    public Object start(IApplicationContext context) throws Exception {
        return IApplication.EXIT_OK;

    public void start(Stage primaryStage) throws Exception {
        primaryStage.setTitle("Hello World!");
        StackPane root = new StackPane();

        IConfigurationElement[] elements
            = Platform.getExtensionRegistry().getConfigurationElementsFor(Activator.PLUGIN_ID, "buttonProvider");
        for (IConfigurationElement element : elements) {
            Object o = element.createExecutableExtension("class");
            if (o instanceof IButtonProvider) {
                Button btn = ((IButtonProvider) o).createButton();
        primaryStage.setScene(new Scene(root, 300, 250));;
    public void stop() {


I won’t go into all the gory details. You can clone my git repo up on github,, to see what I’ve done. But there are a couple of important points I want to highlight and maybe spark discussion on how the approach could be made better.

To start, you need an Eclipse with Java 8 support. I’m focusing on the Oracle Java 8 VM and am leaving the Java 7 JavaFX solution behind. Java 8 is easier to set up, although as you’ll see it’s still not optimal. Get an Eclipse distribution that also has EGit and Maven so you can check the github repo and use the Maven launch (why are maven builds launches?) to build the product.

The biggest hurdle we need to get over is that JavaFX isn’t part of the Java 8 standard. It’s only available in the Oracle VM. So the Java 8 support in Eclipse doesn’t work for JavaFX out of the box, or at least, doesn’t do anything automatically to help you set it up. There are two issues we need to deal with. First, the JDT doesn’t make the javafx package visible. Which I guess is justified because the Equinox run-time doesn’t expose the javafx package either. JavaFX is in the extension class path so unless you enable that, you can’t build against it. Luckily it’s pretty easy to do, although after a while it becomes a bit of a pain.

First step is to make the javafx packages visible to the JDT compiler. Of course, make sure the Execution Environment is set to JavaSE-8 and that it’s linked to the Oracle Java 8 JRE. In the project properties under Java Build Path, click on the Libraries tab and expand the JRE system library. Edit the access rules and add one that makes javafx/** Accessible. That’s it. Now you can access all the goodies in the javafx package in your plug-in. Unfortunately, you have to do that for every plug-in. But it gets us going.

Screen Shot 2014-04-21 at 10.11.21 AM

The next step is to enable the OSGi runtime to load from the extension classpath when it tries to load you javafx classes. This is done at runtime by changing the default parent classpath for bundles using a handy system property. Add this to your launch configuration and any other places you will be launching your app from.


Now, I’ve been told this is dangerous because it gives access to all the classes in your extension classpath, even the ones you don’t plan on using and may conflict somewhere, or something like that. But since you’re using JavaFX, you’re tied to the Oracle Java 8 VM for now anyway, so I’m not sure it’s really that dangerous. I’d love to hear more if I’m wrong about that.

The third thing comes at releng time. If you’re using Tycho to build you’re product, then there are a couple of tricks you need to do there. First of those is that you need the latest JDT compiler that supports Java 8. At the time of this writing, Tycho only has a Java 7 JDT bundled with it, but that’s easy enough to fix with a little pom magic for your parent pom.



The other thing is that you can’t use the SWT-based binary launchers. They somehow set things up so the JavaFX application framework hangs on startup. I haven’t figured out why, but avoiding them works out best anyway. So I’ve written script based launchers and have bundled them as rootfiles in my project. I then set the ws property on all my environments to ‘javafx’. Some day we’ll need binary launchers that support this configuration, but for now, in the .product file, you need to turn off binary launchers. Works like a peach. I’ve even configured the Mac build to use bundling so it produces a folder which runs like a normal Mac app. Just make sure you have the Java 8 JRE set up as your default JRE.

# Mac launcher                                                                    
appRoot=`dirname $0`/../..
launcher=`ls -rt $appRoot/plugins/org.eclipse.equinox.launcher_*.jar | tail -1`
java \
    -Dorg.osgi.framework.bundle.parent=ext \
    -Xdock:icon=$appRoot/Contents/Resources/Eclipse.icns \
    -jar $launcher

And that’s it. No special tools required and you can get started having fun with JavaFX and Eclipse today. In my next tutorial, I’ll show how to take this example and grow it into an Eclipse IDE on JavaFX. LOL, I kid. But that’s the direction I’m heading. JavaFX gives us a great user interface framework to carry the Eclipse IDE into the next generation. We have some very hard problems to solve with backwards compatibility with an SWT port on JavaFX, but you got to start somewhere. Hopefully this little tutorial will get you excited about the possibilities.

EclipseCon 2014 Wrap Up

While I got a few moments here now that I’m home in Ottawa, I thought I’d jot down a few notes from last week’s EclipseCon. For me personally, it was the best ever. The diversity of discussions I had with so many talented people represent the diversity of my interests these days. I’m trying to build a great IDE for my platform’s customers and that goes beyond just the plug-ins we build for them, but to the entire ecosystem. We should be helping with all that because that value helps grow community and in the end our IDE gets better and my customers get happier and I get to work more on Eclipse :).

As soon as I checked into the hotel, I went up to the second floor where I was staying and looked out over the balcony by the elevator and a rush of memories flowed over me. I was at EclipseCon 2005 (mind you I’ve been to all 11 of them) which was held in that same hotel. There were ghosts here all week. I’ll never forget my first experience as a mentor for other projects when a number of groups interested in a Fortran IDE on Eclipse were trying to figure out how to work together and combine technologies. That’s where my friendship with the Parallel Tools team started and it was great to see Greg and Beth back again to relive those memories.

I was trying to figure out what the differences were back then to today. So many companies were scrambling to get their faces seen, joining the Eclipse board, starting top level projects, making product announcements. It was really different. The developers were there to get their projects known but they weren’t really the focal point. And I figure that’s it. EclipseCon is now a developers conference. It’s a place where the community gets to meet, and have a few beers together growing relationships, and to learn about what’s going on that might inspire. And I think that’s a perfectly good place to be. Yeah, the numbers are down a bit again, but I think the developers I talked to got way more out of it than we did back in 2005.

I have to admit that I started looking at JavaFX because it’s a shiny ball. I always seem to be chasing those. But there is a lot of interest in it’s capabilities in the Eclipse context. The CDT multi-core visualizer, for example, is a pretty complex visualization of the state of the dozens, if not hundreds, of cores in the chips these days. It’s all hand rolled SWT paint code with it’s own custom framework for drawing nodes and connectors. I have a feeling there are a lot of such visualizations that we could have in the IDE for representing data of all sorts. I think JavaFX can help there, but that needs to be validated. And if it does, that means we need the best architecture for the Eclipse IDE and JavaFX to make it work. I’ll blog more about that in the upcoming days. Talking with Tom Schindl and Steve Northover (who I’m so glad was there), I think we have some ideas. And, of course, it will require community support to pull it off and that’s the next challenge. To make sure we’re communicating the value.

I had a good chat with Gorkem Ercan from the Red Hat JBoss team. I got to know him when he was doing the Mobile Tools for Java back at Nokia. He’s now working on Apache Cordova tooling, which is good for us at QNX/BlackBerry since we support Cordova as one of our runtimes. I got to learn more about the type inferencing problem in JavaScript, i.e., how do you get content assist to return something useful. It’s a real hard problem and it was good to hear that they were talking with the Orion gang, who are also working hard at this problem. It was also good to see the VJET talk and they also seem to be working on that problem. Why we have two desktop JavaScript tooling projects in VJET and JSDT, I still don’t have an answer to, but it’s good to see that there are others out there who care about having good JavaScript tooling on the desktop.

And last but not least (for now), I had a few conversations with Lars Vogel over the week. He has done so much for the Eclipse community, it’s hard to measure and thank him enough. Everyone knows about his great tutorials on Eclipse development. We’ve all used them, or at least ran across them in Google searches. But what has me inspired is his drive to contribute to the Platform UI project and to solve all those problems we seem to always be complaining about. Why are we complaining and not putting that energy into contributing to make the Platform better. We all depend on it and have such a vested interest. We can’t and shouldn’t depend on others to do that for us. If Lars can drive through and work with the platform team and make change, well, I can to. And that’s what I intend to do. And thanks Lars for giving me that inspiration and I hope others catch it too.

Well, I’ll blog more as I dig into all these different areas. And I haven’t even mentioned the CDT summit we had on Monday and Tuesday. Great things coming there too. For now some sleep and some much needed family time. Then it’s back to work. EclipseCon has fuelled my passion and has given me hope that we can make the great Eclipse IDE even greater.