No Java? No Problem!

For the 2020-09 Eclipse Simultaneous Release, the Eclipse IDE will require Java 11 or higher to run.  If the user doesn't have that installed, Eclipse simply won't start, instead popping up this dialog: 

That of course begs the question, what should I do now? The Eclipse Installer itself is an Eclipse application so it too will fail to start for the same reason.  At least on Windows the Eclipse Installer is distributed as a native executable, so it will open a semi-helpful page in the browser to direct the user find a suitable JRE or JDK to install rather than popping up the above dialog.

Of course we are concerned that many users will update 2020-06 to 2020-09 only to find that Eclipse fails to start afterwards because they are currently running with Java 8.  But Mickael Istria has planned ahead for this as part of the 2020-06 release, adding a validation check during the update process to determine if the current JVM is suitable for the update, thereby helping prevent this particular problem.

Now that JustJ is available for building Eclipse products with an embedded JRE, we can do even better.  Several of the Eclipse Packaging Project's products will include a JustJ JRE in the packages for 2020-09, i.e., the C/C++, Rust, and JavaScript packages.  Also the Eclipse Installer for 2020-09 will provide product variants that include a JustJ JRE.  So they all will simply run out of the box regardless of which version of Java is installed and of course even when Java is not installed at all.

Even better, the Eclipse Installer will provide JustJ JREs as choices in the dialogs.  A user who does not have Java installed will be offered JustJ JRE 14.02 as the default JRE.

Choices of JustJ JREs will always be available in the Eclipse Installer; it will be the default only if no suitable version of Java is currently installed on the machine.

Eclipse Installers with an embedded JustJ JRE will be available starting with 2020-09 M3 for all supported platforms.  For a sneak preview, you can find them in the nightly builds folder.  The ones with "-jre" in the name contain an embedded JRE (and the ones with "-restricted" in the name will only install 2020-09 versions of the products).

It was a lot of work getting this all in place, both building the JREs and updating Oomph's build to consume them.  Not only that, just this week I had to rework EMF's build so that it functions with the latest platform where some of the JDT bundles have incremented their BREEs to Java 11.  There's always something disruptive that creates a lot of work.  I should point out that no one funds this work, so I often question how this is all actually sustainable in the long term (not to mention questioning my personal sanity).

I did found a small GmbH here in Switzerland.  It's very pretty here!

If you need help, consider that help is available. If no one pays for anything, at some point you will only get what you pay for, i.e., nothing. But that's a topic for another blog...

Eclipse JustJ

I've recently completed the initial support for provisioning the new Eclipse JustJ project, complete with a logo for it.

I've learned several new technologies and honed existing technology skills to make this happen. For example, I've previously used Inkscape to create nicer images for Oomph; a *.png with alpha is much better than a *.gif with a transparent pixel, particularly with the vogue, dark-theme fashion trend, which for old people like me feels more like the old days of CRT monitors than something modern, but hey, to each their own. In any case, a *.svg is cool, definitely looks great at every resolution, and can easily be rendered to a *.png.

By the way, did you know that artwork derivative of  Eclipse artwork requires special approval? Previously the Eclipse Board of Directors had to review and approve such logos, but now our beloved, supreme leader, Mike Milinkovich, is empowered to do that personally.

Getting to the point where we can redistribute JREs at Eclipse has been a long and winding road.  This of course required Board approval and your elected Committer Representatives helped push that to fruition last year.  Speaking of which, now there is an exciting late-breaking development: the move of AdoptOpenJDK to Eclipse Adoptium.  This will be an important source JREs for JustJ!

One of the primary goals of JustJ is to provide JREs via p2 update sites such that a product build can easily incorporate a JRE into the product. With that in place, the product runs out-of-the-box regardless of the JRE installed on the end-user's computer, which is particularly useful for products that are not Java-centric where the end-user doesn't care about the fact that Eclipse is implemented using Java.  This will also enable the Eclipse Installer to run out-of-the-box and will enable the installer to create an installation that, at the user's discretion, uses a JRE provided by Eclipse. In all cases, this includes the ability to update the installation's embedded JRE as new ones are released.

The first stage is to build a JRE from a JDK using jlink.  This must run natively on the JDK's actual supported operating system and hardware architecture.  Of course we want to automate this step, and all the steps involved in producing a p2 repository populated with JREs.  This is where I had to learn about Jenkins pipeline scripts.  I'm particularly grateful to Mikaël Barbero for helping me get started with a simple example.  Now I am a pipeline junkie, and of course I had to learn Groovy as well.

