Official FontAwesome support in JVx

Post to Twitter

We're happy to announce that JVx got "official" (experimental) support for FontAwesome icons. We made some changes to our internal image management but it wasn't a big change and no API was touched!

How it works?

Simple, as usual :)

An example:

UIButton button = new Button("Press me");

But that's not all because we support special things like coloring, e.g.:

UIButton button = new Button("Press me");
button.setImage(UIImage.getImage(IFontAwesome.USER_SMALL + ";color=orange");

and it's also possible to set the size:

UIButton button = new Button("Press me");
button.setImage(UIImage.getImage(IFontAwesome.USER_SMALL + ";size=24;color=orange");

The support was split in different parts. JVx got the IFontAwesome interface which defines FontAwesome icon names. This doesn't mean that every UI implementation supports FontAwesome!

Every UI has to support FontAwesome because it's UI dependent how font icons will be rendered.

We have support in our Swing UI and vaadin UI, but currently we don't have support in our JavaFX UI (not yet). This means, that you can use FontAwesome directly in your JVx application out-of-the-box without manual configuration and without accessing resources directly.

Pure Swing

We have a read-to-use FontAwesome ImageIcon for Swing developers. It's called JVxFontAwesome. It's easy to use this icon in your Swing application, also without JVx UI.


There are some limitations in Vaadin, because it's not possible to add custom style properties to menu items via API calls. It's possibel via css files, but this is a limitation you should know. Sure, it shouldn't be a big problem but vaadin doesn't support this feature right now.

Vaadin up to 7.5.6 has support for FontAwesome 4.1.0 and JVx has support for 4.4.0. Not all icons are available in vaadin UI right now! There's a ticket about an update to 4.4.0.

JavaFX UI, native mobile clients

We didn't implement FontAwesome in JavaFX UI or our Android, iOS clients - not yet. It shouldn't be a big problem to implement the support but we're still in an experimental phase ;)

JVx' vaadinUI supports FontAwesome and VaadinIcons

Post to Twitter

Vaadin has support for FontIcons since release 7.2. The first supported FontIcon was FontAwesome. Vaadin has a nice description in their book.

It's straight forward:


Since June 2015 vaadin also supports their own Font Icons: Vaadin Font Icons.

In our JVx' VaadinUI, it wasn't possible to use FontIcons without accessing the real vaadin resource, e.g.


With next release, we'll allow FontAwesome and VaadinIcons out-of-the-box, without accessing the ressource and without manual installation of font icons, because our UI has everything included.

It will be possible to write:




This feature is not official because it's not technology independent, but it's already available in our nightly builds :)

Eclipse MARS with ANT and JRE 6 (story)

Post to Twitter

Eclipse Mars is available since June 25th. We didn't update our IDEs because it wasn't needed.

Some days ago we played around with JavaFXPorts Eclipse plugin. This plugin requires Eclipse Mars. So far so good. We made some tests with Mars, and everything was fine. We installed all required plugins for our internal and customer projects and configured a first workspace....
After everything was done, we tried to work with Eclipse Mars - no problems... BUT we have many projects with Java 6 compatibility.

Why Java 6?

Some big legacy projects/applications and Oracle Forms compatibility. There are more reasons, but it's not unusual to be backwards compatible, especially for frameworks and libraries!

Long story, short: It's not possible to start an ANT task with Java 6, because Java 7 is required. A nice error message appears:

JRE version less than 1.7 is not supported.

BUT it's still possible to choose any JRE in Runtime configuration dialog.
Why shouldn't it be possible to start ANT with "any" JRE?

We tried to find help in the world wide web and found some postings about our problem:

And two bug database entries:

It's absolutely incomprehensible why the first ticket is in state: RESOLVED INVALID and the
second one: VERIFIED FIXED.
OK, the second one was for a different requirement, but the first one explains the problem.

Why did the developer ignore the user requirement?

It's possible to call ANT with "any" JRE, without Eclipse and other IDEs don't have such crazy limitations! We didn't plan to use another IDE just for building our software!

I can't live with recommended workarounds because suggested steps were not usuable with big projects!
So, we tried to solve the problem for us. The source code of the ANT plugin is available here, so it shouldn't be a problem to "fix" the problem.

After reading source code, we found that the only reason why it's not possible to use JREs < version 7, is Java 7 Syntax:

  • Diamond operator, e.g. List<MyObject> list = new ArrayList<>();
  • try-with-resources, e.g. try (InputStream stream = createInputStream()) { ...}

And of course, the plugin was configured for execution environment JavaSE-1.7.

Our solution: Removed Java version check in class org.eclipse.ant.internal.launching.launchConfigurations.AntLaunchDelegate, method launch:

//String path = configuration.getAttribute(IJavaLaunchConfigurationConstants.ATTR_JRE_CONTAINER_PATH, new String("")); //$NON-NLS-1$
//if (!path.isEmpty()) {
//      IPath jrePath = Path.fromPortableString(path);
//      IVMInstall vm = JavaRuntime.getVMInstall(jrePath);
//      if (vm instanceof AbstractVMInstall) {
//              AbstractVMInstall install = (AbstractVMInstall) vm;
//              String vmver = install.getJavaVersion();
//              // versionToJdkLevel only handles 3 char versions = 1.5, 1.6, 1.9, etc
//              if (vmver.length() > 3) {
//                      vmver = vmver.substring(0, 3);
//              }
//              int ver = (int) (CompilerOptions.versionToJdkLevel(vmver) >>> 16);
//              if (ver < ClassFileConstants.MAJOR_VERSION_1_7) {
//                      // IStatus status = new Status(IStatus.ERROR, AntLaunching.PLUGIN_ID, 1,
//                      // AntLaunchConfigurationMessages.AntLaunchDelegate_Launching__0__2, null);
//                      // throw new CoreException(status);
//              }
//      }

We set the execution environment for org.eclipse.ant.launching, org.eclipse.ant.core and org.eclipse.ant.ui to JavaSE-1.6 and made the source code compatible with Java 6 syntax.

After we built the required jar files, we had problems with Eclipse, because there was something like a plugin cache (not sure what exactly). We made a test with -clean command line parameter and were happy. It was possible to start ANT tasks - with JRE 6 - without modifications, directly via Eclipse.

It's not difficult to create your own ANT plugin, but here are our jar files.
The libs were built for

Version: Mars Release (4.5.0)
Build id: 20150621-1200

The tag-id of the ANT plugin source code: I20150430-1445.


  • Download the zip archive, extract the content to <eclipse_dir>/plugins.
  • Start eclipse with parameter -clean (only once)
  • Configure JRE6 for your ANT task, via Externals Tool configuration...

Feel free to use our changed files but we don't guarantee that it doesn't destroy your Eclipse Mars installation :)
We didn't have any problems so far, but send us your impressions.

