Fork me on GitHub

JRebirth Origins

The small story of JRebirth project.

Introduction

Just before the 2011’s summer I was bored to work with some RIA toolkit that don’t give me enought satisfaction.

Like many people I thought that web applications were the ultimate solution to build quickly beautiful and sophisticated applications. Before the advent of JQuery’s like toolkit I built mine, a modularized javascript framework written with OOP spirit. Browser compatibility stops the projects because it requires too much time to manage their particularities. But the biggest pitfall is the Javascript language that is not enough powerful to build cleanly big application and not enough efficient than pre-compiled ones.

Then I was upset by the single thread used by Flash and Flex application, even if I really have pleasure to work with FlexBuilder with PureMVC framework. Making extension of Flex components was also sometimes pretty hard due to inheritance of Flash widgets (partially resolved with new spark components).

Unfortunately I also worked several month with Silverlight (C#) provided by Microsoft, the language itself has got some interesting feature but ecosystem is not as good as the Java one. The MVVM pattern (Model-View-ViewModel) is a fake that hide a MVVCVM (Model-View-ViewController-ViewModel) where VC is the .xaml.cs file…

Before working with RIA, I obviously worked with Swing and SWT/JFace toolkit. And finally Swing was not so bad !

It suffered from a lot drawback like graphical performance issues, concurrency problems and old layout and components. But it was possible to write nice application powered with a pleasant Look & Feel.

So JRebirth was first thought to be a rebirth of Java Swing Toolkit in order to create the missing Application Framework that Swing never had.

I posted on the ToulouseJUG mailing list a question about my Swing revival vision, and during the discussion I learned that Oracle had planned to rewrite the first JavaFX entirely in Java (and leave the awful fxscript language). So I spent the summer in reading beta documentation and during the autumn I began to play with it … and I decided to build my own Framework.

The name was readily found: JRebirth (for Java Rebirth) JavaFX Application Framework

Everything began on a local SVN and then was pushed on Github on Feb 22, 2012, few days after my first talk about JavaFX (2).

The main goal of building yet another application framework is to be the more convenient as possible for developers.

The major issue when building graphical application is to create unresponsive memory-hungry application, while dealing with ugly code hard to maintain.

To address the first point JRebirth offers a way to manage threads on your behalf, for the second JRebirth defines ‘layers’ to maintain a good Separation of Concern (SoC).

Why don’t manage myself my application thread ?

Writing concurrent program is more complex than you can think, you should find a way to make it easier unless you will be probably struggle with incomprehensible problems so hard to debug. Moreover this kind of problems always occur when you are demo-ing your application to your client.

Layers sucks !

Are you sure ? Layer is the more basic way to organize and reuse smartly your code. It could seem to add some overhead to it but when you are working with a small or big team over years, you will enjoy to retrieve at the same place the same logic. It requires to respect some rules, within JRebirth Layers shall be seen as Area because there is no hierarchy between them, all Areas can communicate with others but they provide real concerns separation.

Moreover you will have the capability to customize your layer to fit your need by factorizing your code.

Main features of JRebirth Application Framework are:

  1. Simplify Thread Management
  2. Avoid memory leak
  3. Maintain a good SoC
  4. Be the more convenient as possible for developers
  5. Be lightweight and modularizable
  6. Follow OSS spirit and Java Best Practices