JVx 2.8.5 is out and we have some Source Code statistics for you!

Our last statistics were determined for JVx 2.2. The source code grew by 50.012 lines, since 2.2. We now have 178.896 (JVx library, Swing UI, tests) compared to 128.884 in JVx 2.2. Still awesome if we compare the features of JVx with any other application framework!

Here are the actual numbers for you:

Some additional numbers:

Files and Tests

JVx library source files   825 Swing UI source files   148 Test source files   151 Total   1124

Still a small codebase and still very easy to maintain. Here are more numbers, about testing:

Unit tests (no UI, without manual perf. tests)   1000 Class coverage (without UI)   73% Method coverage (without UI)   62%

Our coverage is not as good as with 2.2 but still not bad.

TOP 10 classes

This are interesting numbers because in JVx 2.2, MemDataBook was on 1st place. We now have more code for database support than before. The newcomers are SimpleJavaSource and PostgreSQLDBAccess.

We tried to reduce complexity of DBAccess and MemDataBook, but complex things are complex. This is why we develop JVx. It makes complex things, simple.

The development phase of JVx 3.0 has started. We'll change some things which are important to know:

JVx 3.0 won't be Java 6 compatible. We'll switch to Java 8 and... still super backwards compatible.

We'll also change some package names like javax.rad. But we don't have a complete list right now.
So keep reading.

We're happy to announce that JVx 2.8.5 is available. It's a bigger bugfix release and comes with many powerful new features.

What's new?

• Loading MetaData performance tuning
• REST

  It's now possible to register custom admin services and to disable general admin services. We also introduced a public zone.

• E-Mail support

  Simply send an email with pre-configured server settings.

• Dynamic cell editors

  Set the dynamic cell editor on one cell and use different cell editors in the same cell, based on a type configuration.

• Simple Map implementation

  OpenStreetMap and Google

• Accessible/Not Accessible per environment
• putObject support for DataRow
• Better logging API configuration
• Many more...

The full changelog is available here.

Start with JVx

No worries about CVE-2021-44228.

We have support in JVx for different logging libraries, but use Java logging API per default.
Our product VisionX doesn't use log4j(2) and the log4j2 jar file is not included.

So if you're using VisionX, you won't have any problems.
If you're using JVx without log4j2, also no problems.
If you're using JVx and log4j2, be sure to use one of the latest jdks and you won't have any problems. Also an update to latest log4j2 is recommended.

We are happy to announce that our EPlug 1.2.43 is out.

EPlug is our Eclipse plugin for JVx applications and also for our low-code platform VisionX.

The main improvements were a complete redesign and a big performance tuning.
For sure, we have some great new features like:

• Support for ColumnViews
• Support for MasterReferences
• Support for SortDefinitions
• Support for new Var(...)
• Metadata cache improvements
• Avoid compile Errors when columns cannot be checked
• Show element in tree (one click)
• Bugfixes

Feel free to try out our new version and send us your feedback.

-> Eclipse Marketplace

Es gibt seit kurzem einen neuen Artikel über unsere brandneue Flutter App in der deutschen Presse. Hier das Intro:

Wer eine App für mobile Geräte entwickeln möchte, steht zumindest vor einer wichtigen Frage: Mit welcher Technologie soll die App realisiert werden? Da es aktuell verschiedenste Möglichkeiten gibt, ist die Antwort nicht sofort klar. Mit diesem Problem war das Framework-Team von SIB Visions ebenfalls konfrontiert, als es darum ging, einen Client für das Open Source Application Framework JVx zu entwickeln. Wie
vor allem was umgesetzt wurde, wird ...

Der vollständige Artikel ist hier zu finden. Prädikat lesenswert

We're happy to announce that JVx 2.8 is available. It's a big release with lots of important bug fixes and some awesome new features. The last release of JVx was in January. It was version 2.7 which was more or less a small bugfix release with few new features. We took more time for JVx 2.8 to make it awesome.

What's new?

• Placeholder/Prompt support

  This feature is available for input fields and cell editors. Simply enable this feature:

  editor.setPlaceholderVisible(true);
  editor.setPlaceholder("PLACEHOLDER");

  to get
  

  

  Prompt support

• New popup menu button

  This new button reduces the visible components. It's a must have for modern applications:

  

  Menu button

• Savepoints for transaction handling in PostgreSql
• Components have a unique name

  This is an important feature fore UI tests and our headless UI as well. It's now possible to address components in vaadin UI by their id to apply custom css.

• Configurable REST services
• Mac OS UI improvements

The full changelog is available here.

Start with JVx

Our generic REST interface in JVx is well documented and different examples for different technologies are available. The generic approach itself is smart but not super specific because the implementation follows the CoC paradigm. It's awesome for "REST out-of-the-box" without additional coding effort, but the flexibility is sometimes missing.

We tried to break some of this restrictions and get more flexibility. Here is a list of new features to explain some details:

• Fetch on demand

  The old implementation always returned all records from the database. It wasn't possible to implement paging or lazy loading. To solve this problem, we introduced new request parameters:

  _firstRow
  _maxRows

  With _firstRow (starts from 0) you define the start record number. The _maxRows defines the amount of records for the resultset, e.g. start from 0 and return max. 20 records, start from 20 and return 20 records