We didn't publish the changed source code right now, but let us know if you need it - it's still under EPL.

JavaFXPorts with Eclipse

Post to Twitter

Some weeks ago, Gluon released the first version of their Eclipse plugin for creating/building mobile applications with Java(FX).

We had some experience with their NetBeans plugin but our preferred IDE was Eclipse. So, an Eclipse plugin was good for us :)
The NetBeans version worked without bigger problems and we expected the same quality for the Eclipse plugin.

We followed the official installation instructions and didn't have any problem. But the problems started after we tried to create Android or iOS specific code. It wasn't possible to access javafxports, android or robovm classes, because the jar files weren't found. The classpath with NetBeans had references to all libraries, but the Eclipse project didn't have such references.

We tried to find some information in the documentation and found the NFC example application. The build file had additional dependencies for android and javafxports. We changed the build file of our Eclipse project:

dependencies {
    compile files("C:/tools/android/android-sdk_r04-windows/platforms/android-21/android.jar")
    compile "org.javafxports:jfxdvk:8u60-b3"
    compile fileTree(dir: 'libs', include: '*.jar')
    runtime fileTree(dir: 'libs', include: '*.jar')

and after some Gradle/Refresh Dependencies, Refresh All clicks, all Errors were fixed!
It was horrible, because after clicking Refresh Dependencies, nothing happened and after some more clicks, all errors were gone. Not sure if this was a Gradle project problem, or Gluon plugin problem.

Our full build script (without robovm):

buildscript {
    repositories {
    dependencies {
        classpath 'org.javafxports:jfxmobile-plugin:1.0.1'


apply plugin: 'org.javafxports.jfxmobile'

repositories {

dependencies {
    compile files("C:/tools/android/android-sdk_r04-windows/platforms/android-21/android.jar")
    compile "org.javafxports:jfxdvk:8u60-b3"
    compile fileTree(dir: 'libs', include: '*.jar')
    runtime fileTree(dir: 'libs', include: '*.jar')

mainClassName = ''
jfxmobile {
    ios {
        forceLinkClasses = [ 'com.sibvisions.mobilefx.ios.**.*' ]
    android {
      androidSdk = 'C:/tools/android/android-sdk_r04-windows'
      compileSdkVersion = 21  

  • Enable developer options for your Android device
  • Show log messages from your Android device: \platform-tools\adb logcat

JVxEE 1.2

Post to Twitter

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:

@Entity public class A
    @Id private int id;
    private B source;
    private B target;
    // Getters/Setters

@Entity public class B
    @Id private int id;
    private String name;

    // Getters/Setters

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

ID          BigDecimal
B_ID        BigDecimal
B_NAME      String
B_ID        BigDecimal
B_NAME      String

And with 1.2:

ID          BigDecimal
SOURCE_ID   BigDecimal
TARGET_ID   BigDecimal

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:

@Entity public class Aircraft
    private String country;
    private String description;
    @Id @OneToMany private String registrationNumber;

@Entity public class Airport
    @Id @OneToMany private String code;
    private String country;
    private String location;
    private String name;

@Entity public class Flight
    @OneToOne private Aircraft aircraft;
    private String airline;
    @OneToOne private Airport airportDestination;
    @OneToOne private Airport airportOrigin;
    @Id private String flightNumber;

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:

<?xml version="1.0" encoding="UTF-8" ?>
<persistence xmlns:xsi=""

             version="2.0" xmlns="">

  <persistence-unit name="test" transaction-type="RESOURCE_LOCAL">

      <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
      <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:hsql://localhost/db" />
      <property name="javax.persistence.jdbc.user" value="sa" />
      <property name="javax.persistence.jdbc.password" value="" />

      <property name="eclipselink.ddl-generation" value="drop-and-create-tables" />
      <property name="eclipselink.ddl-generation.output-mode" value="database" />
      <property name="eclipselink.logging.level" value="FINE"/>

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

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

EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("test");
EntityManager entityManager = entityManagerFactory.createEntityManager();

JPAStorage storage = new JPAStorage(Flight.class);

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

Ein GUI für alle Fälle

Post to Twitter

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.

DOAG 2015 - I'm a speaker

Post to Twitter

2015-K_A-Banner-Speaker-180x150-ENGL   I'm a speaker at DOAG 2015 in Nuremberg.
My talk will be about "Mobile applications with JavaFX"

Read more.

I'll show you some really cool things with JVx and JavaFX on mobile devices. Let yourself be surprised.

Create WildFly Swarm applications from existing war files [part 2]

Post to Twitter

My first steps with WildFly swarm were very successful but I didn't solve my problem completely:

I tried to create a self-contained jar (fat jar) file from an existing war file, with minimal effort. The idea was that our product VisionX could create such jar files with some mouse clicks.

This wasn't possible because the project is in a very early phase, ANT wasn't supported and it wasn't planned.

I solved the problem for my use-case and published the result at github.

The project contains an Eclipse project with an ant task and a fully functional ANT build. It has a dependency to ivy, because ivy was used for dependency resolution. Ivy is not needed if you want to work with a copy of all dependencies, e.g. our VisionX will do this.

The code isn't production ready but it works like a charm. The test war file has 56MB and the created jar is around 78MB.

Just play around with the code :)

Create WildFly Swarm applications from existing war files

Post to Twitter

Have you heard about WildFly Swarm?

It's a new sidecar project to WildFly which helps you create self-contained Java microservices based upon the normal WildFly application-server.

Sounds interesting?

We had different use-cases for such a product. Our VisionX creates war files and desktop applications. It would be nice to have a microservice option. Our idea was to create a WildFly Swarm application based on our pre-created war files. Could be useful.

We made some experience with bundeling an embedded Tomcat with our applications because we use this variant for our desktop applications to add browser based help systems. We thought that a replacement of embedded Tomcat could reduce complexity...

The documentation was simple and maven based. The info:

We do aim to add support for other build-systems in the near future.

was nice but the relevant information wasn't available for ANT. We found some gradle tasks, but nothing for ANT - because ANT isn't supported.
What's the problem with maven? We don't like downloading the Internet for simple dependency management. This happened during our first tests with WildFly Swarm. Before we built our first "fat" jar, the "whole JBoss repository" was downloaded.

Test: Phase 1

We tried to follow the documentation and started with a new Maven "war" project. Our application was a simple JVx application with vaadin UI. The application code:

@Widgetset(value = "com.sibvisions.rad.ui.vaadin.ext.ui.Widgetset")
@Configuration({@Parameter(name = "main", value = "com.sibvisions.demos.swarm.EmbeddedApplication$MyApplication")})
public class EmbeddedApplication extends VaadinUI
    @WebServlet(value = {"/minimal/*", "/VAADIN/*"}, asyncSupported = true)
    @VaadinServletConfiguration(productionMode = false, ui = EmbeddedApplication.class)
    public static class Servlet extends VaadinServlet
    }   // Servlet

    public static class MyApplication extends Application
        public MyApplication(UILauncher pLauncher)
            setName("Simple application");

            setLayout(new UIBorderLayout());
            UILabel lblHello = new UILabel("Hello JVx' vaadinUI");
            lblHello.setFont(UIFont.getDefaultFont().deriveFont(UIFont.BOLD, 16));
            //example CSS without custom css file
            ((VaadinLabel)lblHello.getUIResource()).getCssExtension().addAttribute("margin-top", "100px");
            add(lblHello, UIBorderLayout.CENTER);

We found an intro from vaadin about their tests with WildFly Swarm. The last link contains redirects to a github project with many examples and a ready-to-use maven configuration.

But, we had bad luck because no example was working with our setup. The build wasn't a problem, but we got some Exceptions at runtime. We tried to find documentation in the Internet, but we didn't find a solution because the project is in Alpha status and documentation is not yet ready... So we tried to build WildFly Swarm on our own to be able to add debug messages.

After a long maven fight (once again) everything was working. We had some problems with JDK 8 and Eclipse Kepler because Kepler didn't support JDK8 without a Patch and bundled maven was too old. Latest maven didn't work with Eclipse but 3.2.1 was working...
WildFly Swarm test artifacts didn't work without problems and we had to fix some autoboxing errors (because of our custom compiler settings). Horrible but we won the fight!

The problem with our "fat" jar was that two dependencies were missing or weren't resolved correctly. After we manually set two more dependencies:


our "fat" jar was working without problems.

BUT... the jar had about 100 MB! Our war file had about 40MB. The overhead was about 60MB - WTF?
Our applications with embedded Tomcat had an overhead of 4MB.

The problem was/is that all maven dependencies were added to the war and the jar file. It was handled by the swarm-plugin and the issue #107 explains the problem.

After one day! we had a working Hello world example as Maven project. Sure, we built our own WildFly Swarm version too.

Test: Phase 2

The Maven project was working and maven built a war for our sources and bundled all dependencies for us, but what about existing war files? Our initial plan was the creation of WildFly Swarm applications for existing war files. This wasn't possible without hacking because it wasn't implemented... for us.

I told you that we built our own WildFly Swarm version and also the swarm-plugin. The plugin had a PackageMojo class. This mojo had enough documentation (= source code) for us, to create a simple test case for our use-case.

The test class is about 100 LoC with minimal logic but it's tricky. The relevant calls:

BuildTool tool = new BuildTool();

for (File jar : findMinimalDependencies())
  //read groupid, artifactid, version from jar

  tool.dependency("compile", sGroupId, sArtifactId, sVersion, "jar", null, jar);

tool.artifactResolvingHelper(new Resolver(tool));
tool.projectArtifact("com.sibvisions.demos", "swarm", "0.2-SNAPSHOT", "war", war);"swarm-0.2-SNAPSHOT", target);

The Resolver was a simply code copy of BuildTool findArtifact method:

public class Resolver implements ArtifactResolvingHelper
    private BuildTool tool;
    public Resolver(BuildTool pTool)
        tool = pTool;

    public ArtifactSpec resolve(ArtifactSpec pSpec) throws Exception
        for (ArtifactSpec each : tool.dependencies())
            if (each.file == null) {
            if (pSpec.artifactId != null && !pSpec.artifactId.equals(each.artifactId)) {

            if (pSpec.version != null && !pSpec.version.equals(each.version)) {

            if (pSpec.packaging != null && !pSpec.packaging.equals(each.packaging)) {

            if (pSpec.classifier != null && !pSpec.classifier.equals(each.classifier)) {

            return each;

        return null;

(Sure, not the best solution - but it was good enough for our tests)

With our test class, it was possible to create a WildFly Swarm application for an existing war file, without problems and without maven. And the best: The "fat" jar file had about 83MB and the original war file was about 60MB. The overhead was 23MB, but awesome for a basic WildFly installation.

The example project of Phase 1 is available on github.


WildFly Swarm is a nice product but it's not ready-to-use. If you have time to play around with it, just do it because it creates a back to the roots feeling - back to hacking. The "fat" jars are a nice idea, but microservice is just a buzzword.

WildFly is not comparable to embedded Tomcat, but if you need a simple application server for your servlets, an embedded Tomcat or Jetty are good enough. We won't replace our embedded Tomcat with WildFly Swarm because we misunderstood the concept and both products are for different use-cases.... but a new export Option for VisionX should be possible!

JVx' Vaadin UI 1.3 is available

Post to Twitter

The next release of our JVx' vaadin UI is available. It's not a big update but an important one because vaadin was updated to 7.5.0 and we support CORS out-of-the-box. We also have some annotations for easier application deployment.

The best thing for most of you is that starting with 1.3 our vaadin UI can be found on maven central.

Simply add the dependency:


We also upload snaphsots of vaadin UI, starting with current 1.4 branch
Simply configure the repository:

    <name>Sonatype Snapshots</name>  

and use following dependency:


The release files are also available on SourceForge.

The complete Changelog.