Oracle doesn't use/define the SQL Type Boolean. You can't define a column in a table as Boolean. It's possible to use boolean in PL/Sql e.g. for procedures or functions but you can't call the function from SQL.

Example functions

It's possible to call:

but it's not possible to call:

or

(1 = true, 0 = false; boolean is mapped to integer in Oracle)

If you want to call a procedure or function which defines boolean parameters, it's not possible without tricks with Oracle JDBC driver. This is annoying.

We solved the problem in JVx 2.4 and it's now possible to call functions or procedures without tricks. Here's a "more complex" example. We define a function with an input parameter and a procedure with an input/output parameter in a package:

Now we use JVx' DBAccess to call the function and procedure.

The whole type mapping was done in OracleDBAccess and it's invisible for you. Simply use the API to call procedures or functions.

Some days ago, I wrote about our eTV project. The blog post had some pictures but no more details. I want to tell you some details about this project because it's simply awesome.

The project was a research project of our framework team and was started just for fun. The use-case was simple: Our room had 4 walls and 3 were full with pictures and world maps. Only one wall was empty. Why not using a flat TV for showing different content like livestreams, comic strips, images.

The idea was great and some days later, the last wall was full. A nice 43" flat TV was mounted.

We thought that a RaspberryPi could bring the content to the TV because it's a small device and fits behind the TV. Java works without problems on the Pi and JVx as well.

After all hardware pieces were ready, it was time to think about the software because a sort of control center was needed to implement some features. The plan was to write a simple server which has a set of commands like: open website, show image, play livestream, execute command, upload file, download file.

The server was implemented as simple socket server, with JVx. It executes pre-configured commands and has some important control features: take screenshot, next - previous window, get window list, close window. The server has no GUI and is more or less a window/process manager.

The server has no GUI, but we need a GUI to control the server. We wrote a simple JVx application as remote control. The remote control application was deployed on a Jetty application server (on the RasPi, with vaadin UI) and as mobile JavaFX application. Jetty runs fine on the RasPi and our vaadin UI as well.

The TV with RaspberryPi, streaming a Video from YouTube:

eTV YouTube Stream

After we were ready with the server, we tried to create a simple JVx demo application to demonstrate JVx on embedded devices. It was funny to use eTV for live streams or to show images, but what about real-world use-cases?

The idea was about a JavaFX application, running on the RasPi. The application could be a monitoring app for a warehouse with a nice looking frontend and a backoffice view for administration. It's usual to have a nice looking frontend and a not so nice looking backoffice part.

We've implemented an application for a big assembly hall. The application is a styled JVx application but still 100% JVx. We've used VisionX to create the UI:

VisionX design mode		TV mode

The application in VisionX is not 100% the same as on the TV because of the screen resolution, but it's the same source code and VisionX works with this application. The application on the TV hides the application frame and only shows the screen content, but this is a supported feature.

The UI technology is not JavaFX! We tried to use JavaFX but it wasn't possible because the RasPi had performance problems with the amount of nodes. It wasn't possible to reduce the amount of used nodes with standard JavaFX controls. Overclocking the Pi didn't solve the problem.

We simply switched to Swing and didn't have any performance problems. So, the UI technology is good old Swing. It works great in combination with the RasPi and we think the result is also nice!

The application is a monitoring application for different events, like performance, effort, pressure, temperature, aerodynamics, alerts. We did connect a temp sensor and two buzzers to get a better real-world experience and because it was easy to support with a RasPi. Initial setup:

Initial setup

The backoffice/backend was deployed as web application (Jetty on RaspberryPi, JVx vaadin UI) because it should be possible to use it on tablets or smartphones without native apps:

Backend view

The same UI on mobile phones:

Mobile view

Mobile view (no menu)

The application is a 100% JVx application with Swing UI and vaadin UI. Everything runs directly on the RaspberryPi.

We've used the whole eTV system as showcase application at DOAG conference in November:

eTV @ DOAG 2015

