Already at the beginning of this year we started to improve the support for Lambdas in JVx. Now with 2.4 only a few days away, I'm happy to announce that we managed to improve it dramatically! Our events are now supporting basically every method which you can imagine as handler.

But let's not get ahead of ourselves, shall we? As most of you know, our own event handler scheme had support for basically five different variations of listeners:

This scheme allows us to wire up basically any method to the event, and even to wire the same method to different events. Behind the scenes there is some reflection magic going on which I won't describe here, but with Lambdas entering the stage this changes quite a bit. The good thing about Lambdas is that they are fitting neatly into the already existing interface structure, so you can replace any interface implementation which has only one method with a lambda.

That means that you can do something like this:

But if you wanted to use a method without parameters you were out of luck until now, because listener interfaces always expect a parameter. With 2.4 there will be a new interface, called IRunnable, which provides a method which does not accept any parameter and can throw any exception and the EventHandler will also accept listeners which implement this interface. That means that the scheme outlined above is now fully possible with lambdas.

And more good news, did you notice that the visibility of these methods changed from public to private? With the new Lambda scheme these methods no longer need to be public, they can have any visibility and will still work as intended.

So JVx 2.4 is the release when it comes to Lambda support, and everyone who has the possibility to already use Java 8 can now enjoy full support for them.

After one year of JavaFX development, we thought it's time to write about our experience.

We started in Nov. 2014 with our first bigger JavaFX tests. The idea was an UI implementation for JVx. We thought it should be an easy task because JavaFX is a desktop technology. We had another research project in 2012, but the result wasn't as expected. Sometimes it's a good idea to re-start from scratch!

JavaFX wasn't very popular and is still not a Superstar, but we love researching and we thought it might be a good idea to bet on JavaFX. Not only as pure desktop solution and Swing replacement, but also for mobile app development based on JavaFXPorts and for embedded devices, like Raspberry Pi. So we had this big picture in mind.
We thought it would be awesome to create a single JavaFX application, for all platforms and devices. Sure, some other companies tried to solve this problem as well, but we didn't try to do the same. Our idea was simple and based on JVx. We hade this awesome JVx application framework which enabled GUI and technology independent application development. So we tried to solve the GUI problem because all other things like persistence, remote communcation, i18n, ... were already solved by JVx.

We did different GUI implementations for JVx, before we started with JavaFX. Our first one was based on Swing, followed by QTJambi, GWT, GXT, a headless variant and - last but not least - vaadin. We also made some tests with Flex and Pivot, but we didn't create more than some simple PoC. To be clear: GUI technology know-how was not the problem!

We knew that JavaFX didn't have a solution for MDI and especially a DesktopPane was missing, but it wasn't a problem to create custom components/controls. We had some hard months of development because we found out that JavaFX wasn't a mature toolkit like Swing. We had to find many workarounds for very simple problems and had to create more custom components than expected. We solved most problems in our own code, but it wasn't possible to change some basic problems. We tried to get in contact with the developers, via JIRA, but it was hard to explain real-world use-cases to toolkit developers. Our developers at SIB Visions create custom products and projects together with customers for their needs. So we had many UI toolkit requirements from real users. Some issues were accepted but not all. Many bugs were fixed but we had big problems with Feature Requests. So far so good.

We finished our JavaFX UI implementation in April 2015 and it was a big success, because we had a fresh UI technology with lots new features and animations, transitions, web and media views, .... awesome.

We thought that JavaFX will be improved in 2015/2016 and it will be mature enough to use it for our customers.

Wait... what's the problem with JavaFX?

Performance, Memory, limited chances to modify standard controls

The performance is not good, if you have many controls (= nodes). It's different on Windows, Linux, MacOS. It's much better on MacOS than on any other supported OS. If you develop business/backoffice applications, the performance is very important. Sure, if you create simple form based applications, it doesn't really matter.

We use JVx to develop huge backoffice applications and currently, JavaFX should be used with care.

What do we mean with "performance is not good"?

• Large TableViews have scroll delays
• Layouting sometimes need some "extra repaints"
• Scrolling with many controls is not immediate
• Startup time of an application is too long, compared to e.g. Swing applications

The version number of JavaFX 8 is too high for it's maturity.

JavaFX has big potential but we're not sure if it'll survive it's predecessor Swing.

And we're not alone with our opinion: Should Oracle Spring clean JavaFX

But there are also companies with JavaFX applications: JavaFX Real-world apps

There's more

The toolkit issues are one thing. Another big surprise was that Oracle stopped official ARM support in Jan 2015 which didn't mean that JavaFX doesn't run on ARM devices (RaspberryPi, ...), but it's not officially supported and Oracle doesn't fix bugs or implement improvements.
Thanks to Gluon it's still very easy to use JavaFX on ARM devices.

Another step backwards was the migration to Bugzilla. In 2014 (and earlier), JavaFX was a "newcomer" and announced as Swing replacement. The development process at Oracle was very open and you had a "direct connection" to the development team, or something like that. It was very simple to report issues and to get feedback from the developers. It was fantastic to see and feel the progress. This is different nowadays, because the ticketing system moved from JIRA to Bugzilla and it's more or less readonly for standard developers.

