Welcome Richard

I’m very happy to introduce the Eclipse Foundation’s newest staff member, Richard Burcher.

Richard will be helping me with “project stuff”. If you take a quick look at Richard’s blog or Twitter feed, you’ll notice that he’s got a an affinity for location/geo-sorts of things in particular and open source software in general (along with an apparent disdain for capital letters). As part of that, Richard has a bunch of experience working with and growing communities. I intend to fully exploit that experience.

We’ve already begun Richard’s immersion into all things Eclipse. It’s been a fascinating and valuable experience for me to explain how things work around here. Assembling materials for the Eclipse Committer Bootcamp, helped me illuminate potential areas for improvement in our process. Working with Richard over the last few days has had an even bigger effect. I’m excited that we’ve already identified a potential ways that we can improve and streamline our implementation of the Eclipse Development Process, while honoring its fundamental underlying principles.

I’m excited by the potential for us to do more to help our open source projects evangelize and court their communities.

More on this later. But for now, please join me in warmly welcoming Richard aboard.

Posted in Announcements | Leave a comment

Add Java 8 support to Eclipse Kepler

Want to add Java 8 support to Kepler?

Java 8 has not yet landed in our standard download packages. But you can add it to your existing Eclipse Kepler package. I’ve got three different Eclipse installations running Java 8:

  • A brand new Kepler SR2 installation of the Eclipse IDE for Java Developers;
  • A slightly used Kepler SR1 installation of the Eclipse for RCP/RAP Developers (with lots of other features already added); and
  • A nightly build (dated March 24/2014) of Eclipse 4.4 SDK.

The JDT team recommends that you start from Kepler SR2, the second and final service release for Kepler (but using the exact same steps, I’ve installed it into Kepler SR1 and SR2 packages). There are some detailed instructions for adding Java 8 support by installing a feature patch in the Eclipsepedia wiki.

The short version is this:

  • From Kepler SR2, use the “Help > Install New Software…” menu option to open the “Available Software” dialog;
  • Enter http://download.eclipse.org/eclipse/updates/4.3-P-builds/ into the “Work with” field (highlighted below);
  • Put a checkbox next to “Eclipse Java 8 Support (for Kepler SR2)” (highlighted below);
  • Click “Next”, click “Next”, read and accept the license, and click “Finish”
  • Watch the pretty progress bar move relatively quickly across the bottom of the window; and
  • Restart Eclipse when prompted.
Select "Help > Install New Software..." to open the Available Software dialog.

Select “Help > Install New Software…” to open the Available Software dialog.

Voila! Support for Java 8 is installed.

If you’ve already got the Java 8 JDK installed and the corresponding JRE is the default on your system, you’re done.

If you’re not quite ready to make the leap to a Java 8 JRE, there’s still hope (my system is still configured with Java 7 as the default).

  • Install the Java 8 JDK;
  • Open the Eclipse preferences, and navigate to “Java > Installed JREs”;
  • Java Runtime Environment Preferences

    Java Runtime Environment Preferences

  • Click “Add…”;
  • Select “Standard VM”, click “Next”;
  • Enter the path to the Java 8 JRE (note that this varies depending on platform, and how you obtain and install the bits);
  • Java 8 JRE Definition

    Java 8 JRE Definition

  • Click “Finish”.

Before closing the preferences window, you can set your workspace preference to use the newly-installed Java 8 JRE. Or, if you’re just planning to experiment with Java 8 for a while, you can configure this on a project-by-project basis.

Specify that your project will use a JavaSE-1.8 JRE.

In the Create a Java Project dialog, specify that your project will use a JavaSE-1.8 JRE.

It’s probably better to do this on the project as this will become a project setting that will follow the project into your version control system.

Next step… learn how wrong my initial impressions of Java 8 were (hint: it’s far better).

The lamda support is so choice. If you have the means, I highly recommend picking one up.

The lambda is so choice. If you have the means, I highly recommend picking one up.

Posted in Eclipse 101, Eclipse 4, Java | 8 Comments

Official Eclipse Support for Java™ 8

Dani Megert, the project lead for the Java development tools (JDT) project made this announcement earlier today:

The Eclipse top-level project is very proud to announce official support for Java™ 8. Starting with I20140318-0830 all Luna (4.4) builds contain the Eclipse support for Java™ 8. For Kepler SR2 (4.3.2) a feature patch is available. For future builds visit our downloads page.

The Java™ 8 support contains the following:

  • Eclipse compiler implements all the new Java™ 8 language enhancements.
  • Significant features, like Search and Refactoring, have been updated – to support Java™ 8.
  • Quick Assist and Clean Up to migrate anonymous class creations to lambda expressions and back.
  • New formatter options for lambdas.

Note that PDE API Tools has not yet adopted the new language constructs. This will be completed in the final Luna release.

Big thanks to everyone who worked on this effort!

The Contributors

Congratulations to the team!

Posted in Announcements, Community, Java | 9 Comments

This Week in Open Source Projects at Eclipse

It’ll be another busy week next week: I have six reviews scheduled. More on that in a bit…