The results of our "research project" are awesome and eTV is a ready-to-use product. We didn't code one line of code to support different UI technologies and didn't have problems with resolutions of tablets, smartphones or the TV (#responsive).

Thanks to JVx it was super easy to create an amazing application.

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.

Our (research) projects with JavaFX are almost finished. We have awesome results and everything is production ready. The only drop of bitterness is the performance of JavaFX on desktops and mobile devices, but this can be improved by Oracle. It's not in our hands.

What do we have?

We have

• a complete JavaFX UI for JVx
• a custom application frame for mobile applications
• Live CSS manipulation of installed apps (needs debug build)
• Complete Project export for JavaFX mobile projects (JavaFXPorts based gradle project),
  integrated in upcoming VisionX 2.3
• Remote Work-screen loading (via VisionX)
• JVx server runs without limitations on mobile devices
• JVx client runs on mobile devices (for network clients)

How does it look like?

I have some screenshots from two applications. The first one is a standalone JVx application. The whole JVx framework runs on the mobile device. The app is a remote control for our eTV project (it's a brand new side project of our research team).

The app was inspired by MS Metro style ... Windows8 style ... Modern ... Universal ... Windows Store ... Windows apps.

The main screen has some buttons to control our eTV and some buttons open a "popup" with additional options:

eTV Dashboard		eTV Window view
eTV Gallery

The second app will be shown as Video, because we want to demonstrate how we use VisionX to create backoffice apps in under 5 minutes! The app itself isn't complex and does "nothing special", but the same mechanism works for complex applications like our Demo ERP system (read our Code once. Run anywhere post).

Our JavaFX mobile project was based on the great work of Gluon and their JavaFXPorts OpenSource project and also on RoboVM.

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.

We have a short video about our LIVE css hacking feature for mobile JavaFX applications on YouTube:

We demonstrate a mobile JavaFX application, running on a Nexus 9 Tablet. It's a pure JavaFX application with our mobile application frame and it was deployed with JavaFXPorts. In the video, we change some styles on our Laptop and the application updates its styles on demand. This is really useful because resolution/screen size can be different. Sometimes the background color looks different than on a Desktop, ... And it's easy to try out new styles without application restarts - same principle as developer tools for Chrome or FireBug for Firefox.

But how did we implement this feature?

It was too easy

Here are the "secrets":

• A simple socket server for the application
• A custom URL handler for loading remote-retrieved styles
• A simple File watcher for the client

That's it!

But to be honest, the custom URL handler was very tricky, because we tried to find a very smart, non-static, solution. And every platform has its specific handling and URL loading mechanism. But one step after another.

I guess you know that a socket server isn't a real problem. We wrote our own "generic" socket server some years ago, for JVx and it's not tricky. In principle, it works like this snippet:

The problem is that you need a sort of protocol for the content. We've used our UniversalSerializer and send simple POJOs. The stylesheet POJO contains the css file as byte[]. Here's our server code:

We add custom stylesheets with remotecss as protocol. The resource loading mechanism of Java(FX) tries to load the URL automatically. The protocol isn't a standard protocol and so we had to create a custom URL handler. The problem wasn't the handler itself because it's straight forward:

And the CssURLConnection also wasn't a problem:

The problem was that the JVM didn't know how to load remotecss:// URLs because it doesn't have a default handler. The JVM offers different solutions for this problem and the well known is:

But this is a static mechanism and we didn't know if another library uses the same method. There's no getURLStreamHandlerFactory in URL and the solution wasn't good enough for us. For a simple test application this restriction shouldn't be a problem, but we didn't like it because we're framework developers.

There's another solution for the problem, because the source code of URL contains the static method:

This method tries to load protocol handlers automatically, if definded via system property java.protocol.handler.pkgs or from package: sun.net.www.protocol.protocolname.Handler

After reading the source code, we found a blogpost about this feature, read more. It was easy to search with the right keyword after we knew the solution.

...be careful with security manager, but this shouldn't matter.

The URL implementation for Android is a little bit different because but if you set the system property, it'll work as expected.

The hardest parts were done and the last thing was the file watcher client because we planned to send the changed CSS file(s) to the app automatically. Here's our solution (Java8 style):

The source code examples aren't complete but I guess you can implement your own solution based on them. We made tests with iOS, Android and Desktop applications and didn't have any problems. The CSS editing feature would be a very useful extension for ScenicView but it's not available right now.

Our test devices:

CSS hacking - test devices

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.

Es gibt seit heute einen neuen Artikel über JVx in der deutschen Presse. Hier das Intro:

Die Erstellung von modernen und optisch ansprechenden Anwendungen ist gerade ein heißes Thema. Egal welche Fachzeitschrift oder welches Onlinemagazin gelesen wird, ein Artikel über JavaFX ist immer dabei. Wer Webanwendungen bevorzugt, findet auch ganz bestimmt einen Artikel über Vaadin. Und natürlich...

Der vollständige Artikel wurde heute auf Informatik Aktuell veröffentlicht. Natürlich lesenswert

Jegliches Feedback ist willkommen.