In the initial stage, we generate the JREs themselves, and that involves using shell scripts effectively.  I'm not a big fan of shell scripts, but they're a necessary evil.  I authored a single script that produces JREs on all the supported operating systems; one that I can run locally on Windows and on my two virtual boxes as well. The pipeline itself needs to run certain stages on specific agents such that their steps are performed on the appropriate operating system and hardware.  I'm grate to Robert Hilbrich of DLR for supporting JustJ's builds with their organization's resource packs!  He's also been kind enough to be one of our first test guinea pigs building a product with a JustJ JRE.  The initial stage produces a set of JREs.

In the next stage, JREs need to be wrapped into plugins and features to produce a p2 repository via a Maven/Tycho build.  This is a huge amount of boiler plate scaffolding that is error-prone to author and challenging to maintain, especially when providing multiple JRE flavors.  So of course we want to automate the generation of this scaffolding as well.  Naturally if we're going to generate something, we need a model to capture the boiled-down essence of what needs to be generated.  So I whipped together an EMF model and used JET templates to sketch out the scaffolding. With the super cool JET Editor, these are really easy to author and maintain.  This stage is described in the documentation and produces a p2 update site.  The sites are automatically maintained and the index pages are automatically generated.

To author nice documentation I had to learn PHP much better.  It's really quite cool and very powerful, particularly for producing pages with dynamic content.  For example, I used it to implement more flexible browsing support of download.eclipse.org so that one can really see all the files present, even when there is an index.html or index.php in the folder.  In any case, there is now lots of documentation for JustJ to describe everything in detail, and it was authored with the help of PHP scaffolding.

Last but not least, there is an Oomph setup to automate the provisioning of a full development environment along with a tutorial to describe in detail everything in that workspace.  There's no excuse not to contribute.  While authoring this tutorial, I found that creating nice, appropriately-clipped screen captures is super annoying and very time consuming, so I dropped a little goodie into Oomph to make that easier.   You might want to try it. Just add "-Dorg.eclipse.oomph.ui.screenshot=<some-folder-location>" to your eclipse.ini to enable it.  Then, if you hit Ctrl twice quickly, screen captures will be produced immediately based on where your application currently has focus.  If you hit Shift twice quickly, screen captures will be produced after a short delay.  This allows you to bring up a menu from the menu bar, from a toolbar button, or a context menu, and capture that menu.  In all cases, the captures include the "simulated" mouse cursor and starts with the "focus", expanding outward to the full enclosing window.

The bottom line, JustJ generates everything given just a set of URLs to JDKs as input, and it maintains everything automatically.  It even provides an example of how to build a product with an embedded JRE to get you started quickly.  And thanks to some test guinea pigs, we know it really works as advertised.

On the personal front, during this time period, I finished my move to Switzerland.  Getting up early here is a feast for the eyes! The movers were scurrying around my apartment the same days as the 2020-06 release, which was also the same day as one of the Eclipse Board meetings.  That was a little too much to juggle at once!

At this point, I can make anything work and I can make anything that already works work even better. Need help with something?  I'm easy to find...

Getting to the Source

As a Java developer using JDT, no doubt you are intimately familiar with Ctrl-Shift-T to launch the Open Type dialog.  You might not even realize this is a shortcut accessible via the Navigate menu.  So you probably will not have noticed that this menu also contains Open Discovered Type:

Eclipse has a huge variety of open source projects maintained in a bewildering collection of Git repositories.  Many are hosted at Eclipse:

https://git.eclipse.org/c/

Others are hosted at Github:

https://github.com/eclipse/

Finding the Git repository that contains a particular Java class is like finding a needle in a haystack.  This is where Open Discovered Type comes to the rescue.  Once a week, Oomph indexes every *.java file in every Git repository hosted by git.eclipse.org and github.com/eclipse.  The Open Discovered Type dialog loads this information to populate a tree view of all these packages and classes.

Please read the help information the first time you use it.  It was written to help you get the most out of this dialog.  Also be patient the first time you launch the dialog; there's a lot of information to download.

Suffice to say, you can use the dialog much like you do Open Type.  So here we search for JavaCore and discover all the classes with that name:

We can select any one of them and discover all the Git repositories containing that class and we can use the context menu for each link for each repository or for the specific file in that repository to open the link where we want it opened.  From that link, you can of course see the full history of the repository or specific file.

As a bonus, if this repository provides an Oomph setup, you can easily use that Oomph setup to import the sources for this project into your workspace. If there is no Oomph setup, you'll have to do that manually.

In any case, contributing to Eclipse open source projects has never been easier.

And Now for Something Completely Different

It's been 5 years since I last blogged, so I had to delete 500 SPAM posts when getting started again.  Much has happened over the past years, some of them not so great. When you start to get old like me, you must deal with the older generation gradually passing on and health problems, such as coronary re-plumbing, can become an ugly fact of life.

