This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

Oracle Forms (FMB) to Java conversion

If you're an Oracle Forms user and think about a different technology for your applications, watch following screen cast. It shows how we use VisionX to migrate FMB (windows) to Java, in seconds. Simply watch 90 seconds and it's done :)

JVx Application Stack

Another use-case is the integration of a Java screen, directly in your Oracle Forms application. See our solution in action:

JVx Application Stack

The first video shows our record navigion similar to Oracle Forms and of course, we have a solution for Forms' Enter query mode.

VisionX Update 2.0.121

Great news for all VisionX users!

The current update release 2.0.121 is available for download. Please check your download area.

The release is more than just an update release. It contains all currently available features. We wrote about some of them:

Repeating frames
IDE integration
QR Codes
Features for developers
Ready made solutions

It contains current JVx, ProjX libraries and source code.

If you miss some features after upgrading, please contact our product support because previous versions provided features without valid license. If the features are already licensed, no worries.

We have a product and feature overview for you.

Repeating frames - Oracle Forms related feature

We have a really cool new feature for you. It's comparable to repeating frames of Oracle Forms. It's more or less a free-form table. Every row is a panel with custom components and every row shows the same components but bound to our DataBook.

A short video will demonstrate how it works:

JVx Application Stack

We use the name ComponentTable for the control. It'll be available in one of the next VisionX nightly builds but will be limited to our OracleForms license option.

Master Thesis - JVx Mobile und iOS

Die Master Thesis von Stefan Fessler steht nun öffentlich zur Verfügung. Das Thema war

Design und Implementierung einer Multi-Touch optimierten iOS App für das JVx ERP Applikation Framework

Im Zuge seiner Arbeit wurde der iOS Client für JVx entwickelt. Das Projekt steht unter der Apache Lizenz 2.0 zur Verfügung.

Die Arbeit ist zugleich eine gute Dokumentation und erklärt Designentscheidungen sowie deren Umsetzung.

Master Thesis - JVx Mobile und Android

Die Master Thesis von Michael Hofer steht nun öffentlich zur Verfügung. Das Thema war

Design und Implementierung einer Multi-Touch optimierten Android Runtime Umgebung für JVx ERP Applikationen auf Smartphone Devices

Im Zuge seiner Arbeit wurde der JVx.Mobile Server und der Android Client für JVx entwickelt. Das Projekt steht unter der Apache Lizenz 2.0 zur Verfügung.

Die Arbeit ist zugleich eine gute Dokumentation für und erklärt Designentscheidungen sowie deren Umsetzung.

VisionX RnD news - IDE integration

We want to tell you some fantastic news from our RnD team: The next big step for VisionX will be an IDE integration feature.

Our team is working very hard to reach the goals. The result will be an Eclipse plugin that connects to VisionX and allows bidirectional communication. We won't embedd VisionX in Eclipse because it makes no sense for us, but we'll use the whole power of the IDE.

What will be supported?

  • Event links (Eclipse)

    A click on an event action string will jump to the right method.

    databook.eventValuesChanged().addListener(this, "doValuesChanged");

    The click on doValuesChanged will jump to the method in the work-screen.

  • Call links (Eclipse)

    A click on an action/object call will jump to the right method, in the right life-cycle object.


    The click on getLicenseInformation will jump to the method in the life-cycle object.

  • DataBook links (Eclipse)

    A click on the name of a databook will jump to the storage definition, in the life-cycle object.

    RemoteDataBook rdb = new RemoteDataBook();

    The click on users will jump to the DBStorage definition, in the the life-cycle object.

  • Auto completion (Eclipse)

    We'll offer auto completion for table columns, event methods, action/object calls, ...


    It'll be possible to get a list of all available columns, like DESCRIPTION.

  • Column checks (Eclipse)

    We'll check if all column names are valid and will show compiler warnings/errors.

  • Jump to Eclipse

    It'll be possible, with VisionX, to jump to the source code of e.g. actions, component definitions or databooks in Eclipse. We'll introduce some new Buttons in VisionX, for that feature.

    VisionX E-Plug

    VisionX E-Plug

  • Jump to VisionX

    It'll be possible, with Eclipse, to highlight selected GUI components directly in VisionX.

No worries, we have more features for you!

The IDE integration will be available as optional VisionX module.

VisionX feature - QR code generation

We have a new feature for you!

