It is available from the project page.

What’s different?

We fixed some smaller bugs and improved metadata caching. A very cool NEW feature is the block fetching for RemoteDataBooks.

• MetaData caching

  We have a metadata cache on the server side to reduce database calls and we have a cache role on the client-side to reduce remote calls. But it was not possible to change the cache role for specific connections. If the cache was enabled, it was enabled for the whole application.

  Now it is possible to set a connection property to change the cache handling for all databooks which use the connection.

  connection.setProperty(IConnectionConstants.METADATA_CACHEOPTION, MetaDataCacheOption.Off.toString());

  Off means no metadata on client-side and reload metadata from database on server-side.
  On means always use the metadata cache and ignore the default setting.
  Default means that the connection uses the client cache role setting.

• Block fetching

  This is an amazing new feature and boosts an application!
  Before beta-4, every Master/Detail selection change executed a remote call if the detail was not already fetched. It depends on the number of detail databooks, but if you have one master and 5 detail databooks, every master-change executes 5 remote calls to retrieve detail data. 5 requests is not very clever because it should be possible in only 1 request? With 1.0 beta-4 this optimization is implemented, but not used per default. It depends on th number of records and number of details if it is possible to fetch all defail databooks as one block. It is your decision if it makes sense to use block fetching!

  Be careful, the block fetch columns are not the same as used for the master reference definition!

  Example:

  rdbWorkScreenMembers.setMasterReference(
      new ReferenceDefinition(new String[] {"APPL_ID", "CLASSNAME",
                                            "PARENT_NAME", "PARENT_METHOD"},
      rdbWorkScreenMembers,
      new String[] {"APPL_ID", "CLASSNAME", "NAME", "METHOD"}));

  //Block fetching does not need PARENT information, because we want all PARENTs
  rdbWorkScreenMembers.setBlockFetchColumnNames(new String[] {"APPL_ID",
                                                              "CLASSNAME"});

• JNLP service access for Applets

  If you use the jnlp_href tag for your applet, it is now possible to use the clipboard, file open and file save JNLP services without additional coding effort. Since 1.6 u24 it is not possible to copy/paste to/from text components. We made it possible in the Swing UI and now it is available for all your applications.

• Refactoring

  We moved IDataBook.searchNext to IDataPage and added searchPrevious to the API.

Check the Changelog for a complete list, and use our Forum to talk with us