I've been working with itemis for the past 11 years, but that now draws to a close.  I wish to thank them for their generous support over all these years.  Many of you might thank them as well because much of what I've contributed is thanks to their funding.  Though admittedly I have the nasty habit of working like a maniac, beyond any reasonable number of working hours, regardless of whether or not there is financial reward.  Cool things are just so compelling. But the worst habit then is not bothering to document or advertise all these cool new features as they become available, but rather to dive into the next obsession because somehow that's more compelling.  Compulsion is a bit of a Merks' family trait, e.g., my sister has more than 20 dogs, though it's easy to lose count...

In any case, most of my obsession over the last year has been related to working with Airbus.  I don't normally talk about my customers, but given they were gracious enough to allow me to demo at last year's EclipseCon the software being developed at Airbus, it's common knowledge anyway.  My goodness but that was a creative and cool project! Unfortunately that too has, as is the case for all good things, come to an end.

I immediately dove into generating a quality report for the Eclipse SimRel p2 repository; there's no rest for the wicked nor for the compelled.  I used EMF's Java Emitter Templates (JET) for implementing that, just as I did for generating the full site information for  EMF's Update Sites  as part of migrating the build to Maven/Tycho.

Speaking of which, did you know that you can make it trivially easy for your contributors to set up a development environment? Just have a look at EMF' build page.  Also, did you know that there exists such a thing for the complete Eclipse Platform SDK as well? Of course not, because I never bothered to tell you!

What's really supergeil (yes, I live in Germany and speak fluent Denglish) about the installing an environment with the full Platform SDK, or some subset there of, is that you can easily see all the Git history of each source file, so you can see what exactly has changed and evolved.  Also, when developing new applications, you can easily search for how the Platform implements those things; then you can snarf and barf out your own solutions, with all due respect for the EPL of course.  You can even find out all the places that a constant is actually used; you cannot do that against binaries because constants get in-lined.  Also, if you see some label in the IDE, you can search for where it comes from, some *.properties file somewhere no doubt, and then you will know the name of that property and can easily find where that's defined and how that's used in the code.  You might even contribute fixes via Gerrit commits!

But I digress.  I was using JET to generate a nice helpful web page with information about all the problems in the SimRel repo, or in any arbitrary repo actually, i.e., invalid licenses, unsigned content, missing pack200 files, duplicate bundles, inappropriate providers, and so on. But then I got frustrated that JET templates eventually get really hard to read, especially as they become more complicated.  Then, when you need it the most, all the nice features of JDT are missing while editing the scriplets and expressions in that template. So as I am wont to do, I digressed further and spent the better part of the last two months working on a rich editor for JET.  I'm sorry (not!) that I had to violate a few API rules to do so, but alas, API rights activists is a topic for another blog because that's a long digression.  The good thing is that the JET editor is finished now; it will be in 2019-09's M3.  Here's a sneak preview:

Yes, that's content assist, just is if were in a real Java editor! Not only that, this time I wrote documentation for it in EMF's doc bundle. And, to top that off with icing, this time I blog about it.  Perhaps only three people in the world will ever use it, but I am one of those three people and I love it and I need it even for working with EMF's code generation templates too. So now I can pop this off my digression stack and go back to generating that p2 repo quality report.  I've been doing that for the past week, and it's almost ready for prime-time.

But then at this point, I must ask myself, where is the financial gain in all this?  My local neighborhood fox, I've named him Fergus,  might be trying to tell me something.

Perhaps you should be a little more sly.  Perhaps the endless free goodness too must come to an end...

A Floor Wax or a Dessert Topping?

For those as old as I am and as influenced by American culture as most Canadians certainly are, the question "Is it a floor wax or a dessert topping?" likely rings a bell. Unfortunately, because the internet aims to curb the exchange cultural media—I use the term "cultural media" loosely in this case—you likely can't watch the video via that Wikipedia link where you live, but there are alternatives, thanks to the wonders of Google search. How could modern society, and effective software developers, function without Google?  It makes a guy dizzy just to think about it!

I bring this floor wax verses dessert topping question up because EclipseCon is just around the corner.  Like a floor wax, it's a valuable utility, in this case for learning cool new things and for interacting with experts and other like-minded people. Yet like a dessert topping, it's fun, because of the social events, and fattening, because the food is so good. I'm certainly excited to attend yet another EclipseCon. Barring death or disease, I wouldn't miss it! I've been to every EclipseCon and Eclipse Summit, except one.