• Configure visible columns

  The old implementation returned the same column list for the REST call and the GUI/frontend. But sometimes the REST call should return a different list of columns because some internal columns aren't relevant or should be hidden. The new implementation got a new property in the metadata object: visibleColumnNames. If you set this property, the REST interface will return only the configure columns. The GUI won't recognize the new property because GUI controls have own visible column properties.

• Actions with Array parameters

  The old implementation didn't support simple Arrays like BigDecimal[] as parameter types for action calls. Only List was supported. The new implementation supports Arrays but it's not possible to mix Array and List parameters. An example:

  //valid
  public String createPerson(String[] name, String[] title)
  //valid
  public String createPerson(List<String> name, List<String> title)
  //invalid
  public String createPerson(String[] name, List<String> title)
• New admin zone

  We introduced a new admin zone for generic admin options. The URLs are:

  http://.../services/rest/APPLICATION_NAME/_admin/ACTION_NAME
  http://.../services/rest/APPLICATION_NAME/_admin/ACTION_NAME/ACTION_PARAM

  Currently, we support following actions (POST requests): changePassword, testAuthentication

  The request needs a JSON object with username, oldpassword, newpassword or password properties.

• Configurable zones

  We now allow custom zones. The current default zones are:

  http://.../services/rest/APPLICATION_NAME/_admin/...
  http://.../services/rest/APPLICATION_NAME/LIFECYCLE_CLASS/data/OBJECT_NAME/...
  http://.../services/rest/APPLICATION_NAME/LIFECYCLE_CLASS/action/ACTION_NAME/...
  http://.../services/rest/APPLICATION_NAME/LIFECYCLE_CLASS/object/OBJECT_NAME/...

  The zone names are: _admin, data, action, object
  It's possible to set custom names with following parameters in the deployment descriptor: zone.admin, zone.data, zone.action, zone.object

• Hide object names

  If you want to hide the object name(s), e.g.

  https://.../demoerp/services/rest/DemoERP/Customers/data/customer/

  The URL contains the Lifecycle Name (Customers) and the object name (customer). Both are easy to understand. In this example, we return the customer list from our customers object. If you want to use different names, it's possible to change the name in the lifecycle object code, e.g.

  @Replacement(name="business")
  public class Customers extends Session
  {
      @Replacement(name="clist")
      public IStorage getCustomer()
      {
          ...
      }
  }

  With above code, it'll be possible to request:

  https://.../demoerp/services/rest/DemoERP/business/data/clist/

The updated implementation is still a generic solution but it's now more flexible than before and should help you to offer new services. To use the new features, simply use our nightly JVx builds.

I'm happy to announce that our Workflow Engine will work with Oracle Forms.

The current state is beta but we'll release our Workflow engine in the next days. We found some time to test the integration in Oracle Forms and the result is soo cool. It works like a charm.

So it will be possible to embed our Workflow engine in your oracle Forms. It'll be possible for your users to design custom flows and processes. The engine itself is database driven and will work with your Oracle Forms application.

More details will follow in the next days, but here's a first impression:

Workflow Engine - Oracle Forms

It's a standard Oracle Forms window/canvas with our Workflow Designer, embedded as Java Bean.

Feel free to ask your questions

We improved the support for standard MacOS LaF in our Swing UI and VisionX. The LaF has a lot of rendering problems. We tried to use another LaF implementation but had other problems. So we decided to keep the standard Java MacOS LaF.

The problems

• The InternalFrame border problem
• The field border problem
  

  Field border problem

  A simple JTextField has a 5 pixel focus border. This is horrible because the focus is about 2 pixel. The other problem is that a JTextArea wrapped in a JScrollPane doesn't have the 5 pixel border. This makes it hard to create nice looking layouts.

  We fixed this problem:

  Field border without gap

  Looks better. One problem is that the JScrollPane doesn't paint the focus if the JTextArea has the focus. This is a LaF problem and we didn't find a workaround for this problem.

• Application Menubar

  Standard Java appliacations show the menubar in the same frame

  Application menu

  If you set the system property:

  System.setProperty("apple.laf.useScreenMenuBar", "true");

the menu will be placed in the menu bar of MacOS:

macOS Menu

We fixed the problem that setting the menu to null will keep the menu as it was.

• Comboboxes

  The height of Standard Comboboxes is wrong:

  Combobox wrong

  We fixed the problem as good as possible:

  Combobox fixed

• VisionX Toolbar height

  The toolbar height was wrong because of layout calculation problems:

  Wrong Toolbar height

  We fixed the problem and the toolbar height is correct:

  Toolbar fixed

• VisionX Wizard gaps

  The image gaps in VisionX wizards was not recognized:

  Wrong gaps

  It looks better without gaps:

  No gaps

• Wrong button rendering

  If you had a button without an image and a button with an image, the height of the button without image was higher than the button with an image. This is a LaF rendering bug:

  Wrong size and font

  The fonts are also different. We didn't know why there has to be such a difference, but we fixed the problem in Swing UI:

  Button with correct size and font

All changes are available in our nightly JVx builds