Category: News

Maven central: JVx.web snapshots

Post to Twitter

Our JVx headless UI (aka JVx.web) implementation is available as maven snapshot:

<dependency>  
  <groupId>com.sibvisions.web</groupId>    
  <artifactId>headless</artifactId>  
  <version>1.2-SNAPSHOT</version>
</dependency>

Don't forget the snapshot repository:

<repository>  
  <id>sonatype-nexus-snapshots</id>    
  <name>Sonatype Snapshots</name>  
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>

Maven central: JVx.mobile snapshots

Post to Twitter

Our JVx mobile project is available as maven snapshot:

<dependency>  
  <groupId>com.sibvisions.mobile</groupId>    
  <artifactId>mobile-server</artifactId>  
  <version>1.0.1-SNAPSHOT</version>
</dependency>

and only the API

<dependency>  
  <groupId>com.sibvisions.mobile</groupId>    
  <artifactId>mobile-api</artifactId>  
  <version>1.0.1-SNAPSHOT</version>
</dependency>

Don't forget the snapshot repository:

<repository>  
  <id>sonatype-nexus-snapshots</id>    
  <name>Sonatype Snapshots</name>  
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>

Maven central: JavaFX UI snapshots

Post to Twitter

Our JavaFX UI for JVx is available as maven snapshot:

<dependency>  
  <groupId>com.sibvisions.jvx</groupId>    
  <artifactId>jvxfx</artifactId>  
  <version>1.2-SNAPSHOT</version>
</dependency>

or only JavaFX extensions

<dependency>  
  <groupId>com.sibvisions.jvx</groupId>    
  <artifactId>jfxtensions</artifactId>  
  <version>1.2-SNAPSHOT</version>
</dependency>

and don't forget the snapshot repository:

<repository>  
  <id>sonatype-nexus-snapshots</id>    
  <name>Sonatype Snapshots</name>  
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>

Maven central: Online Help System

Post to Twitter

Our JVx online help system is available as maven artifact:

<dependency>  
  <groupId>com.sibvisions.help</groupId>    
  <artifactId>help-server</artifactId>  
  <version>1.1</version>
</dependency>
<dependency>  
  <groupId>com.sibvisions.help</groupId>    
  <artifactId>help-themes</artifactId>  
  <version>1.1</version>
</dependency>

and as snapshot (weekly):

<dependency>  
  <groupId>com.sibvisions.help</groupId>    
  <artifactId>help-server</artifactId>  
  <version>1.2-SNAPSHOT</version>
</dependency>
<dependency>  
  <groupId>com.sibvisions.help</groupId>    
  <artifactId>help-themes</artifactId>  
  <version>1.2-SNAPSHOT</version>
</dependency>
<repository>  
  <id>sonatype-nexus-snapshots</id>    
  <name>Sonatype Snapshots</name>  
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>

JVx 2.5 - summer release

Post to Twitter

The next JVx release will be version 2.5. It will be available by the end of this week (beginning of July). It's a really cool release because JVx got awesome new features. We had to change the API a little bit but it shouldn't be a problem for your existing applications.

What will be interesting?

  • Push-light

    Our push support has nothing to do with Websockets. It's a technology independent solution for JVx. The Push-light mechanism is available on server-side and enables you to send objects from the server to the client. If you use a direct connection betwenn client and server, the objects wil be sent immediate (e.g. vaadin UI). If you use a serialized connection, the objects will be sent with next client call or alive check.

    The API is simple:

    SessionContext.publishCallBackResult("MESSAGE", "Please logout!");

    or, in a Thread

    final ICallBackBroker broker = SessionContext.getCurrentInstance().getCallBackBroker();

    Thread th = new Thread(new Runnable()
    {
        public void run()
        {
            try
            {
                int i = 0;

                while (isMessageLoopEnabled(i))
                {
                    Thread.sleep(200);
                   
                    broker.publish("MESSAGE", getMessage(i++));
                }
            }
            catch (InterruptedException ie)
            {
                //done
            }
        }
    });
    th.start();

    It's also possible to publish to all clients, via ICallBackBroker.

    The client code is short and simple:

    connection.addCallBackResultListener(new ICallBackResultListener()
    {
        public void callBackResult(CallBackResultEvent pEvent)
        {
            if ("MESSAGE".equals(pEvent.getInstruction()))
            {
                showMessage((String)pEvent.getObject());
            }
        }
    });

    More details: Tickets #25, #1635

  • H2 DB support

    We support H2 with a custom H2DBAccess. The auto detection works with URLs: jdbc:h2:.

  • SQLite DB support

    We support SQLite with a custom SQLiteDBAccess. The auto detection works with URLs: jdbc:sqlite:.

  • MySql limit support

    Read more...

  • Life-cylcle object method inheritance
  • Pie control
  • Set individual cells of a table readonly
  • Connection retries

    We try to re-send requests, if errors occur during transmission. This feature will be available for serialized connections only.

  • Security improvements

    see Tickets: #1605, #1606, #630.

  • API changes

    ICellFormat got a Style attribute and the createCellFormat of IFactory got one more parameter