The decentralized nature of Git makes it so that it’s no longer possible to expect that somebody who has found your source code repository will easily find the corresponding project and sort out how to contribute without assistance. In short, if you value contributions, then you really need to have a contribution guide baked right into your repository. The use of a CONTRIBUTING file, located in the root of every Git repository is becoming the standard way of helping potential contributors be successful. As Denis stated, “every project I’ve interacted with in the Linux world has a README, INSTALL and/or CONTRIBUTING file… or contributing instructions somewhere in any of those.”

I decided to put some serious energy into Bug 389644, which is concerned with providing some help to get projects to create a contribution guide. I took it one step further, and implemented an automatic contribution guide generator. The generator creates what I believe is a reasonable default minimal CONTRIBUTING file. That reasonable default can and should be extended to include, for example, more detailed how-to-contribute documentation, or a link to a more comprehensive document.

Information about the generator is in the Eclipsepedia wiki. I don’t currently have it linked to anything yet, but I think it will find a natural home in the PMI. For now, you can use this URL:

http://www.eclipse.org/projects/tools/default_contributing_file.php?id=project-id

Where project-id is the Eclipse project id (e.g. ‘technology.jgit’). The results produced by the generator are only as good as the information provided by the project team in the PMI.

Here’s the important bit: All Eclipse projects are henceforth required to have a contribution guide in every source code repository before any release review will be scheduled. The guide does not have to be exactly as the generator provides and I’m not particularly hung up on the naming convention: I just need to be able to quickly find and understand it.

And now to the reviews…

This week, we have two project creation reviews:

RCP Testing Tool

The scope of RCP Testing Tool is to provide a best-possible support for testing of Eclipse-based applications.

Californium (Cf) CoAP Framework Creation Review

Californium (Cf) provides an implementation of the Constrained Application Protocol (CoAP) standard.

We have two release reviews:

And, finally, two termination reviews:

The Eclipse Project Incubator termination isn’t as scary as it sounds. The two incubators included in this termination aren’t being used; all incubation in the Eclipse project occurs in the e4 project. UFaceKit is being terminated because all development on the project has halted.

As always, if you have any questions or concerns, please let me know!

Posted in Announcements, Community, EDP | Leave a comment

Open Source Project Activity at the Eclipse Foundation

This is a pretty big week for reviews.

According to the Eclipse Development Process (EDP), Eclipse open source projects are required to engage in reviews at key points in their lifecycle. This starts with the creation review, but most reviews are concerned with releases. Every major or minor release is preceded by a release review. Service (or “bug fix”) releases are excused from the review requirement.

It’s a particularly busy week for creation reviews.

Eclipse UML Generators

UML Generators Project provides components that automatically bridge the gap between UML models and source code. Either by extracting data from UML models (and UML profiles or decoration models) to produce source code or by reverse-engineering source code to produce UML models.

Ogee

The main goal of Ogee project is to provide tools for developers who want to consume and produce data using the OData protocol.

CHESS (PolarSys)

The CHESS project provides a model-driven, component-based methodology and tool support for the development of high-integrity systems for different domains. The methodology is particularly suited for space systems and industrial domains.

Handly

The project distills the core abstractions of a handle-based model into a uniform API and supply basic building blocks for construction of such models. It borrows heavily from some of the design patterns and principles used in the Java Model, but aims for a generalized albeit partial implementation.

Gendoc

Gendoc generates documentation for EMF models using document templates in formats such as OpenOffice Writer (.odt) or Microsoft Word (.docx).

GeoScript (LocationTech)

The GeoScript project provides a convenient API for the Java based GeoTools library to other JVM languages. GeoScript aims to provide a relatively consistent API between different languages, preferring existing language conventions and semantics over absolute consistency. GeoScript modules can be used in existing applications or accessed via interactive shells. GeoScript does not intend to provide a complete application itself.

It’s also a busy week for release reviews:

Orion 5.0.0 Release Review

The main deliverables for the Orion 5.0 release are a multi-user server based on a Java runtime and a single-user server based on a Node.js runtime.

EMF Client Platform 1.2.0 Release Review

The release adds the new sub component EMF Forms and provided e4 and RAP compatiblity.

Equinox Restructuring (Security and Website Subproject Termination) Review

The Equinox Security and Website projects are no longer necessary. Their assets have already been transfered to other projects and so they are effectively empty. They will be terminated.

Aether 0.9.0 Release Review

First incubation release. The Aether project generally provides two sets of deliverables: Aether Core, i.e. the API, SPI, utility classes and base implementation of the library; and Aether Ant Tasks, a collection of tasks for Apache Ant to employ Aether for interaction with repositories using the Apache Maven format.

Eclipse Git Team Provider 3.3.0 Release Review

This release includes several new features, including the add ability to squash commits directly from the history view, along with usability and performance improvements.

C/C++ Development Tooling (CDT) 8.3.0 Release Review

Usability has been greatly improved around the paths and symbols area and scanner discovery settings. Work continues on supporting new C++ standards C++11 and C++14. We are working on C++11 and C++14 support available in gcc 4.8.

A handful of projects are engaging in service releases:

