The first preview release of VisionX 2.2 is available. The exact version number is 2.2.41.

It available as trial version or for our customers via download area.

The preview release contains updates of all dependent frameworks like JVx and vaadin UI.

Here's a list with more details:

• Responsive web applications
  

  Window shutter web control

• Browser navigation
• Application styles
• Support for embedded devices
• Style definition with VisionX
  

  Style definition

• New EPlug support
• Custom Database connection strings (e.g. Oracle TNS entry)
  

  Custom connection string

• Live Template support for work-screens
• XLSX reports instead of XLS
• Ready for application monitoring
• UI improvements
• Ready for native Android client

Sure, we fixed some bugs and we also improved overall performance because of improvements in JVx. The most interesting thing is the support for embedded devices like RaspberryPi.

Have fun with VisionX

Did you ever use plain JDBC? For sure.

Wasn't it horrible because of so much boilerplate code? There are different solutions like Hibernate, EclipseLink, MyBatis, .... But such libraries create mappings, annotations, xml files, POJOs, ....

The idea behind JDBC is great but the API generates a lot of code and work.

I want to show you how easy DB access could be, without overhead.
First I want to define the table for our test:

The following snippet opens a HSQLDB connection inserts 3 records, checks the auto-generated id of the first inserted record, counts the number of records and does some filtering by id and value.

Here's the code:

Nice, isn't it. Hopefully I didn't forget a close() call. The use-case was simple and not really complex compared to real world problems, but the LoC are extreme. All together 144 lines (comments included).

Sure you could write a small utility to auto-close statements and to read result sets, but why re-inventing the wheel? The most problems seem to be trivial but gets really complex.

I want to show you different solutions with DBStorage from JVx framework. It's a small class with extreme power. It handles whole JDBC for you, solves CRUD and more. The class is a server-side class and was designed for multi-tier environments but can also be used directly on client-side.

Here's the code, for the same use-case as before:

Better? Only 49 LoC.

As I told you before, the DBStorage is a server-side class and the API wasn't designed as client API. But there are some very useful classes in JVx. We call them DataBooks. A databook can be compared to a database table because it is row and column oriented. We have different DataBooks like MemDataBook, RemoteDataBook or StorageDataBook. MemDataBook is the base of all our databooks and RemoteDataBook extends it. The StorageDataBook extends the RemoteDataBook. A remote databook gets its records from a remote storage. The storage databook directly gets its records from a DBStorage.
Sounds tricky? A little bit, but these classes allow using multi-tier architectures without making a difference how many tiers you use.

Here's the same example again, but using a StorageDataBook for using a DBStorage with client API:

The LoC: 51 (but we could save 3 lines).
The code doesn't use a remote storage, because we don't use a multi-tier architecture, but how does it look with a multi-tier architecture?

The server in our example is a Tomcat application server and we connect via HttpConnection. You could also use different server implementations like vert.x or a plain socket server.

Here is the code:

LoC: 50 (but we could save the same 3 lines as before)

The API calls are the same, but we used a HttpConnection, a MasterConnection, a RemoteDataSource and a RemoteDataBook. The HttpConnection could be replaced with e.g. NetConnection or any other transport protocol. The MasterConnection is protocol independent and handles the communication between client and server-tier. The RemoteDataSource is the datasource for RemoteDataBook. The RemoteDataBook communicates indirectly with a DBStorage on the server-tier.

The DBStorage definition for the server-side is the same as in all other examples:

but the server-tier contains the definition. The client doesn't know connection settings and credentials in that case.

Sure, there's a difference between fat-client, client/server and multi-tier architecture, but have you ever seen an easier API to use a multi-tier architecture?

The DBStorage and DataBooks have a lot of useful APIs for you and your database applications. It solves all CRUD operations, take care of column metadata and much more.

JVx is Apache 2.0 licensed.

In the last weeks, we did many experiments with JVx on Raspberry Pi, especially using a Pi as server for JVx applications. Our vision was that the business logic could run on a Pi without Java application server like Tomcat or Jetty. Our example application was a simple sensor recorder. We read temperature data and stored the read data into a JavaDB (on the same device). We knew that Jetty and Tomcat worked on a Pi but it was not necessary to run an application server without web content.

We tried different implementations:

• Fun

  A recorder class that saved data directly in the JavaDB. A good old Java application with one DBStorage because plain JDBC was painful.

• Because JVx can do that

  A simple recorder client with embedded JVx server. The client was a simple class with a DirectServerConnection. The server saved retrieved temperature data in the JavaDB.

