Rescue the java world
IT is always in motion. In the last decade the web has made enormous changes. Also smart-phones and tables have caused dramatical changes.
Java 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 overslept 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...
Fate and fortune have caused that HTML and JavaScript are now (miss-)used to realize Rich-Internet-Applications with endless pain for developers. Most people seem to simply accept this aberration and now start to make JavaScript the universal programming language on 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 one my way 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: http://m-m-m.sourceforge.net/apidocs/net/sf/mmm/client/ui/api/package-summary.html
Java started with Swing as the universal and inter-operable 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. Everything changed with the web 2.0 where JavaScript developers where brave 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 misuse of technology initially not designed for such purpose the entire 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 tablets 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-plug-in 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 on widgets and "think" in screens. However, for developing a large-scale (web-)client-application you need to think in dialogs and not screens or HTML pages. 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 platforms. 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 towards this direction. Apache Cordova helps to make this reality today.
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 implementations 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 Android 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 design 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 smart-phone 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 safety 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 switching to another implementation means re-implementing the client from scratch.
I know very well that I can not offer this safety 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 opportunity 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 reusing code such as validation and other business logic on client and server.
One could say - we do not need a programming API but a standard description format to define dialogs in resource files. Believe me that the programming API has to be first to allow the required dynamics. But this will be the next topic then :)
We all remember the times when many users disabled JavaScript in the browser. 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 believe 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 mislead 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.
Update: I found some projects with similar goals that I need to contact:
This documentation is licensed under the Creative Commons License (Attribution 4.0 International).
