DataFX 2.0 is released

Yesterday, we launched DataFX 2.0. One month after releasing a developer preview, we feel it is time to promote the current code as a public release. We feel confident that with DataFX, JavaFX developers can easily connect their applications to back-end systems, and make sure data is visualized in a responsive, thread-safe way.

For more information on DataFX, you can visit the website at http://javafxdata.org. DataFX 2.0 runs on top of both JavaFX 2.2 as well as JavaFX 8. We are now starting the work on DataFX 8, which will only run on JavaFX 8. We might release a DataFX 2.0.1 version containing bugfixes, but only if there is a real need for.

DataFX 2.0 is released under the BSD license. The source code is available at http://bitbucket.org/datafx/datafx and the binaries can be downloaded from maven central:

org.javafxdata
datafx-core
datafx-cell
datafx-controller
datafx-websockets
datafx-samples

A direct download from maven central is available via https://oss.sonatype.org/service/local/repositories/releases/content/org/javafxdata/datafx-core/2.0/datafx-core-2.0.jar — you can easily contruct the download links for the other components.

While developed in the open, and freely available, we do offer commercial support for companies that want a deeper understanding or integration, or that want specific features. In case you are interested, have a look at our support page at http://www.javafxdata.org/support.html.

Apart from commercial support, we do our best to address all questions and issues raised on the google group https://groups.google.com/forum/#!forum/datafx-dev.

DataFX 2.0 focusses on retrieving data from back-end systems. With DataFX 8, we will expand this, and we will also spend more time on “Enterprise JavaFX”, making sure that enterprise developers can leverage typical patterns as injection and inversion of control in JavaFX Applications.

Hendrik Ebbers wrote a blog entry on what we are working on already, you can read it at http://www.guigarage.com/2013/12/datafx-controller-framework-preview/.

We hope you enjoy DataFX 2.0, and we’re looking to work with you in order to make it even better.

Committed to Open Source

When Oracle announced it would no longer offer commercial support for future versions of GlassFish, many people started to “defend” Open Source and blame Oracle. More important than this particular example, I think it is about time that the software industry starts to re-think about how to work with Open Source developers and Open Source technologies.

The best blog entry I’ve read on this subject, is this article from David Blevins: http://www.tomitribe.com/blog/2013/11/feed-the-fish/. If you didn’t read it yet, I highly recommend doing so. I completely agree with his analysis. I hear similar sounds outside the Java EE area as well, and I am worried about this. It appears the industry has created a culture where it is assumed that some geeks will spend all their spare time to “Open Source” products. If those geeks somehow want to be refunded, they are not cool anymore. The industry decided that they have to start a consulting company around their Open Source products. That is valid business model, and to be honest, at LodgON, we’re actually doing this with DataFX, the Open Source JavaFX enterprise framework I co-develop. DataFX is all open and free, but we offer commercial support for companies that want to integrate it in their own products or projects.

To be honest, I think forcing open-source developers in this area is a bad idea. It can be a success story though. Some of the brightest open-source developers are capable of starting a company, e.g. look at what my old cohort Dries Buytaert did: after founding Drupal, he co-created Acquia and Acquia is now a leading technology company. That is great, and I have lots of respect for developers like Dries that also have skills for creating a company, an organization and a culture.

Other developers, however, don’t have the skills or simply the interest in doing this. They want to do what they are good at: writing code. Those people are often very bad in marketing themselves. Those people often spend lots of time in writing code, in answering questions on forums, in talking about their passion on conferences,… but they don’t get a proper reward for it. At the contrary, they might get blamed on forums for not implementing new features fast enough, or by not answering soon enough. Nevertheless, their value to our software heritage can not be underestimated. It is time the industry shows more respect to them. Geeks have to pay their bills as well.

There is an alternative, where a single company funds an Open Source project. This is what happened with GlassFish, and that failed. As David Blevins wrote in his blog entry: “Not even IBM or Oracle can pick up the bill for Open Source forever.” Open Source needs the involvement from a community (apart from potential involvement from one or a few companies), but the community somehow need to be rewarded for this.

Changing this culture is not easy, and it will take time. One of my (probably crazy) ideas is that developers might be considered “artists”. In Belgium, if an artist writes a song, and that song is played on the radio, or on a local party, the artist get some royalties for it. I am not going to say this is a perfect model, far from that, but the idea is that if people like what the artist is doing, they implicitly pay him. They probably pay a lot more to the artist’s manager and the distribution sector, but still, he is rewarded.

It sounds fair to me that if all those big companies and governments that are using Open Source technologies and that are so proud they use Open Source donate “something” back to the community. My favorite quote on this (I forgot who it came from) is that as an Open Source user, you either give time or money. This is already happening in some cases. To use another Drupal example, the White House is using Drupal for its website, and it contributes to Drupal as well — see http://buytaert.net/white-house-contributes-to-drupal. But this is exceptional rather than being the rule. Many government organizations send out RFP’s for their projects that (apart from 90% non-technical requirements that already rule out 90% of the developers that could do the job) explicitly require the use of “Open Source” technologies. Next, they pay way to much to a big IT consulting firm that somehow uses Open Source products (GlassFish, TomEE, Drupal,…), writes a bunch of proprietary code on top of it, and never donates something back to the Open Source development.

