Generics, Eclipse, JFace, and Google Summer of Code

Greeting readers,

My name is Jeanderson Candido, I am undergrad in Computer Science at Federal University of Campina Grande, Brazil, and I will be writing about the cool things we are doing to the Eclipse project in the 10th edition of Google Summer of Code.

My mentors are Lars Vogel and Hendrik Still. The title of our proposal is “Generics support for JFace viewers and migration of Eclipse UI viewers” and we are planning to evolve JFace viewers to meet features targeting Java 1.6. In fact, Hendrik was participating last year as a student on Google Summer of Code and there was a first attempt to migrate JFace viewers but he could not conclude the project due to time constraints. In this year, we are committed to finish what was started.

For those who are not familiar with it, JFace is a widely used API for Eclipse plug-ins that interacts with the Eclipse user interface. JFace works together with SWT to provide predefined user interface components; therefore, developers do not need to rewrite commonly used patterns.

Besides its importance, JFace still does not support features after Java 1.4. In particular, the absence of Generics forces developers to rewrite code for type checking. This workaround not only results in verbosely duplicated code and wasted time but also may hide potential faults that could lead in runtime errors.

Many of these issues could be solved in an elegant-fashioned way with Generics. Generics is a mechanism that gives support to create general purpose code with type safety. It is clear that finding and fixing runtime errors is challenger than fixing compile-time errors. It would be better if we could spot in compiling-time some runtime errors, like improper casting. This is possible with Generics because it allows the compiler to perform a stronger type checking. Consequently, the use of casts would be unnecessary. Just like the Java Collections API, a generic version of JFace viewers would result in an elegant and clean code:

Without Generics:
combo.setLabelProvider(new LabelProvider() {
@Override
public String getText(Object element) {
if(element instanceof Person){
return ((Person) element).getLastName();
} else {
return "";
}
}
});

With Generics:
combo.setLabelProvider(new LabelProvider<Person>() {
@Override
public String getText(Person element) {
return element.getLastName();
}
});

We are already targeting JFace with Java 1.6. In the last couple of weeks, we have been removing Warnings, simplifying code, and performing a major cleanup in JFace tests, viewers, and snippets.

If you want to know more details about generics, visit the “Generics” tutorial by Oracle (http://docs.oracle.com/javase/tutorial/java/generics/). Finally, visit my personal website (http://jeandersonbc.github.io) and our Github planning repository (https://github.com/jeandersonbc/gsoc14-eclipse-planning) for more information about me and about our progress.

See you soon!

About Jeanderson Candido

I'm currently undergrad in Computer Science at Federal University of Campina Grande (UFCG), Brazil. Since My first year, I've been involved in researches related to Software Engineering. I was visiting student at Walsh University, USA for a year (2012-2013) and research assistant at PLASMA (University of Massachusetts, USA) during the 2013 Summer. Nowadays I'm a contributor of the Eclipse project and research assistant at Software Productivity Group (SPG at UFCG).
This entry was posted in Jeanderson Candido, Other and tagged , . Bookmark the permalink.

6 Responses to Generics, Eclipse, JFace, and Google Summer of Code

  1. Adolfo says:

    That sounds good stuff. Good luck with it.

    I’ve not got which are the Jave 1.6 features you are meeting. Generics arrived a little bit earlier.

    Keep it going.

    Cheers,
    Adolfo.

  2. Hi Adolfo,
    Major features were included in the 1.5 release but we are targeting Java 1.6
    Indeed, the way I wrote wasn’t much clear.

    Thanks for stopping by.

  3. Mikaël Barbero says:

    I really don’t see any advantage to add generics to JFace’s label & content provider or to viewers. By nature, they are aiming to display objects of heterogeneous kind that very rarely share a common supertype other than java.lang.Object. Even when they share a common superclass, it may not be useful because the label and the content of an Object are typically computed from fields/methods of the lowest type and not (only) from the supertype.

    There are some solutions around there to help to overcome the fastidious “if instanceof elseif …” E.g. Eclipse EMF provides the very nice EMF.edit framework with its ItemProvider that properly use Java’s type system. It avoids you to write any fastidious code (see http://eclipsesource.com/blogs/2013/01/29/emf-itemprovider-magic/). Another solution has been adopted by Xtext. It provides a polymorphic dispatcher by using reflection. It’s a twist at the Java’s type system, but still, it is very useful and powerful (see http://blog.efftinge.de/2010/03/multiple-dispatch-and-poor-mens-patter.html)

    IMHO, it really is a waste of time to add generics to JFace to suit maybe less than 0.1% of the use cases of those classes. A port and an integration of one of the two solution above would have much more sense.

  4. Lars Vogel says:

    Mikaël, I find it also makes sense to improve JFace Viewers, EMF and Xtext have nice enhancements but lots of people are still using JFace viewers directly.

  5. Mikaël Barbero says:

    As a matter of fact, I think it has been clearly demonstrated last year that, from a technical point of view, it does not make any sense (if keeping compatibility is one of you priority, and I hope it does for such an low level API as JFace)

    For the record, here are links to technical arguments against such a work:
    https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09647.html
    https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09662.html
    https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09668.html

    I was not suggesting to use Xtext or EMF, I was suggesting to port to JFace some of the features they implemented to overcome the JFace APIs. These features are nice and well thought. Moreover, they are not breaking anything for the adopters.

  6. Lars Vogel says:

    Mikaël, the platform team decided that we think their is some value in this development and we will keep compatibility. We try to make the implementation as good as possible. I think it is a great idea from you to port some of the XText and EMF features to JFace, you are very welcome to provide patches for this wor. But that is not the scope of the GSoC project, I think porting JFace viewers to generics is ambiguous enough.

Comments are closed.