2015: The Year When JavaFX Takes Over

 

I must say that I very much enjoy using Google trends to evaluate the importance of a technology and to see what its future will look like. So today I ran a comparison between “Java Swing” and “JavaFX”. The result shows two things: once we enter the next year JavaFX will be more relevant than Swing but JavaFX will not be that relevant either.

I think this is totally wrong.

Based on the feedback I am getting from the community and also on the projects that I had contact with I foresee a rapid increase in JavaFX usage (and Google searches) over the next 6 to 9 months.

The main reason is the fact that a lot of companies will finally upgrade to Java 8 next year, and JavaFX has really only reached its full potential with this latest Java release. The second reason is the increased availability of third party solutions: open source projects like ControlsFX and JFXtras, and some commercial products (like mine: FlexGanttFX and soon FlexCalendarFX). The third reason will be the availability of JavaFX 8 on mobile devices (Android and iOS). Once managers see that they can ask their developers to use a single UI toolkit for desktop and mobile  development there will be no holding back.

So that’s my prognosis, please make sure to check back in Q2 2015 to see if I was right or wrong.

Advertisement

Collapp: First Release / Looking for Testers

I finally managed to release a first version of Collapp, a solution for collaborative project planning, and now I am looking for testers / early adopters. I have been working on it on and off for the last couple of years. In part to learn more about JEE and in part to continue work on FlexGantt (online demo), a framework for creating Gantt charts.

I believe that I have now reached a point where a bigger group of people could take Collapp for a ride. Anyone interested can now try the online demo or download the full installation. The online demo allows you to register a new user account and get immediate access to the application. If you also want to see the administration features then please send me an email so that I can grant you the required permissions.

Collapp is a JEE (rich) client / server solution running on the Glassfish application server and the MySQL database. The screenshots below show what it looks like when running it on a Macintosh (note: use Java 6, not 7) and on Windows.

The first release focuses on the management of so-called “Action Items” only. It does not contain any actual project planning functionality, yet (e.g. a Gantt chart, Work Breakdown Structures, Resource Calendars). I decided to go with this approach in order to get to a point where the application reaches production quality for at least some part of its functionality. Project planning will eventually be based on the action item feature as project tasks will result in action items that are assigned to individual team members.

A strong emphasize of my work was on the Macintosh UI of Collapp. I tried to come up with a user experience that is as close to native Mac apps as humanly possible. I would love to get some feedback on whether I was successful or not. For Windows I picked a more liberal approach by using the commercial BizLaf look and feel framework from Centigrade.

The Macintosh download also contains the standalone rich client, so that you don’t have to answer any annoying Java Webstart security questions. There currently is no Windows standalone client.

To read more about Collapps feature set, please check out these links:

• Collapp Planning and UI Concept
• Collapp Features (with Macintosh Screenshots)
• Collapp Features (with Windows Screenshots)

The Best Swing Look & Feel: BizLaf

I recently started using the look and feel library BizLaf of Centigrade GmbH (Germany) and I have come to the conclusion that, after 13 years of programming Swing UIs, this is by far the best look and feel library for Java that I have ever used. Reason enough to blog about it and to share my thoughts.

Prologue

For the last 2 and a half years I have been working on my very own software project called “Collapp” for collaborative project planning. I have made it my mission to make it one of the most professional looking applications ever written for Java (this is probably the reason why I still haven’t been able to release it). To me this means that the application should look polished on all platforms and at the same time feel natively to the platform it runs on. On a MacIntosh it should look like a Mac application (e.g. iTunes, iWeb, iPhoto, …) with typical Mac features (unified toolbar, sourcelist, …). On Windows it should look like a Windows application with the frame containing the menubar, and so on. It should be noted that Windows generally allows a higher degree of freedom when it comes to UI design (this can be good or bad).

Macintosh

For the Mac UI I was very lucky that I could use Ken Orr’s outstanding MacWidgets library. It gave me a great head start and I almost instantly looked at an application that fit right onto Macs. So far so good, unfortunately it is not very usable for Windows. The MacWidgets components really only work nicely on Mac, which in return shows how much attention to detail the Apple engineers put into the Aqua UI. Everything works hand in hand (e.g. the Window title and the toolbar appear as a single component / panel).

Collapp running on MacIntosh showing action items

Windows / Linux

So, what to do on Windows and Linux? Plan A was to use the Open Source look and feel project “Seaglass“. I presented this solution at JavaOne 2010 in San Francisco (Black Eyed Peas rocked!!!!) and for a long time I was very confident that I would end up using this approach. However, the development activities on this project slowed down quite a bit and there were always these little things that just didn’t seem right. Performance was also a big issue. Collapp felt quite sluggish when using Seaglass.

BizLaf

I started to get worried that I would end up with no UI strategy for non-Mac platforms, but then I read on Jonathan Giles’ excellent blog “Java Desktop Links of the Week” about BizLaf, a commercial look and feel implementation for Swing. I was first put off by the idea that I would have to pay for it, but still decided to evaluate it. I must say that BizLaf has been able to convince me 100%, because:

• It looks polished and professional. One can easily see that very talented designers had their say in the development of BizLaf.
• It is extremely easy to integrate and use. Simply call the standard UIManager.setLookAndFeel() method and then set a “style” on your components.
• It is very fast. According to Centigrade this is because it runs on top of their L&F engine “Cezanne”. I can confirm that it performs excellent even on my old company laptop running Windows XP.
• It uses a semantic approach, which means that BizLaf “knows” whether a panel is just a simple panel or a toolbar, or a header, or a status bar. Each one of them will be rendered differently.

The following screenshot shows the result of my transition to BizLaf. I am very pleased with the result and no longer have to worry that Collapp will run on Mac only (missing out the other 90% of the market).

Collapp action item list using BizLaf

Usage

Using BizLaf requires a little bit more code compared to other look and feels. In this sense it is actually not “pluggable” because of the extra code required. However, considering the benefits I believe this is an OK price to pay. In my code I now often see statements like this:

JPanel panel = new JPanel(); 
if (Collapp.isAqua()) { // runs on MacIntosh 
 panel.setBackground(Color.LIGHT_GRAY); 
} else { // runs on other platform 
 BizLafControls.get().setStyle(panel, BizLafStyles.HEADER); 
} 

In this example you can see “semantics”. BizLaf makes the panel look like a header panel. Currently there is not a lot of documentation for BizLaf as it is still in an early access state, but the PDF files that contain annotated example screens are really all that you need.

Summary

To wrap this up. I can highly recommend BizLaf as your look and feel of choice if you are in the market for rich client applications that need to satisfy high-end demands. The price for BizLaf varies between 1,800 Euros for the “Basic” license and 8,000 Euros for the “professional” version. The difference is in the support and also, and this is important to know, in the feature set. For example, the “Search Field” style for text fields is not part of “Basic”.

Collapp Sponsor Search

I have been working on Collapp on and off for some time now and made a lot of progress, but it is still not production quality. To change this I am now trying to find a sponsor for this project. I really need to get paid so that I can commit the necessary time to this project.

Collapp is a solution for collaborative project planning. Its goal is to have project leads and project team members all use the same tool. This way everybody is always informed about the current state of the project. Users can be members in several projects at the same time, they can also be regular team members in one project and team leads in other projects.

The ideal candidate would be a larger enterprise that wants to have their own custom solution for project planning, something tightly integrated into the rest of their processes (IT or business side). The current state of Collapp would give any company a great jumpstart, yet it is at such an early stage that it can be easily adjusted in order to meet any requirement imposed by a possible sponsor. Anyone interested? Feel free to contact me directly at dlemmermann@gmail.com

Some technical background: Collapp is a client / server solution utilizing the Glassfish application server (can be replaced by any JEE compliant app server). The client is a fat/rich client, which can run anywhere where Java can be run. Java 6, EJB 3.0. Deployment via Java Webstart or standard installer. A web client can be easily added if desired. Persistence layer: MySQL with Hibernate (can also be replaced). User administration: LDAP via JNDI.

Here are brand new snapshots to wet your appetite (taken on my Mac, it of course also runs on Windows, Linux, ,etc….):

Here is my resume if you want to know more about me: DirkLemmermannResume

Collapp / MacWidgets @ JavaOne 2010

I have been notified this week that my talk about “Attractive and Portable MacOS X Swing Clients for J2EE” has been accepted for JavaOne 2010 in San Francisco. The conference takes place in September and I will try hard to have a feature-complete application to show as a case study.

Please let me know if you are also attending JavaOne and would like to meet me there to discuss concepts, cooperations, contracting, consulting, UI stuff, Collapp, FlexGantt, etc…

Collapp – Collaborative Project Planning

This is a little status update on Collapp, formerly known as “Planner’s Workbench”. I figured that the name was simply too long, so I renamed it to something shorter and more catchy. Please feel free to leave a comment regarding the naming. I still consider it a working title and I am open for alternatives. Important is only that it is a one word name.

This post is an update because Collapp has been featured before on Ken Orr´s blog. Ken is the author of MacWidgets, a framework for creating Swing clients that look right on MacOS X. Collapp makes very heavy use of MacWidgets, as you can see in the snapshots below.

The initial plan was to release a first public beta of Collapp in the summer of 2009. But unfortunately license sales of my FlexGantt UI framework for Java/Swing declined and I had to start freelancing again. I am now working part-time for Credit Suisse in Zurich. This means less time for coding and even worse: it gave me plenty of ideas for new features. Especially since the poor guys at Credit Suisse carry quite a burden in regards to project planning. Right now I think that nobody needs my new app more than they do.

The idea behind Collapp is to provide a single planning tool both for the project leader and the team members. A project lead can create a project, add team members, create and assign tasks. Team members can view the tasks assigned to them and report feedback via comments or the percentage complete attribute. The next snapshot shows the most important view provided by Collapp for regular team members, the “Today” list. Here the team member can see which tasks, todo items, and calendar entries, are due today. A view like this one facilitates the “Get Things Done (GTD)” approach.

The next screen shows the todo browser. It uses the “column browser” feature that most of us know from ITunes. The difference between todos and tasks is that tasks are created by the project lead as part of an overall project plan, while todos can be created by anyone. Tasks are high level (e.g. “deploy application”), while todos are fine-grained (“talk to operations team about good deployment date”). Software developers can think of todos as issues / tickets, but without the whole workflow behind them. The task screen will look very similar to the todo screen but it is not done, yet.

Something I noticed many times is that project leads often do not have information about the availability of their resources. It is quite common that a team member will say that he was unable to complete a task because of this and that and that the project lead should have known that. Yes, in a perfect world, maybe. In the real world the project lead works on many things at the same time and can’t possible remember the schedule of every team member.

Collapp offers two calendars for each user. One to model the work week (mo-fr 8am-12pm, 1pm-5pm) and one for actual appointments, meetings, general unavailability. This information will be visible to the project lead in the Gantt chart screen (not done, yet).

So far we have seen list views (today list), table views (todo browser), and graphical views (calendar). A fourth kind that is very typical for any database driven application is a form view. The screen below shows how this looks like in Collapp. The user has to unlock a form before making any changes. This ensures that two users are not making changes at the same time, hence overriding each others changes. The form shown in the screen is the one used for making changes to the general project settings (start time, end time, project owner, visiblity, etc…).

Whenever I used project planning software (especially MSProject) I soon got the feeling of being lost. I didn’t know “where” I was in my project, meaning I didn’t know whether I am in a certain phase or which milestones have actually been reached. I always missed a summary / overview feature. To address this issue I added a “Timeline” view to Collapp, which is shown below. This view is still under heavy development but I think you can already see where I am going with this.

This is it for now. Any feedback is very welcome. Let me know which live-saving feature you miss the most in existing project planning software and I will see if I can address it with Collapp.

Advanced Java Webstart Login Dialog

I am currently working on a project planning software that “tries” to utilize Java Webstart as its deployment method. Nowadays it is common practice that login dialogs also allow new users to register with the application and existing users to retrieve their password if they forgot it. When I was trying to implement these features I ran into all kinds of issues and finally gave up.

The problem is that login dialogs for webstart applications are stupid. They are not aware of the context in which they are running. All they “know” is that they were shown to the user as a result of a callback from the server. The callback is asking for a user name and a password. This is fine for a simple standard login, but not for an advanced one. How can a new user be created on the server without some kind of connection to the server? Especially if the server is not even known, which is the case when running the webstart client inside an application client container (ACC). The whole idea behind the ACC is to provide injection capabilities, hence freeing the application developer from configuring the initial context.

The following screenshot shows the standard login screen. When the user clicks on the “Login” button the callback object will be populated with the user name and password. The application then simply continues if the login was successful. Another issue I had here was that I could not find out wether the login failed or not. On failure the dialog would simply disappear.

The next screen shows the controls used for registering a new user. I was unable to find a way to actually call something on the server so that the new user would be added. Please let me know if anyone knows a solution for this.

The last screen is used for retrieving a lost password. Once again I ran into problems. The server will not do anything without an authorized user. A solution would be to create a technical user, e.g. “sys” with password “sys”. These values could be put into the callback object and sent back to the server. But how do I let the application know that a password retrieval is in progress? Where do I trigger the code needed to send a mail that contains the user’s password?

Once again, any help would be much appreciated. I still have a couple of months of coding ahead of me before the first release. I would hate to give up on using Webstart as a deployment vehicle.