DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > The Future of Fest

The Future of Fest

Alex Ruiz user avatar by
Alex Ruiz
·
Jul. 12, 12 · Java Zone · Interview
Like (0)
Save
Tweet
3.21K Views

Join the DZone community and get the full member experience.

Join For Free
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 :)

 

 

 

JavaFX Java (programming language) teams GitHub Google (verb) application career Confluence (software)

Published at DZone with permission of Alex Ruiz, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Vaadin Apps as Native Executables Using Quarkus Native
  • Monolith vs Microservices Architecture: To Split or Not to Split?
  • Internal Developer Platform in Plain English
  • Java’s Encapsulation - When the Getter and Setter Became Your Enemy

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo