Release Notes

Rogue Wave JViews 2017 (9.0)

 

This document describes the main changes that have been made to JViews since version 8.10.

1         General changes

·         To provide better accuracy, most computations are now made using double precision in place of float precision. As a result, the corresponding signatures have been changed. For more information, see the Migration notes in this document.

·         JViews libraries are now compiled with Java target 7 instead of target 6.

·         Distribution folder structure has been changed:

o   module folder names no longer contain the version number

o   documentation for all modules has been moved to <install_dir>/documentation

·         Japanese documentation is no longer available.

·         Documentation has been changed to reflect the Rogue Wave corporate style.

·         Due to obsolescence of applet technology (future deprecation and no availability in some browser), all usages of applet technology is removed in samples and demos.

·         ICEfaces samples and libraries have been removed.

·         J2EE samples and demos moved to JSF2.

·         A specific tomcat configuration for facelets/Trinidad demos. The server, located in tools/tomcat-facelets, listen on port 9090.

·         Replaced JDBC-ODBC Bridge driver with CSV JDBC Driver or SQLite JDBC Driver in application and samples.

·         Third-party updates:

 

 

Old version

New version

Framework Tools

 

 

 

 

Ant

1.9.7

1.9.9

 

Tomcat

7.0.72

8.5.11

Framework lib external

 

 

 

 

backport-util-concurrent

2.2

N/A (removed)

 

bcel

5.1

6.0

 

commons-beanutils

1.6

1.9.3

 

commons-codec

N/A

1.10

 

commons-collections

2.1

N/A (removed)

 

commons-collections4

N/A

4.1

 

commons-digester

1.7

N/A (removed)

 

commons-digester3

N/A

3.2

 

commons-fileupload

1.2.1

N/A (removed)

 

commons-lang

2.1

3-3.5

 

csvjdbc

N/A

1.0.31

 

Icu4j

57.1

58.2

 

javaee-api

N/A

7.0

 

javax.faces

N/A

2.2.14

 

jstl

1_1-mr2-api

1.2

 

slf4j-api

1.7.12

1.7.24

 

slf4j-jdk

14-1.7.21

14-1.7.24

 

sqlite-jdbc

N/A

3.16.1

 

trinidad-api

1.2.8

2.1.2

 

trinidad-impl

1.2.8

2.1.2

 

·         Modules changes:

o   Framework release notes

o   Charts release notes

o   Gantt release notes

o   Diagrammer release notes

o   Maps release notes

o   Maps for defense release notes

o   TGO release notes

·         Some deprecated Classes/Methods have been removed.

2         Migration notes

2.1        Code migration

This section contains information about the modifications you need to perform when you are migrating from earlier versions of JViews to version 9.0.

2.1.1        Evaluate

You can evaluate your code to determine which methods/constructors need to change using the tools and information found at Rogue Wave Knowledge Base: JViews 9.0 - Migration tools.

2.1.2        Clean code

Before migration, we highly recommend you clean up your code using the Eclipse’s Clean Up option.  This adds any missing annotations such as @Override (Class override method and implementation of interface methods).  With these annotations, some compilers will be able to detect some errors while migrating, making it a highly useful tool when migrating code.

To enable annotation error detection in Eclipse, open the preferences window from the menu bar and then go to Java -> Compiler -> Errors/Warnings. From the Errors/Warnings dialog, in the Annotations section set Missing ‘@Override’ annotation to Error and enable Include implementations of interface methods.

2.1.3        Use the new JViews Libraries with your projects

Change any references to the old JViews libraries to the new libraries. Please note that subfolder names for all libraries no longer contains the version number.

Example changes:

<old_install_dir>/jviews-framework810/lib/jviews-framework-all.jar

To:

<new_install_dir>/jviews-framework/lib/jviews-framework-all.jar

2.1.4        Change JViews API parameters from float to double

To help you determine which parameters need to be changed from a double to a float, use the compiler. It will give you a list of all the errors that need to be fixed. You must choose if your parameter needs to be changed to a double or if you want to keep it as a float (in this case an implicit cast to double will be used by the compiler).

Review all parameters where the API has changed and select if you need to change them from a float to a double.

2.1.5        Check decimal expression according new type

·         You must change float literals to double (for example change 0.5f to 0.5)

·         Remove all unnecessary casts to float

2.1.6        Javadoc annotations

Review your javadoc annotations and check if any float/double need to be fixed.

2.2        Data migration:

Because the data type of some fields has changed, the persistence of your data must be reviewed.

2.2.1        JViews i/o streams

The IlvInputStream class has a new method named readDoubleOrFloat. The return type is always double but, depending of the file version included in the file itself, this method can read a float or a double from the file. The intent of this method is to handle fields that have been changed from float to double in version 9.0. This way all ivl files written with earlier versions of JViews can be read by version 9.0.

If you have created your own Graphics object that extends IlvGraphic (or a subclass of ) and implemented the interface IlvPersistentObject, and if your fields need to be changed from float to double according the new signatures of the JViews library, you can easily replicate the same behavior by changing the code used for reading the field from ilog.views.io.IlvInputStream.readFloat("Your Field name") to ilog.views.io.IlvInputStream.readDoubleOrFloat("Your Field name") in the constructor of your object using an IlvInputStream  parameter.

Reference: IlvPersistentObject


 

Sample of code for double/float compatibility with JViews IO Streams:

import java.io.IOException;

import ilog.views.io.*;

 

public class MyArc extends IlvArc {

 

  // float myMember; // before JViews 9.0

  double myMember;

 

  public MyArc(IlvInputStream stream) throws IlvReadFileException {

    super(stream);

    //myMember = stream.readFloat("my_member_field_name"); // Before JViews 9.0

    myMember = stream.readDoubleOrFloat("my_member_field_name");

  }

 

  @Override

  public void write(IlvOutputStream stream) throws IOException {

    super.write(stream);

    stream.write("my_member_field_name", myMember);

  }

}

 

2.2.2        Java serialization

The changes made in JViews 9.0 may produce some incompatibilities for java object serialization content.

If you have created your own Graphic object and used the java serialization, (Standard Java serialization with graphic object is not a recommended practice. See: IlvGraphic) you can drive the methods readObject(ObjectInputStream) and writeObject(ObjectOutputStream) with these environment variables:

·         JVIEWS_SERIALIZE_DOUBLE activate double for read AND write operations (default value is true).

·         JVIEWS_SERIALIZE_DOUBLE_WRITE activate/deactivate double for write operations (if it is not defined, the value is the same as JVIEWS_SERIALIZE_DOUBLE).

·         JVIEWS_SERIALIZE_DOUBLE_READ activate/deactivate double for read operations (if it is not defined, the value is the same as JVIEWS_SERIALIZE_DOUBLE).

You can also control the serialization/deserialization locally in your code with the methods setDoubleSerializable(Boolean), setDoubleSerializableWrite(Boolean), and setDoubleSerializableRead(Boolean) of the IlvSerializableUtil class. These methods override the behavior specified by the environment variables.

JViews uses these values to select double or float in java serialization for the classes: IlvPoint, IlvRect, IlvDashboardWriter, IlvDashboardReader, and IlvLinearGradientPaint.

2.3        Impacts

Because most computations are now made using double in place of float in JViews 9.0, be sure to thoroughly review your code as this change can cause some unexpected behavior.

2.3.1        Review numeric expressions mixing float and double

A general rule can be “do not mix float and double in expressions”.

For example, if you run:

float a=0.1f;

double b=0.1;

System.out.println((b-a));

The output is:

-1.4901161138336505E-9

2.3.2        Reviews conditional expressions

Because of the new precision (≈7 significant decimal digits for float and ≈16 significant decimal digits for double) comparisons between two numbers will be different.

For example, if you run:

System.out.print("expression (0.1f+0.2f)==0.3f) return "+((0.1f+0.2f)==0.3f));

System.out.println("  and delta = "+ ((0.1f+0.2f)-0.3f));

System.out.print("expression (0.1+0.2)==0.3)    return "+((0.1+0.2)==0.3));

System.out.println(" and delta = "+ ((0.1+0.2)-0.3));

 

The output is:

expression (0.1f+0.2f)==0.3f) return true  and delta = 0.0

expression (0.1+0.2)==0.3)    return false and delta = 5.551115123125783E-17

 

Rather than using the standard == or equals operator, try to use a comparison function like:

boolean nearlyEqual(double a, double b, double epsilon)

2.3.3        Check other APIs

For example, if you use:

org.junit.Assert.assertEquals(double expected, double actual, double delta);

you may have to change the third parameter delta.