• Production

  The same simple recorder client but the server run standalone. The DirectServerConnection was replaced with a Netconnection.

The first implementation was for fun only and not relevant for our tests. Our Pi should be a server that measures data and allows accessing data from JavaDB (for charts). Some real client applications could use the temperature server for integrating temperature data. The same application could use other Sensor data from different RasPis (measuring lux, webcam, ...) - a RasPi (sensor) network.

The big problem was that JVx server didn't work without an application server. It worked embedded and via http, but we didn't have a plain socket implementation. It wasn't a JVx problem because the server component was ready for socket connections but we didn't have a Socket server. We made some experiments with vert.x and the result was a nice socket server. We also used JVx with vert.x Http server. Both implementations are available on GitHub. It worked like a charm but we didn't like the library dependencies. We already had a socket server API for our product VisionX, but it wasn't decoupled. Now it is!

We used the VisionX socket API and merged it in our applications library. After some modifications and bugfixes, in JVx, it's now possible to use it without additional dependencies. It's a simple socket server for JVx server component. We've used this server to run VisionX and had no problems. VisionX is a huge JVx application and if VisionX works, all other JVx applications will work.

It's very simple to use the the socket server:

The server has a main method and you can use it without additional coding. Simply set the system properties server.hostname, server.port.

To open a connection, simply call:

Not really rocket-science and just works!

The only problem was the server name and port configuration, for every client. Not really cool in a "sensor network". So we started a simple Broadcaster. It's a simple class that checks the network for existing servers. It's easy to use on client-side:

and the server side isn't too complex:

The result contains a list of available hostnames and ports for the first found server. It's still space for a better solution, but I think that's the reason why vert.x uses hazelcast.

To cut a long story short: It's now possible to use complete JVx applications without Java application server, especially on embedded devices like RaspberryPi.

Sure, it's still recommended to use an application server if your device serves web content or a whole web application e.g. with JVx' vaadin UI (see IoT: Window shutter control).

We pushed some of our research projects to GitHub. Our company account currently contains 3 projects:

• jvx.vert.x

  A complete JVx connection implementation for vert.x. It contains a NetSocket and Http Server.

• DropboxStorage

  A storage for accessing Dropbox files and directories. Use it to access Dropbox files from JVx applications.

• flylink

  Flyspray integration for TestLink.
  

We'll use GitHub for smaller projects and finished research projects. Our SourceForge account will be used for all other projects. We do some tests with GitHub and maybe we'll move more projects from time to time.

Today is a great day, because I'm able to write about our latest Research Project.
It has to do with JavaFX and JVx - what else.

If you remember one of my blog postings in 2013, you know that we tried to implement our JVx UI with JavaFX. Long story, short: Not possible with one master thesis.

But... we always try to reach our goals and it's an honor to tell you that we're back on the track.

It's cool because of JavaFX. It's APIs are still not perfect and the overall performance could be better but it has so many awesome things. Two of them are styling via CSS and animations. JavaFX is the official replacement for Swing and it has potential to bring back "write once run anywhere". We don't know if JavaFX will be the holy grail for desktop application development but there's nothing comparable in the Java world.
To be honest, it's not a problem for us because our JVx is (UI) technology independent and if JavaFX won't do it, we'll implement the next UI toolkit for JVx.

... but back to the topic

You should already know that JVx is a Full-stack application framework for building database (ERP) software. It's GUI technology independent and we've different UI implementations. The most important ones are based on Swing and vaadin. We also have native Android and iOS support and our applications run on embedded devices as well. Our applications don't need an application server to work properly because we have a plain socket server as well (IoT ready).

Our preferred Java UI technology was and is still Swing, because it's feature rich and you can build every kind of application without bigger problems. The problem with swing is that it's old and not maintained from Oracle. Sure it will work with future Java releases without bigger problems (hopefully) but you can't use modern development techniques or create fancy and fresh UIs with less effort. A standard Swing application looks boring and cold. Sure, it's possible to pimp a swing application with lots of pictures or nice looking LaFs, but it's not fun.

Swing development is like software development in the stone-age, compared to state-of-the-art web development. If you do web development, you have CSS3 and HTML5 and some nice designed UI frameworks. I won't say that you're faster or that web development is better but it's easier to build nice looking UIs. I'm not a big fan of classical web development because most applications are horrible to maintain, there are soo many different frameworks and you can't be sure that your investment is future-proof because many frameworks don't survive the first year. But everything depends on knowledge and the right framework - for sure.

