Alex is a Software Engineer working on Android development tools, especially Android Studio, at Google. His interests include Java, API design, OOP, IDEs and testing. Alex spends some of his spare time working on Open Source, blogging, writing technical articles, and speaking at international conferences. The opinions expressed here represent his own and not those of his employer. Alex is a DZone MVB and is not an employee of DZone and has posted 49 posts at DZone. You can read more from them at their website. View Full User Profile

The Future of Fest

07.11.2012
| 2388 views |
  • submit to reddit
I'm very excited to be working on FEST again! It has been more than a year since my last commit and there is a lot of catch up for me to do.

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 :)

 

 

 

Published at DZone with permission of Alex Ruiz, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)