Eike and I will be presenting Oomph, which is like a floor wax—reducing hours of tedious work to several minutes of automation— and like a dessert topping—recording your preferences and propagating them to all your workspaces.  Perhaps the latter feature isn't even technically a dessert topping, not if you consider the top reasons why some people hate Eclipse. In particular, consider how many of those reasons relate to issues that are addressed by appropriate preferences. Of course that leads to an endless debate about what's the best default preference, i.e., surely no one wants to use Cp1252 as their default workspace encoding. We intend to address this issue with Oomph, so come to our talk and find out about the grand things that are in store.

The biggest problem with Oomph right now is documentation.  Which self-respecting developer wants to spend time on that?  Not only is it a motivation issue, authoring help-center documentation is beyond horrible. So, being tool smiths and OCD, we've worked on making that much easier.  The basic idea is that the documentation is authored as Javadoc, with numerous doclet extensions. It is processed to generate the help center HTML. The overall processing includes a preprocessor phase to produce model diagrams, screen captures, Java snippets, XML snippets, and even tree views complete with their associated properties view.  All this makes the author's life simpler and the end result is way beyond cool. In particular, have a look at the Setup Resources section; this link is likely to change in the coming days when we refactor the documentation using JDT.

Not only have I been busy with these Oomph-related things, Xcore has some dramatic performance improvements in the latest Luna service release thanks in large part to my itemis colleague, Stefan Oehme, a member of the world-renowned Xtext team. And of course there was the usual service and support work associated with EMF itself, but everyone takes that for granted. I also want to thank Jonas for revamping the embarrassingly outdated Modeling home page along with EMF's home page. It's hard to keep up with all these driving factors, but it's definitely better than being bored!

I hope to see you in Ludwigsburg at the end of the month.  Feel free to test my much-improved German skills!  Though be prepared to hear me complain about the complexities of German grammar. Sollte das ein das, ein die, oder ein der sein? Translated literally to the pointless question, should that a the, a the, or a the be?  Note the three gender articles and dangling verb. Don't expect to get the point of a German sentence until you get to the very end.

Shoes for the Shoemaker

We shoemakers are typically so busy making shoes for others that we and our children are often out and about in shoddy shoes if not barefoot. There is also a strong tendency in the wider Eclipse community to find fault without taking action, looking instead to others to magically fix problems while feeling entitled to "motivate" those actions with poisonous complaints. We should consider carefully what's wrong with this picture.

Consider for example the all-important Eclipse Platform project and the perennial concern about the limited contributions it receives.  Of course this same concern extends to all projects—we'd all love high-quality contributions associated with each and every Bugzilla report—but let's just take the platform as a case in point.  Suppose you would like to provision an IDE for working with the platform SDK source so you can commit your bug fixes to Gerrit.  All you need to do to get started is follow a few simple steps.

That's right, in the modern age of integrated development environments, you're expected to act as an interpreter for converting human language scripts into machine operations.  Does that not strike you as completely anachronistic?  Of course you're likely already doing this each time you provision an IDE to work on your own project, and you likely don't keep up with the release train milestones because it's a royal pain to do all this work each time there's a new version.

This whole problem irritates me to the extreme, not so much the platform's specific problem, but the fact that I have the same problem for EMF and for every project I use and to which I wish to contribute.  Just so you don't think I'm throwing bricks at the platform, have a look into my glass house, in particular at the extremely lovely analog of the platform's wiki page for setting up EMF's source. Good luck getting that to work!  What that heck is CVS? 

Not only is it anachronistic to follow scripts manually, it's always the case that these scripts become dated and are in need of constant maintenance, which, as busy developers, we don't have time to do.   Compound that with the fact that the scripts are buggy, you should not be surprised that when you treat the community like monkeys, you end up mostly with a lot of hooting.

Oh well, so much for the whining, sniveling, and complaining part, this problem calls for action.  Eike and I, being inherently lazy, don't even want to follow these kinds of scripts ourselves so we've worked on an  alternative approach. Yes, there's still a script for bootstrap purposes—you can help improve it—but here's the synopsis:

• just as you would any Eclipse package, download the appropriate version of the Eclipse Oomph installer—we need to do some brand marketing instead of just calling it the "Setup tool",
• unzip it,
• run it, 
• select the project you wish to set up, 
• go for coffee, 
• and come back to enjoy your fully provisioned IDE along with that fresh cup of Java.

Here's how you'd provision an IDE for working with the platform's SDK:

Here's the end result:

Of course a workspace with the entire Eclipse SDK as source is a bit aggressive, but it's a great proof of concept that it can be done for the entire platform. Be patient though, Rome wasn't built in a day: the platform's code base is very large, so cloning it all takes time, for me more than an hour!  Try a simpler project, like the EMF Core SDK, if you want more immediate gratification, and keep in mind that this would not be any faster if you did it manually.  Note that Oomph was built with EMF.  Did I mention that we're inherently lazy?