It's an API to generate QR codes. The API is available in ProjX and you can easily create custom Contact, Phone number, Text, E-Mail and Geo Location QR codes.

We've some new actions for QR code generation in VisionX to easily use the new API.

It's a cool new feature and we've a new example application in our Solution store, but be careful because you need VisionX 2.0.85, or newer, for this feature.

Here's a screenshot from the application:

QR code generation

QR code generation

Create your own QR codes in seconds!

JVx' VaadinUI and Liferay "self-contained" packages

If you are Liferay User and Vaadin Portlet developer, you know that Liferay has Vaadin bundled. If you develop a Vaadin portlet, you should use the bundled Vaadin version, otherwise it'll be a problem after a deployment.

We solved the problem in JVx' VaadinUI by extending Vaadin. Our implementation allows different Vaadin versions independent of Liferay. Some days ago, Matti Tahvonen posted an article about Using "self-contained" approach to package Vaadin portlets. This is an interesting article because it's exactly what we tried to do :) and we thought that Vaadin developers have a better solution for the problem!

And of course, their solution is better than ours :) But we are like copy cats and we changed our solution because it reduced code and made it easier for us to maintain our codebase. Our idea was not far away from the recommended solution, but we did too much.

To find out what Vaadin did in their archetype, we followed their posted instructions. We found two steps that could be ignored. The first step was the creation of a custom maven profile because it was possible to add all properties to the pom.xml of the project. The second step was the configuration of the profile in Eclipse. Not needed if properties were added to pom.xml.

And after creating the project, we had the recommended solution and it was absoutely trivial. Simply extend VaadinPortlet, extend VaadinPortletService and override getStaticFileLocation. The created source code:

public class CustomVaadinPortlet extends VaadinPortlet {

private static final long serialVersionUID = -13615405654173335L;

private class CustomVaadinPortletService extends VaadinPortletService {


    private static final long serialVersionUID = -6282242585931296999L;

    public CustomVaadinPortletService(final VaadinPortlet portlet,
            final DeploymentConfiguration config) throws ServiceException {
        super(portlet, config);
     * This method is used to determine the uri for Vaadin resources like theme
     * or widgetset. It's overriden to point to this web application context,
     * instead of ROOT context

    public String getStaticFileLocation(final VaadinRequest request) {
        return request.getContextPath();


protected VaadinPortletService createPortletService(
        final DeploymentConfiguration deploymentConfiguration)
        throws ServiceException {
    final CustomVaadinPortletService customVaadinPortletService = new CustomVaadinPortletService(
            this, deploymentConfiguration);
    return customVaadinPortletService;


To be honest... our solution contained a little bit more code but it worked. We've used our new knowledge to improve our solution, because it should be possible to use "self-contained" and "shared" approach without additional source code. We introduced a context parameter to switch between modes. Vaadin could do the same, but currently it's not implemented.

Our new solution is as simple as the original Vaadin source code and the most important thing is that it works with our ant build.

Maven omg

It was a very simple task. The library Twitter4j (4.0.1) was compiled for Java 6 and I need a 1.5 compatible version. So, I thought it shouldn't be a problem to compile the project with 1.5 compatibility :)
Twitter4j is available via git and after cloning and switching to 4.0.1 everything was available. I tried to import the maven project with Eclipse (Kepler) and got many problems because of missing libraries. WTF?

Shouldn't maven solve all dependency problems? I didn't try to fix problems with Eclipse because it could be a maven plugin problem. So I tried maven itself with jdk 1.5 and some minutes later I got other exceptions because Twitter4j source was written with Java 6 syntax (@Override with interface methods).
So I had to use Java 6 with 1.5 target option... After modifying pom.xml of twitter4j-core, the build had another problem: All test cases failed :) . So I had to use the command-line property -Dmaven.test.skip=true to ignore unit tests.

Finally I got my 1.5 compatible Twitter4j library.

But it was an awful task because maven bundled with Eclipse didn't work as expected. It's horrible if tools that should save time, waste time. I still don't like maven. IMHO it's still to complex compared to other build tools.
A build tool shouldn't be as complex as developing software.

Nowadays everything has to work with our IDEs, but what happens if it doesn't?

I'm a researcher and love solving problems but is it that complex to keep things simple?
Software has to be simple to help us and we - developers - have to write simple software/frameworks/libraries.

Instead of creating simple software, many developers try to write millions LoC. Don't do that because no one can handle such code-bases in the future.

Just sayin'