IT-Tage 2016 - I'm speaker

Post to Twitter

Logo-itt2016-Web   I'm a speaker at IT-Tage 2016 in Frankfurt - December, 14th.
My talk will be about "JVx – Zurück zur Effizienz! "

Read more.

The full time table.

EPlug 1.2.4 is available

Post to Twitter

Our Eclipse plugin for JVx and VisionX is available as version 1.2.4.
It's a small bugfix release.

Changes

  • Proxy support (tests)

    Some customers had problems with http(s) proxies and our trial activation. We made extended tests with (win/linux) proxies and didn't find any problems. We reduced the communication timeout because it was too long. Please send us your feedback.

  • Additional checks for client/server code mixing

    It might be a problem if you use a server class (src.server) in your client classes (src.client). This depends on the deployment mode (Web, Desktop, ...), but it's better to separate client and server code. The new check can be dis/enabled but it checks by default if your client has direct server references.

  • Using Metadata independent of AbstractCachedStorage

    It's now possible to use column name autocompletion, even if the storage isn't an instance of "AbstractCachedStorage".

Simply update EPlug via Eclipse or jump to the info page.

New VisionX Feature (maybe)

Post to Twitter

We tried to improve the UX of our tool VisionX in the last weeks. The current concept is wizard based and all wizards are kept very simple. This concept works well but requires curiosity. It would be better go guide the user through the application and show the features.

Some software tools use strict guides and explain the application with step-by-step instructions. This is nice but also boring because you can't play around. We tried to add a sort of a guide but without restrictions.

The first preview of this new concept is available as YouTube video. We're not sure if this solution will be available in the next release but our testers love it. It fills the gap between wizards and the question: What should I do next?

Here's the screencast:

New Feature: app guides

JVx and Java 8, Better Lambda support in 2.4

Post to Twitter

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:

private void initializeUI()
{
    button.eventAction().addListener(new UIActionListener() { ... });
    button.eventAction().addListener(this, "doActionA");
    button.eventAction().addListener(this, "doActionB");
    button.eventAction().addListener(this, "doActionC");
    button.eventAction().addListener(this, "doActionD");
}

public void doActionA()
{
    // A simple method with no parameters.
}

public void doActionB() throws Exception
{
    // A simple method which can throw *any* exception.
}

public void doActionC(UIActionEvent pActionEvent)
{
    // A method with the correct signature.
}

public void doActionD(UIActionEvent pActionEvent) throws Exception
{
    // A method with the correct signature which can throw *any* exception.
}

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:

private void initializeUI()
{
    button.eventAction().addListener(this::doActionA);
}

private void doActionA(UIActionEvent pActionEvent) throws Exception
{
    // The correct implementation.
}

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.

private void initializeUI()
{
    button.eventAction().addListener(new UIActionListener() { ... });
    button.eventAction().addListener(this::doActionA);
    button.eventAction().addListener(this::doActionB);
    button.eventAction().addListener(this::doActionC);
    button.eventAction().addListener(this::doActionD);
}

private void doActionA()
{
    // A simple method with no parameters.
}

private void doActionB() throws Exception
{
    // A simple method which can throw *any* exception.
}

private void doActionC(UIActionEvent pActionEvent)
{
    // A method with the correct signature.
}

private void doActionD(UIActionEvent pActionEvent) throws Exception
{
    // A method with the correct signature which can throw *any* exception.
}

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.

The future of JavaFX?

Post to Twitter

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:

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.