It's quite easy to author an executable setup script for your own project.  Here's how the platform's setup script looks:

The platform's script is quite complex because the platform itself is complex. Not only that, there are gotchas to get the platform to build without errors, e.g., an inherent need to install several JREs, which I avoided by changing project-specific preferences to not treat an imperfect JRE match as an error. You can see there are tasks to set global preferences, a task to install additional tools, e.g., the EE profiles feature, tasks to clone the dozens of repos, a task to materialize the target platform, a task to populate reasonable dynamic working sets, and so on.  Unfortunately it's apparently very hard to build all the platform's Ant jars and there appears to be a platform bug that requires an IDE "Restart" followed by a "Build All" before everything builds without errors and with less than 17,000 warnings. Note that the provisioned target platform contains only bundles from Orbit and from Jetty; I have no idea how the Jetty folks provision an IDE to work with source.

Eike and I intend to maintain an index of all Eclipse project setup scripts so that our community of contributors can enjoy one-stop shopping.  In addition, there are already folks looking to maintain indices for other open source forges.

The script-authoring documentation is a work in progress, but of course you can look at all the working examples as a basis for creating your own; remember to turn on "Live Validation" in the editor to catch problems early.  Note that if you provision the CDO Release Engineering environment using Oomph, you'll have all of Oomph's source code and some example scripts at your fingertips.  Contributions to the project are welcome; your changes can be easily committed to Gerrit. If you have questions, please use the EMF newsgroup and prefix the subject line with "[Oomph]". If you find problems, please report a Bugzilla. And finally, if you're so inclined, come see our EclipseCon presentation!

As you might expect, we're not the only ones who recognize the need to solve this vexing problem nor the only ones with a solution for it.  If you need this same type of thing in an enterprise context, you'll want to have a look at the cool features of p3, e.g., carefully managed inside-the-firewall p2 repositories.

As a footnote, it's committer representative election time again.  How will you decide how best to cast your vote given the 4 available choices this year?  Of course you'll want people who actively represent your committer interests at Eclipse, so you might glance at commit stats to see who's actively committing to notice these lines-of-code-committed stats over the past 1, 3, 6, and 9 months:

As a caveat, keep in mind that modeling is a great productivity amplifier!  Not only that, code commits are not the only significant committer activity and are mostly certainly not a good measure of who will best represent your interests.  On that note, I can only promise that, if elected, I'll continue to do my best to make sure Eclipse is a great place to be.  You can definitely count on me to take action where action is needed.

Modeling: Eclipse Daze at JAX 2013