One problem with JavaFX is that Oracle doesn't tell us the strategy behind JavaFX. The investment of Oracle in JavaFX was high, but what will be the next step? It's hard to bet on JavaFX without definitive commitment from Oracle.

But we still hope that JavaFX will be the one and only UI toolkit for Java.

JavaFX for Android and iOS

In summer, we moved forward and tried to use JavaFXPorts. It makes it possible to use your JavaFX application as native Android and iOS apps. Our JavaFX UI worked with some smaller changes out-of-the-box. It was awesome to see our JVx on Android or iOS devices! It was a milestone.

But things have changed since summer because JavaFXPorts has a depency on RoboVM. It was an OpenSource project and was a big win for the community. But now it's a commercial tool (read more). This has no impact for us, but means that we can't offer an out-of-the-box OpenSource solution.

JavaFXPorts also works without RoboVM and there are plans for a JVM running on mobile devices, but this won't solve the problem that you need access to device features/APIs. But we'll see what happens in the next few months.

We had some fun in the last few weeks because we tuned our application frame for mobile devices. A mobile application has some specific characteristics and isn't a 1:1 desktop application. A desktop application usually has a menubar and a toolbar. The same app on a mobile device shouldn't use a menubar or toolbar. It should offer a hamburger button which offers a custom menu. Also the style of the controls should be different on mobile devices, e.g. Tabsets.

There are two interesting projects which offer custom mobile controls. The first is a commercial product, from Gluon and the second one is JFoenix and it's OpenSource (LGPL). We took JFoenix because it met our requirements and JVx is OpenSource.

We have some screenshots in older posts:

• Code once. Run anywhere
• Live CSS hacking

Resume

JavaFX has potential to rule the Java UI world, but it needs an official commitment/statement from Oracle. Now it's unclear if JavaFX is the right UI technology for the future.

We hope that JavaFX is the right toolkit, but we aren't sure. Our investment was risky and high, but no risk - no fun. The results are awesome!

Thanks to JVx the UI technology is not important for us, because if JavaFX won't make the race, we still have Swing or vaadin. It's important to be UI technology independent because it saves time and money and is future save.

Our current Vaadin UI got a new feature. It's now possible to set a background image for a Panel.

This feature was already defined in JVx' IPanel but our vaadin UI didn't support it out-of-the-box.

We already had a custom Panel and it was an easy task to add missing functionality. Sorry, we don't have an extension for this feature, but it shouldn't be a problem to create an extension based on our implementation.

Our solution

As mentioned, we had a custom panel implementation. Its a simple extension of CssPanel with an implementation of SingleComponentContainer. The class can be found here.

The important part in our implementation is that we have a custom State and Connector for our Panel. The state got additional properties for the background, like repeat-x, repeat-y or the size. The image itself is a Resource and we re-used the existing transport mechanism for image resources. The mechanism is available in AbstractClientConnector. The nice thing with this standard mechanism is that the client has a method to build the correct image URL, automatically.

Our implementation:

The most important thing was the connector on client side which reads the State and sets the background image via css. The full class is available here.

The following code snippet shows how we set the background image. It's not really tricky

The method getResourceUrl is an existing method and returns the full image URL. It was easier to re-use this method than creating the URL manually.

We made a simple test in our showcase application and the result was as expected:

Background image

The image was set with following code:

JavaFX mobile

Today is the last conference day and we had our second talk. The title was: Mobile applications with JavaFX We described how a JavaFX desktop application could run on a mobile device without any changes but with mobile user experience. Thanks to JavaFXPorts it was very easy to realize this use-case.

If you have time and want to talk about JavaFX, JVx or VisionX visit our booth and push our buzzers.

SIB Visions @ DOAG

The talk about MS Office as Report designer was on Tuesday:

Reporting design with MS Office

We showed how we use MS Office to create Report templates and fill the templates with data. It's super easy for an end-user to create a custom report becasue MS Office is well known and easy to use. We use this template mechanism for our customers and it's a super easy and fast solution. Lets create a comples Report in minutes without additional coding effort. Simply use MS Office and layout your Report. The fill-in mechanism just uses your template.

DOAG 2015 will be in Nuremberg this year. The conference starts at November 17 and ends at Nov 20.
This year, we have two talks. The first one will be about mobile application development with JavaFX and the second talk will be about MS Office as Report Designer. Both will be in German!

We have a big surprise for all attendees. It's a ....
Okay, it's not really funny without details, but it's a surprise!

For all those, who don't want to wait

We'll demonstrate the power of JVx and VisionX with a super cool showcase. Visit our booth and have fun!
Here's a screenshot of a new JavaFX mobile application. This application is one element in our showcase....

eTV portrait

eTV landscape

Above application is a simple JVx (standalone) application. This means that JVx server runs in the same application.

Don't miss the opportunity to learn more about our showcase and to listen to our talks.

We got awesome mail!

Our community T-shirts are in-da-house!

JVx, original green

JVx, white

VisionX

