Download the new version from the project page.
Our showcase is up to date and all features are available. Login as admin (password.equals(username)).

Some impressions

• Mandatory/readonly coloring

  The WebUI shows mandatory and readonly fields with different background colors, in Editors:

  WebUI 0.7

  WebUI 0.8 beta-1

  and Tables:
  

  WebUI 0.7

  WebUI 0.8 beta-1

• A modest mask

  With WebUI 0.7 we had this big loading bar, centered over the whole application. That was not very stylish. Now we have a small reload image.

  WebUI 0.7

  WebUI 0.8 beta-1

• Show file handles (external content)

  With the Swing UI it is possible to open files and URLs. Now this is possible with WebUI:

  WebUI FileHandle

Check the Changelog for a complete list.

It is available from the project page.

What’s different?

We fixed a lot of problems and refactored the code where needed. But we have fantastic new features in this release:

• Server-side MetaData Caching

  The MetaData detection is an expensive operation. It takes a lot of time to detect them and it slows down your UI. We already have a client meta-data cache which reduces remote calls between client and server. This feature was a first perfomance boost but to keep the meta data up-to-date we had to detect them on the server-side continuously. While you develop an application this loss of time is not a problem because you change a lot and need all up-to-date. But after you installed the app in the customers infrastructure, it is unusual that meta data will be changed without deployment. The app should be as fast as possible. Exactly for that use-case we have the new server option:

  <globalmetadatacache>OFF</globalmetadatacache>

  Add this option to your config.xml in your server directory and set the value from OFF to ON (we recommend to set this option with your build system). The performance improvement is unbelievable - try it out

  With this new option, you only loose performance if your Views or database access are slow.

• Automatic link editor visibility

  We set all automatic link editors invisible if the same columns are used in a MasterReference. If you want them visible, use the following method of your RemoteDataBook instance:

  setAutoLinkInvisibleForMasterReferences(boolean);

  The editors are useful if you want to move a detail row to another master row. Thats not the default case and we think they are not very important.

• Save an UIImage

  We changed our IImage interface from:

  saveAs(String pPath)

  to

  saveAs(OutputStream pOut, ImageType pType)

  The old API tried to forward image data directly to files, but that was a bad design for Applets because unsigned applets have no access to files (not true for JNLP services). Now it is possible to save images of your whole application or single components by calling:

  comp.capture(size).saveAs(stream, type);
• Configuration changes

  When you create a new MasterConnection, the server reads your config.xml and caches the settings for the whole session. The session does not update its cache, but it is still possible to change the file in your filesystem! When you close your connection and open it again, you will get the new configuration! You do not have to restart the whole application or the context of your application server.

• Advanced exceptions

  Some client operations calls more than one server object e.g. if you call saveAllDataBooks() of a Data source. If one of your data books throws an exception, you don't know which one, because the exception does not know the name of your member. It is possible to throw specific exceptions which contains the configured remote-name or other information, but what if you forget to do this?

  Now the remote server adds an extra line to your stack trace:

  at com.sibvisions.util.Reflective.call(Reflective.java:277)
  at com.sibvisions.app.Session.<dataSources>.insert(Unknown Source)
  at com.sibvisions.rad.server.DefaultObjectProvider.invoke(DefaultObjectProvider...)

  After the Object Provider invokes the configured object, you find out which life-cycle object (com.sibvisions.app.Session), which object (dataSources) and which method (insert) throwed the exception.
  Now your debug nightmares are gone!

Check the Changelog for a complete list, and use the forum to talk to us

The last beta of JVx 0.9 will be available on Friday. We have some really cool improvements in it. I think the most impressive one is the performance improvement up to 60% for meta data handling. The meta data detection takes a lot of time because of the database access, but with the new (dynamic) meta data cache mechanism this delay is gone!

Together with the 0.9 beta-4, we release the first beta of JVx WebUI 0.8. It is significantly faster and supports a lot of new properties defined by the UI.

We have invested much time and energy and look forward to the publication

It took some time, but now our application is available.

We did not change the original source code, so the installation contains our result after ~ 25 hours of work. The application is available as WebUI (html/ajax) application and as RIA (Applet). I think we were the only team with "two" frontends.

But after some good news we have a package with bad news: Most of our REST services do not work because we damaged the whole interface during our last deployment, so we are not happy with that. And last but not least, our start html for the RIA stuff is not correct. Time pressure is a killer

Where were the problems?

It was not an enormous amount of time available, but it was absolutely possible to implement all MUSTs and most SHOULDs of the specification. For the MAYs it was not enough time.

Our biggest problem was the REST integration, because we did not have any support in JVx. We decided to implement a generic REST interface based on RESTlet. We knew that the decision is a high risk because it is easier to implement the REST service without regard to JVx. But we wanted to use the result as part of the framework. We were doing well but some problems with the authentication took more time as calculated and so we had big problems towards the end. We knew that the REST services are very important for the analysis phase by the jury, but it was not possible to fix all problems before the packaging phase. And it was better to deliver our work instead of fixing and not to deliver.
In summary: missing framework support and not enough experience with REST.

The frontend/database parts were straight forward, because JVx has powerful features. We developed with our Swing UI implementation and after we finished a task, we have tested with our Web UI implementation. Of course the Web UI had some limits and smaller problems, but we changed some smaller parts to meet the requirements.
In summary: worked great.

The look and feel of the result was not important, either for us nor for the specification, and we did not check the usability. It was important for us that we have a quick access to all controls. And of course, we normally don't create web portals with JVx. It was designed to develop business (database) applications, but we had surprisingly few problems.

What about unit tests and code quality?

Most tests were manual tests because we did not have a lot of complex workflows and we had not enough time for TDD. Of course, we used JUnit for the REST services and for iCalendar creation, but thats all (best not to start EMMA because our test coverage is holey). On the other side, we produced a perfect source code documentation because our checkstyle config did not tolerate any mistakes.
In summary: With the quality we are satisfied.

Team organization?

Martin handled the whole database stuff, most of the User Interface and all workflows
Roland was in a REST "loop"
René took the rest of the User Interface, Business logic, managed the Team, Deployment, Testing and WebUI fixes

We had no problems to work together, it is always easy if you know each other.

Resume

The result could have been better, but even worse - we have our lessons learned.
We had a lot of fun, a perfect organization team and two days of pure adrenalin paired with motivation.

Jetty for Android devices: http://code.google.com/p/i-jetty/

With this implementation it should not be a problem to run the JVx server via http(s) on Android devices. Of course, it is possible to run JVx as DirectServer, but why not via http?
We have not test JVx with i-jetty, but contact us if you want to try it.

In der aktuellen Ausgabe von Java Aktuell ist der Artikel Single Sourcing mit JVx enthalten. Darin wird anhand eines kurzen Beispiels erklärt, wie der Single Sourcing Mechanismus in JVx umgesetzt wurde. Die Beispiel Anwendung wird als Desktop Anwendung bzw. Web Anwendung gestartet, und das ohne auch nur eine Zeile Source Code zu verändern.

Der Artikel zum Nachlesen: Single Sourcing mit JVx, Java Aktuell Q1-2011

Das Magazin, Java Aktuell, erscheint vierteljährlich und wird vom Interessensverbund der Java User Groups e.V (iJUG) herausgegeben.

JVM technologies for 2011 - Voting

Very interesting postings, and yes - JVx is ready for Desktop Applications