Eike and I (well, mostly Eike because I'm faul) have organized this year's Eclipse Modeling Day at the JAX conference in Mainz. We hope to see you in Gutenbergsaal 2 on Friday, March 26th, at 9:00AM sharp. Eike will perform feats of magic to entertain you.

We think you'll really enjoy the mix of technology talks from Eclipse project leads and experienced industrial users.

Decorating with EMF

I recently added something totally cool to EMF.  It's so cool, you might want to use it even if you don't use EMF for anything else.  You're probably aware that JFace provides tool tip support for column viewers and of course, as a user of JDT, you've likely made extensive use of the Java editor's Javadoc hovers which display HTML-based information that even allows hyperlink navigation.  It's effectively a mini browser.  With the new feature I added, you can easily display HMTL-based hover information in any column viewer. You can see that in action with the sample I created; you'll need the latest build.  It's an RCP application that looks like this:

It displays a simple hand-written file system "model" where the files have links to other files. The hovers allow you to navigate those links within the tree. Note that EMF ships with many fine-grained features, so you need only depend on EMF's Common UI feature to exploit this, i.e., just two very small plug-ins, not the whole EMF runtime.

I used this basic feature to implement improved validation support. You can try this out by enabling Sample Ecore Editor → Live Validation.  With that enabled, whenever you change the model, the tree view will be decorated with validation results.  For example, when you create a new EClass, it won't have a name, and that's invalid.  The hover displays that as follows:

Note that the validation decorations propagate up the tree. The hovers at these higher levels display a composed result which contains links to allow you to navigate directly to any child object with a problem.

Also, the properties view itself is decorated, so a feature with a problematic value will be called out and selecting it provides details in the status line.

Pretty cool hey? And now for the best part: this has all been generated.  So if you'd like to see this type of thing in your own model, just set the GenModel's Editor Decoration property to Live, regenerate the editor, and enjoy the results. Have a look at the underlying infrastructure and let your imagination run wild with creative ideas of your own.

I'd like to thank itemis, the generous sponsor of cool things, for funding this year's "Christmas tree decoration" effort. The benefits will definitely outlast your decorated Christmas tree.

EMF Can Do What?

I've been very busy these past months implementing all kinds of cool new things. Of course I always intend to do some marketing for them, but once each problem is solved, it loses its glitter and I quickly focus on the next cool thing.  I know I really should take time to make the community aware of new capabilities, because it makes those things more valuable in reality, but I still prefer to focus on development.  Oh well, we all know where the road paved with good intentions typically ends.

As an example, I'll bet very few people are using using a ResourceSetImpl.ResourceLocator, something I added in EMF 2.8, because they don't know they can. You can see how it's used in the unit test, i.e., just create it and you're done.  What does it do? It allows ResourceSet.getResource to find the resource without searching the whole resource set.  If you look closely at how it's normally implemented, you can see it uses quite an expensive linear search that is made even more costly by the need to normalize each resource's URI to do proper comparison.  By adding a locator, the cost reduces to a fast mapped look-up where the performance is independent from the size of the resource set. Most importantly, the map is properly maintained, so no matter what you change, including changes to the URIConverter's URI mappings, you'll always find the right resource in constant time.  So if your application has a large number of resources, your should consider using it.

The most recent example of a cool new feature is support for reified types. You'll only notice this change if you use generics extensively and you regenerate your model, assuming I've not broken anything in the process, because then you might notice sooner!  Consider the following model:

Notice that in menu we know the children and selected element should be menu elements. With the latest build, the generator realizes that too, so it generates the following overrides in the menu's implementation class.

In other words, the generator will ensure fail-fast, type-safe behavior.  Not only that, the edit support is also enhanced.  That is, you can create any type of thing in a container.

But you can create only a menu element in a menu.

Similarly, you can select any type of element in a container.

But you can select only a menu element in a menu.

How cool is that?  You might ask yourself, who would model in this way?  Look closely, you'll find it right under your nose.  I have the good intention to blog about other cool things you probably didn't realize were available.

Germany: The Demo Camp Capital of the World

It's the fall demo camp season.  If you look at all the scheduled demo camps, you'll see that more than a third are in Germany!

1. Hamburg
2. Bonn
3. Dresden
4. Braunschweig
5. Berlin
6. Kassel
7. Munich

If you plan to attend, I'm sure you'll hear something to perk-up your ears and learn something to squirrel away for later.

I hope to see you in the coming weeks.

A Penny Saved Can Be a Penny Wasted

There's an English saying, "A penny saved is a penny earned". The bean counters of the world who run companies large and small follow this religiously.  Carefully managed accounting books tally every bean; the more beans left over on the bottom line, the better the result. That bottom line is the difference between the earnings and the costs and because accountants have little control over  earnings, costs are the variable they carefully scrutinize and minimize. Of course earnings don't come without costs, so it's not merely a matter of minimizing costs but rather a matter of optimizing costs.  Therein lies the fundamental flaw with the old saying. It may well be the case that a penny saved is a penny twice lost.

Consider the money spent on marketing. It's clear that such money must be spent: without such  investment, earnings will drop due to reduced market demand.  So how much should be spent on marketing?  That's a tough question; intelligent people are likely to differ in their opinion though it's clear that making as much market impact as possible for as little money as possible is optimal. It's always the case that making a good impression requires investment.

In the topsy-turvy world of open source software, where money is spent on software that's given way for free, the bean counting formulas go into a tailspin. At best the open source effort can be saved by resorting to a marketing slant, that is, if we give this software away for free, we will grow the market and will increase demand, or save costs, for whatever we're producing for this market.  This is what justifies spending billions on Linux (spare the expensive Window's license associated with each computer sold) and hundreds of millions on Eclipse (ensure that the Java platform is competitive with the .NET platform).

I used to work for one of the largest organizations of the world, so I have a good understanding of the corporate mindset. One of my final lessons learned there is that managers really don't like it when you send notes to their managers: sending a well-intended, constructive note about how best to optimize open-source investment, i.e., essentially the content of the blog I wrote at the start of 2008, proved the old adage "No good deed goes unpunished". So now I work closely with itemis, essentially doing the same thing as I did before, i.e., ensuring that Eclipse modeling technologies thrive in a growing market. To digress for a moment, for me personally, the most exciting software technology this world has to offer in this space is Xtext, driven by the experts at itemis. I fundamentally believe that the integration of concise notations with well-established software platforms, is the optimal way to improve on a good thing.  Xtend is a great example of what I mean, i.e., it's simply a better Java that integrates seamlessly with Java, i.e., it's evolution rather than revolution, improving on what exists rather than replacing it. My own work on Xcore emulates that same approach.  Please come to the Eclipse Demo Camp in Bonn for a closer look.

In any case, back to the issue at hand: optimizing a company's bottom line beans. The problem in this regard at itemis is no different than anywhere else.  Fortunately itemis has an enlightened view, recognizing that the cost of open source investment pays off in the end.  One way that's the case is the money spent on services and that's why assembling the world's leading modeling experts into a cohesive organization has been one of their goals. A battle ground faced by all service companies is that other organizations often see a penny spent on services as a penny best saved; the cost of those savings are all too easily overlooked.

Consider an example back in my earlier days.  EMF is used by a lucrative web server platform as part of  their start-up configuration model.  EMF was one of their 's favorite scapegoats:  EMF slowed down start-up performance with its bloated byte code.  Of course when you have a bloated model, there's only so much you can do, but that argument goes nowhere fast.  Therefore, when I caught wind of this complaint, I pointed out that they could generate much less byte code by changing package creation to load each package from its serialized form and by using dynamic feature delegation for the implementation classes.  Sure, both of these generate slower code, but the important point is they generate less byte code, all of which needs to be loaded at startup, and then bloats the process when it's no longer needed after start-up. They changed these two options in the generator model, regenerated the code, and presto, sever start-up improved by more than 40% with less than a day of effort. Previous efforts to improve start-up involved man-decades of investment, yes decades.  In this case, my help didn't cost them a penny. Unfortunately neither the savings nor the improved sales were ever calculated, but I did get a huge thank you for my invaluable help.  Okay, that last part is just wishful thinking, I never got so much as a kind word. Oh well, it's good to help prevent fires.

In any case, my message to the enlightened developers of the world is to manage their bean counters more effectively.  Don't let them rule your organization. When you need expert help, demand that you get it.  Spend that extra penny and earn that extra dollar.  A team of unproductive developers producing inferior quality results is a cost that must be brought into focus. Demand that this be measured and that it be factored into the bean formulas.  The team of experienced exerts at itemis, including me, are always available for personalized help.  We do workshops too, like the one I'm doing after the Bonn Demp Camp. The Eclipse community as a whole is rife with expertise so for goodness sake, spend a penny, with the realization that in addition to your internal savings, much of that penny will go back into the development of the next generation of the free software that you know and love. It's an investment in the future, an investment in the commons, and an investment in a better way to build the word's software foundations.

Time Flies Like an Arrow

It's been a long time since last I blogged.  Much has happened these past months.  EclipseCon was, as always, a huge highlight, providing an opportunity to spend fun times with good friends. 

I was especially honored to receive the Eclipse Lifetime Contribution Award for 2012.

Thanks Anne for the memorable photos! Of course I'm eagerly looking forward to EclipseCon Europe!

Most of these past months I've been slaving away getting Xcore ready for prime time.  Thank goodness Juno is out the door.  A particularly challenging feature I felt was badly needed for the first release was support for rename refactoring.  Thanks to Jan's help in the base Xtext framework, it's working very well.  In fact, it's totally cool. You can rename something in Xcore and it will invoke Java rename refactoring for each and every Java artifact derived from the thing being renamed.  All hand written code that uses the generated APIs will be refactored seamlessly in a single step.  

It's gratifying to see from the newsgroup and bugzilla that there are real users of Xcore now.  I'm currently working hard to fix problems in the maintenance stream. If you see a problem, please report it so I can fix it.

In my "copious" spare time, I've been nurturing a new garden.

It's not as big is my old one, but it's in Berlin, the capitol of cool things!

I need to think about submitting talk proposals for EclipseCon Europe and for Eclipse Finance Day.  It looks like I may have missed the Eclipse Day Delft deadline...

On the sad news front, Amber died a few weeks ago.  She had a congenital heart defect that finally got the better of her. I miss her. All good things come to an end.

Xcore on Training Wheels

I've quietly been making excellent progress with Xcore. After getting IP approval, the first step was to migrate the code base to be hosted at Eclipse. I decided this was also an appropriate time to migrate EMF and XSD to use Git to preserve the github history of Xcore. All the cool kids are doing it. Being cool is very important. No one wants to be left out in the cold.

Unfortunately, learning Eclipse's Git tools has been a bit of a nightmare. Its poor support for proper line feed handling continues to be frustrating. I compare learning Git to being given an advanced new hammer, one without a handle, that if you just instruct it nicely to do what you want, will do the job ten times better than ever before. Only the instructional language is Gitinese. It's very hard to pronounce, with lots of German "ch"s (think hissing snake), "st"s, and "sp"s (think "sht" and "shp" where the "h" is implied), plenty of Dutch "g"s (think clearing your throat), and no end of "th"s (think "s" but with your tongue hanging way too far out; it is a very unusual sound if English is not your native language). Anyway, enough bashing Gitinese and the Germanic languages. Once you learn them, they all sound as if they were simply meant to be that way. Oh well, back to Xcore.
Of course we needed a logo, so I whipped one up. Maybe someone will contribute a nicer one. On a more substantial front, with the help of Dennis Hübner, we have our first builds of Xcore available. It's been contributed to the Juno repository. (Note that he's working on making EMF and XSD 2.8 build with Eclipse 3.5 so that we'll have more permissive version ranges that are properly tested.) I also finally found time to write a wiki tutorial for how to get started with Xcore. Lots of cool things are working rather nicely. We even have support for organizing imports. So have a look if you have the time.

Modeling Daze to Come

My transition to Germany is nearing completion. I now have a three year visa to stay in Germany and I'm registered as living in Berlin. Amazingly the visa was acquired with roughly eight hours of time investment, including the four hour wait for the appointment, along with zero euros of financial investment. The best things in life are free.


The German process stands in sharp contrast to the Canadian process we followed for Frank. That cost many thousands of dollars and took the better part of a year. All I need now is a German tax number and a German bank account and I'll be ready for business in 2012. Speaking of business, there's a lot going on! Jonas recently blogged about the Eclipse Modeling Symposium scheduled for EclipseCon. If you'd like an opportunity to showcase Really Cool Things,™ please send in your proposal so that Jonas and I can find an appropriate slot for your facet.


The OMG is holding an Eclipse Symposium as well. It will be held the day before EclipseCon starts, i.e., Sunday, March 25th, 2012. It will focus on Eclipse technologies that implement and support OMG specifications. Ed Willink is helping organize it. If you're interested, I suggest you contact him at ed at willink dot me dot uk . You can also register just to attend. I'm looking forward to seeing the juxtaposition of the old and the new.


As you may have noticed, you simply can't have too many Modeling Days, so of course there will be another modeling day at JAX this year. Sven, Eike, and I are organizing it. If you'd like to get involved, please send your proposal to ed dot merks at gmail dot com. I expect I'll be able to understand more of the German content this year than I did last year. Maybe I'll even have plodded along far enough to speak some broken German by then.


To further round off an already well rounded event schedule, there's an Eclipse Day in Florence on May 4th. Can you think of a lovelier place to hold a Eclipse event? We're really looking forward to having a peek at part of the community we've seen less frequently.


At this point you might be wondering about deadlines for submissions. All I can say is don't ask about deadlines! Do it now. There's no time like the present. Time waits for no one, and most especially not for you. If you have time, and you expect to be in Berlin, Eike and I will be at the Eclipse User Group Stammtisch on January 31st.

Making the Move to Germany

I haven't blogged for a quite a while, not for lack of content, but rather for lack of time. So much as happened in the past months! In August we had visitors from Germany. We took them to see Pacific Rim National Park, one of the most beautiful places on earth.


During this time we also started making plans for an extended stay in Germany, which, as you know, is the home of Really Cool Things.™ My ThinkPad was very old and totally tired, so I finally cracked open my wallet and bought a new Dell Precision M4600; I must have a keyboard with an ultranav. My new baby is fully loaded to the hilt with every desirable feature, including 16GB of 16MHz memory, two SSD drives, an i7-2920XM Quad Core, and more. It sure was a lot of work to get it set up, but I love it.

We've been in Germany since October 7th. Berlin is our home base. And of course we brought the girlies along! Since our arrival, I've been busier than ever with visits to itemis headquarters in Lünen, the Xtext guys in Kiel, EclipseCon Europe in Ludswigburg, as well as demo camps in Bonn and Dresden. We've even had a chance to go sightseeing in Rügen.


Just this past weekend I went to a friend's concert at Berliner Dom! I captured the experience with my brand new Nikon Coolpix S9100 with 18x wide optical zoom.


This week there's a stammtisch in Berlin on Thursday and next week Eike and I present at an itemis event in Bonn on Tuesday. Maybe we'll see you at one of those events! Later next week, Eike and I host an itemis training session in Oldenburg; yet another place I've never been. I'm pretty sure I've seen more of Germany in the past weeks than most Germans have seen in the past years.


It's quite clear now that Germany is the cool place to be for us to be, so we're making long term plans to stay here. It's kind of scary, but oh so exciting too. My German comprehension improves a little bit every day though my speaking abilities lag far behind, for lack of trying I'm told. In any case, I now have a very nice home office that includes a Dell UltraSharp U3011 monitor; I kiss it every morning because I love it so much.

Life is definitely very cool and exciting. I'll have to blog more often now that things are finally settling down. Xcore too is progressing well; stay tuned...