The text is on the front and logos are on the back. Simple and Smart as JVx and our Source Code.

The first chance to get a shirt will be in Hamburg, November 3rd. We'll present JVx at the Java User Group.

It's some time since my last post about JVx. But I have a good excuse - Coding

I tried to improve our JavaFX UI for mobile devices. It was a hard fight but I won. Not everything is done right now, but the result is soo awesome!

Many of you know that JVx is an Application Framework. It's small and simple but still very powerful. It follows the convention over configuration principle and it was designed to be UI technology independent. Oh, it follows the Single sourcing principle too, it's a Full-Stack-Framework, contains a very smart persistence implementation, and so on.

What means UI technology independent?

We define the term as follows:

Code an application once and use it on different platforms and with different devices and different technologies.

As platform, we recommend Windows, Linux or MacOS. Devices are Desktop PCs/Notebooks, Smartphones, Tablets or embedded Hardware like RaspberryPi. We use the term technology for UI toolkits/standards like HTML5, Java Swing or JavaFX.

JVx isn't a JavaScript framework or library because it supports every platform with maximum power. This means that a desktop application runs as standalone application on your desktop computer with full access to connected hardware. A HTML5 application runs in a web browser and has limited access to the device but you have full css features and websockets. If your application runs on mobile devices, simply use all available hardware features and gesture support.

All the platform/device/technology specific problems were solved in JVx and a developer simply has a standard API to create applications. If the standard API isn't enough, it's easily possible to access the technology features without limitations. JVx encapsulates but doesn't hide anything.

With JVx you can code desktop applications, browser based HTML5 applications or native mobile applications without know-how of every platform/device/hardware.

I guess it's time for facts and some screenshots should clarify what I mean.

Desktop Swing UI		Desktop JavaFX UI
vaadinUI corporate		vaadinUI simple
vaadinUI Legacy
mobile fxUI		mobile fxUI menu
mobile fxUI legacy

All screenshots show the same application (same source code) with different UI technologies and on different devices. We have UI implementations for vaadin, JavaFX, Swing. We have different application styles because the application shouldn't look like a desktop application, on mobile devices or in your browser (but it's possible).

The application style itself is fully customizable and it's only one possible implementation. It's not a problem to change it or create a new one from scratch. We've defined that our standard applications have a menu, a toolbar a content are (for screens) and an authentication mechanism (login).

If you compare the vaadinUI with Swing or JavaFX UI, you'll see that the vaadin style has a completely different menu. There's also a legacy mode which shows windows for every screen, but this style isn't the preferred one. Sure, sometimes this style makes sense but it's not very user-friendly. If you have an application with few screens, a simple menu would be useful and if your application has many screens, the corporate style could be better because it has a menubar and a sidepane for quick navitation.

The mobile variant is our latest style and it's really different. You won't use apps in MDI style. Sure, we have this style but it's ugly. We like hamburger menus as shown in the screenshots.

JVx is very fast, flexible and powerful. Don't waste time for platform problems, simply implement your requirements by using JVx.

Wir sind am Dienstag, 03. November zu Gast bei der JUG Hamburg.

Nähere Details gibt es hier.

Im Moment sieht die Teilnehmerzahl verblüffend aus und das Thema dürfte auch für viele passen. Wir können allen interessierten schon jetzt versprechen, daß wir einige Überraschungen mitbringen. An einem zusätzlichen Highlight arbeiten wir noch und lasst euch einfach überraschen. Es wird auf jeden Fall etwas neues sein!

JVxEE version 1.2 is out!

The good news

JVxEE is now available from Maven central, that means that you can add it as dependency to your Maven projects:

The first of the two major changes are that we fixed possible exceptions that might be thrown by JPAStorage.getEstimatedRowCount(ICondition), it should now work under all situations.

The second change is the handling of foreign key columns. Previously, foreign key columns where named with the pattern "REFERENCEDTABLE_REFERENCEDCOLUMN", which can lead to collisions if there is more than one column referencing the same table and primary key. So it was possible that you would end up with two columns with the same name, which of course can't be handled by the storage and databook correctly. We devised a new naming scheme and from now on the foreign key columns are named with a combination of the referencing column and the referenced column.

An example:

With 1.1 the generated columns would look like this, for entity "A":

And with 1.2:

This is definitely an improvement!

The bad news

There is always a downside

The changes in the foreign key column naming scheme, to avoid collisions, also mean that most foreign key columns do now have a different name. You'll have to check your code for usages of the now differently named columns.

But there is also an upside! With EPlug you will find those easily.

Usage example

JVxEE provides the possibility to utilize the Java Persistence API (JPA) as backend for storages and databooks. JPA is powered by POJOs, like these:

This is an extremely simplified model for airline flights.

There is an aircraft that can be used, airports that can be flown to and from and the flight itself. Flight is referencing both, the aircraft and the airport. Now we only need to tell JPA about these classes by placing a persistence.xml in the META-INF directory, like this one that we use for our unit tests:

(Sure, it's also possible without manual XML mapping)

Now all that is left is creating a new storage that uses the JPA:

And that's it! From here on there is only JVx code.