Rescue the (java) world - help needed
IT is always in motion. In the last decade the web has made enmourmous changes.
Also smartphones and tables have caused dramatical changes.
Jave was initially designed as the language for the web. Every browser
used to have java on board and has been able to render applets.
However the entire java world overlsept the chance to improve this
technology with DOM access or other features to address the actual
needs of web-applications. Maybe JavaFx could be
the rescue - maybe not...
(miss-)used to realize rich internet applications with endless pain
for developers. Most people seem to simply accept this aberration
client and server. If you see what is going on with node.js it seems
to me like going back to the roots and make the same design mistakes (e.g.
direct mysql access without abstraction like JPA) again without learning
from the state of the art.
I scream it out: Let us stop this madness!!!
Well, these people can do what ever they want but the java community
needs to offer a true alternative. So here is where I need your help,
the help of many good open-source developers. I am willing and full of
energy to create a meta-UI-framework in Java. I have put all my experience
of rich client development into a IMHO great design and started an
implementation in my open-source project. Please have a look.
You can get started here to get the philosophy:
Some words about the history of client development in Java:
Java started with Swing as the universal and interoperable native client technology.
I still think it is quite nice. However others did not like it and created
SWT, JFace and EclipseRCP as an alternative. For a long time such technologies
where used for rich clients while web-technology with all its limitations was
used for thin-clients. Managers always used to think that for easy distribution
of clients and reaching the largest audience you need web-clients. Therefore
JavaWebStart never reached its potential and is not commonly known.
and crazy enough to build all the features of a native client within a web-client.
While this was insane from the start and a missuse of technology initially not
designed for such purpose the enitre world ran for this hype. It took me some
time till I understood that there is absolutely no chance to stop this trend.
Mobile devices and tables came in making all this a lot worse (I mean its absolutely
cool for the users but no fun for developers and architects). So finally it
has actually become true what managers started to say about web-technology.
Additionally one could observe that a single decision of Apple could sweep
away Flash from the market within about a year or two. This was an indicator
that it seems that bringing a reasonable programming model into the browser
via a vendor-plugin technology (including silverlight, etc.) has finally failed.
We will see what happens to Google Dart...
Java has millions of web-frameworks. This is an obvious indicator that there
is NOT a single solution that solves all the real problems. Most of them
focus und widgets and "think" in screens. However, for developing a large-scale
(web-)client-application you need to think in dialogs and not screens or
As I had to follow the web 2.0 hype I picked GWT which is a great technology
but has a major drawback: developer tests are extraordinary slow as starting
a large application in DevMode is taking too long.
JSF is nice but can, by design, not address the real needs of the RIA as state
and presentation should be fully on the client side.
To make everything even worse there are these apps for mobile devices.
If you want to reach a large number of users you need to support the three
major plattforms. Doing android is quite fine for java developers but
ObjectiveC without packages is a crime to developers. Maintaining the "same"
app with 3 totally different codebases on totally different operating systems
is a major drawback. Again web-technology wants to make the universal deal
and HTML(5) is going to support the possibilities of these apps. ChromeOS
is totally leading in this direction. Apache Cordova helps to make this
So you might ask yourself. Wait a moment. This guy is saying that there are
too many web-frameworks and other solutions and therefore we should create yet
another new solution?
Yes and no. I do not want to create a UI-technology. I want to create a universal
API for UI-technology in Java. This is the most missing link and the major success
in Java itself have always been the good APIs like JPA and not the implemenations
like Date or Logging. A well designed and widely accepted API is the important key.
I also want to create implementations that adapt from this API to existing native
UI-technolgies. And I have already done this for GWT and in previous versions for
Swing and SWT. I see enough of my vision to say that it is really possible.
So in the long run you can write a client once and then run it as native Swing app
or build it for andorid or using GWT as web-app, etc.
This might sound crazy, but with enough abstraction this is possible.
Client programming is currently working in a way that the developer places widgets
in panels and organizes them on top or beside each other on the screen. However, if
you look at a client on a higher level you can see that there are high-level desing
patterns such as a master-detail panel. On "desktop applications" this is showing
a list of items (e.g. emails) and a details panel to view or edit the selected
item below or beside. On a smartphone you have the same pattern but with a list
and if you select an item the list slides away and the details panel slide in.
Do not expect magic that renders perfect results on every screen and device without
invest and manual optimizations. But even if you build a client for a single target
technology this approach will give you a lot of safty for the invest of your
(large) client application because you can switch to another technology with
reasonable effort. It would already be a great help if only the common sense
is available via a common API. Every UI-toolkit offers buttons, text-input,
combo-box, etc. But currently we only have implementations like Swing, GWT,
SmartGWT, GXT, etc. that all have the same things with different APIs.
Without such API and the chance to switch an implementation no manager or architect
would even try JavaFX or whatever for a really large project. The future is to
unsure and open.
I know very well that I can not offer this safty with an open-source codebase but no community.
But if many others join in and this can become a apache or java.net project or
even a JSR the future is open and Java has a great oportunity to come back to
the client and allow to use the same language both on client and server offering a
consistent model of transfer-objects and resuing code such as validation and other
One could say - we do not need a programming API but a standard description format
to define dialogs in resource files. Belive me that the programming API has to
be first to allow the required dynamics. But this will be the next topic then :)
Now the trend is going to ban Java from the browser.
But never forget: Nothing is as sure as the change.
I want you to discuss, contribute, support, or spread.
Please help to rescue the (Java-)world!
I belive in Java not because it is the best programming language but because
it is simple, open, has a great eco-system and an awesome community.
BTW: Do not be misslead by the name of my OSS project. I wanted to write
a multi-media-manager but as a seeker of truth I first needed the proper
infrastructure to build on. This is where I seem to end but I really want to make it happen.