|
Release Notes |
Rogue Wave JViews 2017 (9.0)
This document describes the main changes that have been made to JViews since version 8.10.
· 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 Maps for defense release notes
· Some deprecated Classes/Methods have been removed.
This section contains information about the modifications you need to perform when you are migrating from earlier versions of JViews to version 9.0.
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.
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.
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
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.
· You must change float literals to double (for example change 0.5f to 0.5)
· Remove all unnecessary casts to float
Review your javadoc annotations and check if any float/double need to be fixed.
Because the data type of some fields has changed, the persistence of your data must be reviewed.
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);
}
}
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.
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.
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
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)
For example, if you use:
org.junit.Assert.assertEquals(double expected,
double actual, double delta);
you may have to change the third parameter delta.