IMO it's better to use one framework that solves most of application relevant problems - if it exists. If we talk about web applications, I recommend vaadin because it's feature rich, just works, is very polished and is licensed under Apache 2.0. The community is active and great support is available!
Sure, there are some other frameworks like GXT or extJS from Sencha, but the license could be a problem if you build commercial applications. Don't forget RAP, but it's not trivial to start with the whole Eclipse ecosystem.

I'm talking about (enterprise) application development and not about webpage or webservice development. I would recommend pure HTML5 and CSS3 with one or two smaller javascript libs for developing fancy "webpages", or php instead of Java. If Java and "webpages", PrimeFaces is a good decision.

Soo, if Swing is "dead" and web development is hard, what should we use for (enterprise) application development?

If you develop for the desktop, try to start with JavaFX becasue it's maintained and has potential for mobile devices.
If you develop web applications, use vaadin.

And why should you use JVx?

JVx bundles all together in one independent framework (it's still small and easy to learn). You'll be independent of the underlying UI technology. Write your application once and start it with different UI technologies or use it on different devices without problems. Your investment is future-proof. JVx is open source and licensed under Apache 2.0. JVx doesn't hide the underlying technology. It's always possible to use features from the technology if you want. If you use a UI without abstraction, you can't switch to another UI easily without rewriting most parts of the UI. If you start with e.g. JavaFX and if Oracle will abandon JavaFX, will you rewrite the application?

You can compare the concept of JVx with SLF4J, but with a different use-case: (enterprise) application development

And what about JavaFX?

I like JavaFX because of, IMO, 5 great things: scene graph, CSS styling, Animations, Web engine and the community. All other things are important and useful but not essential for real-world applications (vs. Swing). It's not possible to compare Swing with JavaFX because JavaFX was written from scratch and Swing was based on AWT. Sure, both toolkits are UI toolkits but with different concepts.

JavaFX bridges the gap between desktop and web development. It's still a toolkit for desktop applications but with most advantages of web development. It's possible to create fancy applications without headache. There are cool tools like Scene Builder or ScenicView. IDE support is getting better and developing controls is not too hard.

Sounds too good? JavaFX is on the right track and ready for real-world applications.

That was enough for us to start a JavaFX UI for JVx. It's the only framework which allows switching between Swing, Web, JavaFX or native mobile. Sounds unbelievable? Here's is our first video with our JavaFX implementation. It demonstrates the full power of JVx and JavaFX.

The video starts with our good old Swing UI. The same application will be shown as web application in a Chrome browser. And finally it will run as JavaFX application. You should carefully check the JavaFX application because it has an embedded browser that shows the same application, with a different UI technology - at the same time. Don't miss the animations

We had our first contact with vert.x in 2012 as we tried to use it for our first RaspberryPi project. We did a simple implementation of our JVx connection interface and used the Vertx net implementation to run our applications without application server on a RasPi. Our implementation was based on vert.x 1.2. We didn't use our implementation since that time. We re-used the project in the last weeks because vert.x is still alive and we changed some things in our connection to support streaming protocols. It was a great test case for our changes.

First of all, we did an update to vert.x 2.1.5. Our implementation is now up-to-date. We also changed the implementation because it wasn't an optimized solution. We removed our internal buffering and used vert.x core classes. We also created verticles to support the core concept of vert.x.

If you're interested, simply check the source code. There are two test cases: TestNetSocketConnection and TestHttpConnection in the test folder.

You could use the solution to run a JVx application on an embedded device without a Java application server.

But you should know that this project isn't an official project of SIB Visions, and we don't offer support for it. But we try to answer your questions via Forum.

The project is currently located in the JVx repository, but we'll move it to its own repository in next few weeks.

With version 8, Java has received support for lambda expressions and of course also JVx and its users directly profit from this new feature.

In case you do not know what a lambda expression is, it is basically the possibility to inline functions, sometimes also called "anonymous functions" and should not be confused with "anonymous classes", which Java has supported for quite some time now. Let's look at a simple example of anonymous classes:

This launches a thread that does something. The Runnable in our example is the anonymous class. Now with the new lambda support we don't need to write the interface implementation, but can directly tell it to run a function:

The empty parentheses and the arrow indicate a new anonymous function. The parentheses contain the list of parameters of the function that is going to be invoked, in our case it is empty because Runnable.run() does not have any parameters. So the anatomy of a lambda looks like this:

Internally this is still compiled into an anonymous class, but the code becomes a lot smoother and easier to read.

Additionally it is now possible to reference functions directly, like this:

Especially the last possibility is very exciting, as our event system has a very similar mechanism but until recently did not have compile-time safety and checks.

The new lambda feature is backwards compatible and can easily be used in JVx. Here is a simple test window that shows the new lambda expressions in combination with JVx events:

Our last research project was real fun: Build a Webcam with temp and light sensor to do some home/office automation.

We took a RaspberryPi model B, temp sensor (DS18B20) and light sensor (TSL45315).

The temp sensor had a 1-wire interface and the Internet had many tutorials to connect the sensor to a RasPi. It should be a trivial job, if you read the tutorials and it should be ready in max. 10 minutes. Should!

The theory wasn't the reality and the tutorials didn't cover our environment, because we had a new Raspbian ISO with kernel 3.16 and 3.18 some hours later.

We tried to connect the sensor as described (with and without pullup resistor, with parasite power and without) but it wasn't detected. It was horrible because the driver was loaded without problems and logged a simple success message.
We didn't find information about the problem because we didn't see an error. It simply did nothing and the filesystem didn't contain the relevant files and directories. Our /sys/bus/w1/devices directory was clean and empty. After some hours error searching, without any ideas we tried an older Raspbian image with kernel 3.6 and our sensor worked out-of-the-box without modifications. We saw additional log information from the 1-wire module which we didn't have with our 3.18 kernel. So we knew that something has changed in the kernel or kernel config...

But we weren't happy because the whole thing should work with an up-to-date setup. After we knew that the kernel caused our problems, we tried to find a solution and found: http://www.raspberrypi.org/forums/viewtopic.php?t=97216&p=676793 (first posting on 2nd page). There was a hint about the device tree. With this information, we found: https://github.com/raspberrypi/documentation/blob/master/configuration/device-tree.md

We disabled the device-tree by adding device_tree= to our config.txt and everything worked after a reboot, with our 3.18 kernel. So far so good.

It also worked with device_tree_overlay=overlays/w1-gpio-overlay.dtb. This option was our preferred one because it didn't disable the device_tree.

After our temp sensor worked without problems we connected the Raspicam and made some tests. Everything worked without problems. The last piece of our project was the light sensor. It was a littly bit tricky to use the sensor with our Pi because the source code example wasn't available for Java/Pi4J, but here it is:

We compared the output with an Arduino board and the values were "the same".

It wasn't possible to use the light sensor without required modules. We simply added device_tree_param=i2c1=on to our config.txt and I2C worked. You should install

to verify connected sensors, via:

After we thought that everything will work, we put all pieces together: temp sensor, cam, light sensor.
During development, we didn't use all parts together - only the relevant sensor, to rule out errors.

Everything worked fine after starting the Pi, but the cam stopped capturing after some minutes... frustrating.
So again we tried to find an error without detailed information and without logs. We thought it might be a module loading problem and found some hints: https://github.com/raspberrypi/linux/issues/435. But nothing worked for us. The only working solution was: disable the device tree

The whole system is up and running for some days and there we no problems.

We currently don't know what's the problem with the device tree or what we should configure to avoid problems, but if you have similar problems, this posting could help. If you have a working solution with the device tree... leave a comment

I wrote in a previous article about my problems with Jetty and Vaadin push support.

I found the problem in the meantime and Jetty works well on my Raspi. The performance is a little bit better than with Tomcat 8.

What was the problem?

Vaadin 7.1 push implementation was incompatible with Jetty 9.2.6. I had to use Jetty 9.0.7.

I didn't use Jetty as embedded server, it runs standalone via bin/jetty.sh. It was a little bit tricky to add an external lib to the classpatch because the commandline argument changed from 9.0 to 9.2.

I had to add following to my jetty.sh:

With 9.2:

You have to know the pitfalls

It seems that Vaadin' websocket implementation for Jetty is better than for Tomcat because Vaadin handles multiple rotate/resize events faster with less communication. I know that Vaadin 7.3 has a better websocket implementation and it's also up-to-date and should work with Jetty 9.2.6, but I still use Vaadin 7.1.

I recommend Jetty for your embedded project because it's fast and simple. If you prefer Tomcat, you can't do anything wrong.

Oh... I also solved the problem with missing request from / to /index.html. The redirection won't work if you don't have a file with the name index.html in your public web area because Jetty does nothing in that case. I didn't find an option for that, but creating an empty index.html solved my problem because I had a Servlet which was listening on /index.html.

It's not rocket science and we didn't write code, but it's nice to see our UIs on SmartTVs

Here are some impressions:

SmartTV - Statistic		SmartTV - Data
SmartTV - Window Shutter