If you have any questions, comments, or concerns regarding these releases, communicate directly with the project via the specified forum (you can find the appropriate forum by navigating to the project’s “Contact Us” page). For proposals, you can ask questions in the proposals forum.

Posted in Announcements, Community, EDP, Project Management | Leave a comment

Project Explorer: Opportunity to Contribute

Bug 427897, titled Remove need for “Package Explorer” in favor of “Project Explorer”, presents a great opportunity to contribute to the Eclipse Platform. The primary concern of the bug is improvement in the functionality provided by the Project Explorer view so that it may one day replace the Package Explorer view in the Java perspective (or become an anchor view in an entirely new über “Software Development” perspective). An enhanced Project Explorer will improve the development experience for language development tools, and reduce the need to switch perspectives when working with multiple programming languages.

Bug 427897 is a bit of an “umbrella bug”. Some actual code changes will be required to switch the Java perspective to use the Project Explorer, but a lot of other work needs to happen before that. This work is expressed as “blocker” bugs. I expect to see the list of blockers on this bug grow.

This is where you come in:

  • There are already many bugs open to improve the Project Explorer. We need to decide which of these bugs are blockers; what subset of the bugs that are already open must be addressed before we can declare victory and swap the Project Explorer in for the Package Explorer?
  • What functionality is not already addressed by a bug? Do we need to open new blocker bugs?
  • Finally, which of these blocker bugs can you address/solve?

The Project Explorer is based on the Common Navigator Framework, so some of the bugs that need to be addressed are filed as “[CommonNavigator]“.

Have at it.

Posted in Community | Leave a comment

Playing with Java 8 Lambdas in the JDT

I’ve been playing with the language a bit while tinkering with the Java 8 support under development by the Eclipse Java development tools (JDT) project.

I’ll admit that I’m a little underwhelmed by lambdas in Java 8. This, of course, comes from an Old Dude Who Knows Smalltalk (and LISP/Scheme).

Old Curmudgeon Dude Who Knows Smalltalk

Old Curmudgeon Dude Who Knows Smalltalk

Like any good Smalltalk curmudgeon, when I set about learning how to use lambdas, I naturally decided to implement the known and loved collections.

Starting from something like this:

OrderedCollection employees = new OrderedCollection();
employees.add(new Employee("Wayne", 10));
employees.add(new Employee("Joel", 9));
employees.add(new Employee("Jon", 6));
employees.add(new Employee("Anthony", 8));
employees.add(new Employee("Mary", 2));
employees.add(new Employee("Sue", 3));
employees.add(new Employee("Joanne", 7));
employees.add(new Employee("Shridar", 1));

In classic Java, you’d do something like this to find employees with more than five years of experience:

List longTerm = new ArrayList();
for(Employee employee : employees) 
	if (employee.years > 5) longTerm.add(employee);

Using lambdas, you might do something like this:

OrderedCollection longTerm = 
	employees.select(employee -> employee.years > 5);

It’s a little tighter than classic Java, and I personally find it very readable and understandable; readers with different experiences may have a different option. I believe that it is way better than the equivalent implementation with an anonymous class:

OrderedCollection longTerm = employees.select(new SelectBlock() {
	@Override
	public boolean value(Employee employee) {
		return employee.years > 5;
	}
});

Anonymous classes make babies cry.

Of course, babies aren’t particularly happy about the implementation of select() either:

public class OrderedCollection<T> extends ArrayList<T> {
	...
	public OrderedCollection<T> select(SelectBlock<T> block) {
		OrderedCollection<T> select = new OrderedCollection<T>();
		for(T value : this) {
			if (block.value(value)) select.add(value);
		}
		return select;
	}
	...
}

Lambdas are syntactic sugar for anonymous classes, and do arguably make some code easier to read. For my rather simplistic example, the benefit over the direct use of a for-loop is marginal from a readability point-of-view, but it’s far easier to understand than the anonymous class example. From a performance point-of-view, I expect that using lambdas or anonymous classes in this context would be something like an order of magnitude worse than just using a for-loop.

One of the cooler things that we do in Smalltalk is create our own control structures. Instead of creating a whole new collection, you could create custom iterators, e.g.:

payroll.longTermEmployeesDo(employee -> payroll.giveEmployeeARaise(employee));

Or something like that. I’m not sure if this makes it better or not.

Simple collections might not be the best use of lambdas. Lambdas are not quite as useful (or, I believe, as efficient) as blocks in Smalltalk. I’ll need to spend a little more time tinkering with examples where the use of anonymous classes is more natural in Java (Runnables and listeners seem like an obvious place to start).

Unfortunately, I think that trying to implement Smalltalk-like collections using lambdas in Java 8 will also make babies cry.

As a parting shot… try to wrap your brain around this:

double average = (double)employees.inject(0, 
	(sum, employee) -> sum + employee.years) / employees.size();

Totally readable. Totally.

Modified on Feb 18/2014. My initial observations led me to believe that lambdas are syntactic sugar for anonymous classes. I’ve since learned that this is not the case. Further, there are some optimizations that I need to better understand. I’ve struck out the incorrect statements (but have otherwise left it for posterity).

Posted in Java | Tagged , , , | 3 Comments