The Future of Fest

I have put together a plan for the project and myself, which I’m going to share with the rest of the team. The plan is the following:

1. Release FEST-Assert 2.0

That would be my #1 priority. Joel and Ansgar have been making great progress on FEST-Assert 2.0. I’m joining them now (and Yvonne soon after me.)

2. Create a Java-7-specific version of FEST-Reflect

IMHO, FEST-Reflect was a nice improvement over reflection. Now when I look back, I find its API too verbose. For example, consider this method call in plain Java:

String name = names.get(8);

Now, the same method call using FEST-Reflect:

String name = method("get").withReturnType(String.class)
                           .withParameterTypes(int.class)
                           .in(names)
                           .invoke(8);

Instead of specifying parameter types, FEST-Reflect should deduce them from the values passed (we still need withReturnType to skip casting though.)

String name = method("get").withReturnType(String.class)
                           .in(names)
                           .invoke(8);

The Java-7-specific part of the project would be to implement it using method handles instead of reflection. I haven’t done any Java 7 development yet (yes, I feel embarrassed) but my understanding is that method handles are supposed to be faster.

3. Move the project out of CodeHaus

I’m very grateful for the support we got from CodeHaus. Unfortunately CodeHaus’ performance is an exercise for one’s patience. Its Confluence and JIRA instances are just too slow (BTW, we moved the code to Github long time ago.)

We will keep our project at Google Code. There are too many good memories attached to it.

4. Replace our ugly blog with Github pages

They are just beautiful and hopefully easier to manage.

5. Retire inactive committers

I’m going to revoke access to committers who have been inactive for a year or more. Joel, Ansgar, Yvonne and I will remain as active committers.

6. Retire UI-testing-related projects

It was a lot of fun to work on FEST-Swing, but unfortunately I don’t have the motivation and time to work on it anymore. Swing was a great UI toolkit and one of my favorites. Unfortunately, debugging platform-specific issues or finding workarounds for bugs that will never, ever be fixed is no longer interesting to me.

Like I said many times, there is not point in creating a version of FEST for SWT. SWTBot is a great project that works pretty well. In fact, I’m a big fan of it!

Before joining Google, I had some vague intentions to work on a JavaFX version of FEST. That is no longer the case. IMHO, except for corporate applications and IDEs, desktop Java is pretty much irrelevant. It would have been useful for the few JavaFX users out there to have a UI testing tool that works (unfortunately it is not you, JemmyFX.) Even thought JavaFX may be better than Swing technically, it does not excite me.

Conclusion

I’m happy to be part of the FEST project again. Now that I have very little spare time (I’m a family man now and I have a job that I’m love with,) I’m trying to be an active FEST committer while focusing my energy on things that matter the most. Reducing both the scope of the project and the size of the team seem to be the best choice for now.

The opinions expressed in this post, as harsh as they may sound, are my own.

Feedback is always welcome :)