I would love to see more examples as the White House, where technology (time) or money is sent back to the Open Source project.

Most likely there are other valid models as well, that allow Open Source products to survive without being forced in the traditional business approaches. I really would love to see more discussions and initiatives in this area. Offering a free management course to all great Open Source developers is not going to help.

Finally, I want to stress that Open Source is not all about money. I am pretty convinced that most Open Source developers (including myself) are driven by passion. This is what makes innovation possible. As an example, I am currently working on a community port of JavaFX to Android. That is probably not the best thing I can do, from a financial point of view. But seeing my own JavaFX code working on my Android phone really gave me a thrill.

Committed to Java EE and GlassFish

It’s been a roller-coast year for the Java Enterprise world. The Java EE 7 specifications have been released, and work has started on the Java EE 8 specifications. While 2 of the major Open Source implementations of the Java Enterprise specifications are surging (Apache TomEE and WildFly), the Reference Implementation of Java EE (GlassFish) got in the news because Oracle will not offer commercial support for the current version and next versions. However, my faith in GlassFish remains.

When Sun Microsystems launched GlassFish in 2005, I was extremely happy. Until that moment, Java Enterprise development wasn’t really transparent to me. I was using JBoss and Sun ONE Application Server before, and they did a good job at that time. However, Java Enterprise standardization was not as transparent as it is now, and I didn’t have the source code for the Sun Application Server. I always try to understand why code is behaving the way it behaves, and I was in the dark. The code controlled me, not vice versa.

With GlassFish, it became much more clear. The source code was available, and over the years, the Java Enterprise specifications became more transparent and also more clear to me. Finally, I could use an Application Server that I felt I could control. People working with me know that I don’t like guessing. There are no quantum effects in our software development. Everything that happens, happens because someone instructed a CPU to do so. With GlassFish, guessing was not needed anymore. If “something strange” happened at runtime, I could easily follow the exact path(s) in the code, and investigate the context without modifying it. That allowed me to fix lots of bugs in my own code and in customer projects.

One of the main reasons GlassFish is easy to control, is the quality of the code. Some of the best developers I know worked on GlassFish. The Grizzly core is an amazing piece of Art. While very performant and scalable, it is still very readable and understandable. This is no-nonsense code.

GlassFish marked a new phase in Java Enterprise development. It didn’t just followed the standard by creating a Reference Implementation, it was also sort of an incubator where new specifications, technologies or patterns could be checked. If you look at the JAX-RS 2.0 specification, you can see that many ideas and patterns are leveraged from Jersey 1.x, which served as the Reference Implementation for JAX-RS 1. Jersey 1.x contained a client module which was not part of the JAX-RS specification, but it provided very relevant input for the JAX-RS 2 specification.

GlassFish is not alone in this role, anymore. I am particularly pleased by WildFly and TomEE at this moment. They share some of the basic requirements that I, being a developer, like: easy to understand and set up, no-nonsense, community-driven and very open to innovation.

At this moment, I see 3 mature Open Source Application Servers, being GlassFish, WildFly and TomEE. This is great, since I believe the next Java Enterprise specification should be mainly driven by input from these Open Source Application Servers. The three of them are relative open to new ideas, and somehow offer an “incubator” area although not always explicit.

In order to get great Java Enterprise specifications, the Java EE committee should look at how things are done inside these communities. GlassFish, WildFly and TomEE already offer more than just the Java EE specifications (i.e. GlassFish, bundled with EclipseLink provides access to NoSQL datasources). They contain the foundation for future Java EE specifications. Rather than one implementation defining the specification, I prefer a healthy discussion based on experience. Actually, this already happened for the Java EE 7 specification. If you look at the people on the Expert Groups, they often represent the innovative Open Source products combined with bright individuals.

Oracle’s official statement on the future of GlassFish is probably a bit in that direction. Oracle recently states what a lot of people expected to happen right after the acquisition of Sun: GlassFish is the Open Source Reference Implementation without commercial support and WebLogic is the commercial implementation.

I’m not at all worried about Oracle dropping commercial support for GlassFish. LodgON is now providing commercial support for GlassFish. We already did this before, by helping companies with performance or scaling issues, by setting up failover and by monitoring the server instances. At LodgON, we are committed to continue this. We try to stay involved with the GlassFish development.

Also, we are having a closer look to TomEE and WildFly, as they clearly made great progress over the last year. I plan to have at least one commercial project on TomEE and another one on WildFly next year. Experience with the three leading Open Source Application Servers should increase my insights in innovative enterprise technologies.

While Oracle dropping commercial support is not worrying me, I do hope Oracle is not cutting down the innovation in GlassFish. I realize some of the bright engineers and evangelists left the GlassFish team, but there are still great people working on it. I am looking forward to work together with them and make GlassFish 4.x and beyond a great and truly innovative Open Source product.