From: Jim Procter Date: Thu, 10 Dec 2020 17:50:05 +0000 (+0000) Subject: JAL-3223 - update swingjs to 3.2.9-j11 X-Git-Url: http://source.jalview.org/gitweb/?a=commitdiff_plain;h=0aa289427134d46212cb8fd7e207f714ec0282f3;p=jalview.git JAL-3223 - update swingjs to 3.2.9-j11 --- diff --git a/swingjs/SwingJS-site.zip b/swingjs/SwingJS-site.zip index a1b1cf6..52b640a 100644 Binary files a/swingjs/SwingJS-site.zip and b/swingjs/SwingJS-site.zip differ diff --git a/swingjs/differences.txt b/swingjs/differences.txt index 70eabbc..60f5fcc 100644 --- a/swingjs/differences.txt +++ b/swingjs/differences.txt @@ -31,6 +31,7 @@ ever be shadowed or overridden by subclasses. For example, we see in java.lang.T ---------------------------------- +updated 12/6/2020 -- note about restrictions on long, including BitSet and Scanner updated 3/21/2020 -- adds note about HashMap, Hashtable, and HashSet iterator ordering updated 3/20/2020 -- adds note about interning, new String("xxx"), and "xxx" updated 2/26/2020 -- adds Graphics.setClip issue @@ -480,6 +481,8 @@ MINOR ISSUES--requiring some rewriting/refactoring outside of SwingJS See below for a full discussion. +Restrictions on long +Restriction on BitSet and Scanner HashMap, Hashtable, and HashSet iterator ordering interning, new String("xxx") vs "xxx" Names with "$" and "_" @@ -586,6 +589,60 @@ changed to JSToolkit.isDispatchThread() MINOR ISSUES--requiring some rewriting/refactoring outside of SwingJS ===================================================================== +restrictions on long +-------------------- + +Java's 64-bit long type is not supported in JavaScript. There is no Int64Array in JavaScript, +and 0x20000000000000 + 1 evaluates to 0x20000000000000, not 0x20000000000001. +(Likewise, -0x20000000000000 - 1 is left unchanged.) + +The largest "integer" value in JavaScript is 9007199254740991 (9.007199254740991E13, or 0x1FFFFFFFFFFFFFF). +Effectively, you get to use only 53 bits of the long, not 64. Trying to set a long larger than +0x1FFFFFFFFFFFFFF or smaller than -0x1FFFFFFFFFFFFFF will result in a NumberFormatException. + +The transpiler handles conversion to long the same as Java for all cases other than from double. + +For small double values, there is no problem, and, in fact, this is a known trick used to round +doubles and floats toward zero: + +double d; +d = (long) 3.8; +assert(d == 3); +d = (long) -3.8; +assert(d == -3); + +SwingJS will evaluate (long) d as 0 for d > 9007199254740991 +or d < -9007199254740991, same as Java returns for Double.NaN. +So, in Java we have: + + assert(((long) Double.NaN) == 0); + assert(((int) Double.NaN) == 0); + assert(((long) Float.NaN) == 0); + assert(((int) Float.NaN) == 0); + +and also, in JavaScript only, we also have: + + double d = 0x2000000000000L; + assert(((long) d) == 0); + + +restrictions on BitSet and Scanner +---------------------------------- + +Because of the issue of long being only 53 bits, any time a method returns a long value, considerations must +be made as to whether this will work in JavaScript. In particular, BitSet and Scanner have issues. + +In SwingJS, java.util.BitSet has been implemented as a 32-bit integer-based bitset. This was no problem in +Java 6, but starting with Java 7, a method was added to BitSet that allows for the extraction of the +underlying long[] word data. This is not work in JavaScript. Instead, SwingJS java.util.Bitset.toLongArray() will deliver +32-bit int[] data. + +SwingJS Scanner has hasNextLong() and nextLong(), and although it will scan through long numbers, +Scanner will choke on long numbers greater than the JavaScript 53-bit limit. hasNextLong() will +return false, and nextLong() will throw an InputMismatchException triggered by the NumberFormatException +thrown by Long.parseLong(). + + HashMap, Hashtable, and HashSet iterator ordering ------------------------------------------------- @@ -1432,6 +1489,10 @@ and so are not implmented. javax.swing.text.View and its subclasses are not impl The JS document model does not allow two text fields to address the same underlying document. +JavaScript is slightly different from Java in that the field value is changed asynchronously after +the keypressed event, so Java actions that are keyed to KEY_PRESSED may not pick up the new +key value even after SwingUtilities.invokeLater() is called. Thus, key pressed actions may need +to be recorded after a key released event instead. Formatter/Regex limitations --------------------------- diff --git a/swingjs/net.sf.j2s.core-j11.jar b/swingjs/net.sf.j2s.core-j11.jar index 928a835..8cae046 100644 Binary files a/swingjs/net.sf.j2s.core-j11.jar and b/swingjs/net.sf.j2s.core-j11.jar differ diff --git a/swingjs/net.sf.j2s.core.jar b/swingjs/net.sf.j2s.core.jar index 6e3c4f0..ab277a9 100644 Binary files a/swingjs/net.sf.j2s.core.jar and b/swingjs/net.sf.j2s.core.jar differ diff --git a/swingjs/timestamp b/swingjs/timestamp index 89e1eb4..df5be44 100644 --- a/swingjs/timestamp +++ b/swingjs/timestamp @@ -1 +1 @@ -20200615125203 +20201206115202 diff --git a/swingjs/ver/3.2.7/SwingJS-site.zip b/swingjs/ver/3.2.7/SwingJS-site.zip index 763362e..dd6765a 100644 Binary files a/swingjs/ver/3.2.7/SwingJS-site.zip and b/swingjs/ver/3.2.7/SwingJS-site.zip differ diff --git a/swingjs/ver/3.2.8/SwingJS-site.zip b/swingjs/ver/3.2.8/SwingJS-site.zip index 46f33d8..dd6765a 100644 Binary files a/swingjs/ver/3.2.8/SwingJS-site.zip and b/swingjs/ver/3.2.8/SwingJS-site.zip differ diff --git a/swingjs/ver/3.2.9-j11/SwingJS-site.zip b/swingjs/ver/3.2.9-j11/SwingJS-site.zip index a1b1cf6..dd6765a 100644 Binary files a/swingjs/ver/3.2.9-j11/SwingJS-site.zip and b/swingjs/ver/3.2.9-j11/SwingJS-site.zip differ diff --git a/swingjs/ver/3.2.9-j11/differences.txt b/swingjs/ver/3.2.9-j11/differences.txt index 70eabbc..46e49ec 100644 --- a/swingjs/ver/3.2.9-j11/differences.txt +++ b/swingjs/ver/3.2.9-j11/differences.txt @@ -1432,6 +1432,10 @@ and so are not implmented. javax.swing.text.View and its subclasses are not impl The JS document model does not allow two text fields to address the same underlying document. +JavaScript is slightly different from Java in that the field value is changed asynchronously after +the keypressed event, so Java actions that are keyed to KEY_PRESSED may not pick up the new +key value even after SwingUtilities.invokeLater() is called. Thus, key pressed actions may need +to be recorded after a key released event instead. Formatter/Regex limitations --------------------------- diff --git a/swingjs/ver/3.2.9-j11/net.sf.j2s.core-j11.jar b/swingjs/ver/3.2.9-j11/net.sf.j2s.core-j11.jar index 928a835..8cae046 100644 Binary files a/swingjs/ver/3.2.9-j11/net.sf.j2s.core-j11.jar and b/swingjs/ver/3.2.9-j11/net.sf.j2s.core-j11.jar differ diff --git a/swingjs/ver/3.2.9-j11/timestamp b/swingjs/ver/3.2.9-j11/timestamp index 89e1eb4..7a0c426 100644 --- a/swingjs/ver/3.2.9-j11/timestamp +++ b/swingjs/ver/3.2.9-j11/timestamp @@ -1 +1 @@ -20200615125203 +20201127032339 diff --git a/swingjs/ver/3.2.9/SwingJS-site.zip b/swingjs/ver/3.2.9/SwingJS-site.zip index a1b1cf6..52b640a 100644 Binary files a/swingjs/ver/3.2.9/SwingJS-site.zip and b/swingjs/ver/3.2.9/SwingJS-site.zip differ diff --git a/swingjs/ver/3.2.9/differences.txt b/swingjs/ver/3.2.9/differences.txt index 70eabbc..60f5fcc 100644 --- a/swingjs/ver/3.2.9/differences.txt +++ b/swingjs/ver/3.2.9/differences.txt @@ -31,6 +31,7 @@ ever be shadowed or overridden by subclasses. For example, we see in java.lang.T ---------------------------------- +updated 12/6/2020 -- note about restrictions on long, including BitSet and Scanner updated 3/21/2020 -- adds note about HashMap, Hashtable, and HashSet iterator ordering updated 3/20/2020 -- adds note about interning, new String("xxx"), and "xxx" updated 2/26/2020 -- adds Graphics.setClip issue @@ -480,6 +481,8 @@ MINOR ISSUES--requiring some rewriting/refactoring outside of SwingJS See below for a full discussion. +Restrictions on long +Restriction on BitSet and Scanner HashMap, Hashtable, and HashSet iterator ordering interning, new String("xxx") vs "xxx" Names with "$" and "_" @@ -586,6 +589,60 @@ changed to JSToolkit.isDispatchThread() MINOR ISSUES--requiring some rewriting/refactoring outside of SwingJS ===================================================================== +restrictions on long +-------------------- + +Java's 64-bit long type is not supported in JavaScript. There is no Int64Array in JavaScript, +and 0x20000000000000 + 1 evaluates to 0x20000000000000, not 0x20000000000001. +(Likewise, -0x20000000000000 - 1 is left unchanged.) + +The largest "integer" value in JavaScript is 9007199254740991 (9.007199254740991E13, or 0x1FFFFFFFFFFFFFF). +Effectively, you get to use only 53 bits of the long, not 64. Trying to set a long larger than +0x1FFFFFFFFFFFFFF or smaller than -0x1FFFFFFFFFFFFFF will result in a NumberFormatException. + +The transpiler handles conversion to long the same as Java for all cases other than from double. + +For small double values, there is no problem, and, in fact, this is a known trick used to round +doubles and floats toward zero: + +double d; +d = (long) 3.8; +assert(d == 3); +d = (long) -3.8; +assert(d == -3); + +SwingJS will evaluate (long) d as 0 for d > 9007199254740991 +or d < -9007199254740991, same as Java returns for Double.NaN. +So, in Java we have: + + assert(((long) Double.NaN) == 0); + assert(((int) Double.NaN) == 0); + assert(((long) Float.NaN) == 0); + assert(((int) Float.NaN) == 0); + +and also, in JavaScript only, we also have: + + double d = 0x2000000000000L; + assert(((long) d) == 0); + + +restrictions on BitSet and Scanner +---------------------------------- + +Because of the issue of long being only 53 bits, any time a method returns a long value, considerations must +be made as to whether this will work in JavaScript. In particular, BitSet and Scanner have issues. + +In SwingJS, java.util.BitSet has been implemented as a 32-bit integer-based bitset. This was no problem in +Java 6, but starting with Java 7, a method was added to BitSet that allows for the extraction of the +underlying long[] word data. This is not work in JavaScript. Instead, SwingJS java.util.Bitset.toLongArray() will deliver +32-bit int[] data. + +SwingJS Scanner has hasNextLong() and nextLong(), and although it will scan through long numbers, +Scanner will choke on long numbers greater than the JavaScript 53-bit limit. hasNextLong() will +return false, and nextLong() will throw an InputMismatchException triggered by the NumberFormatException +thrown by Long.parseLong(). + + HashMap, Hashtable, and HashSet iterator ordering ------------------------------------------------- @@ -1432,6 +1489,10 @@ and so are not implmented. javax.swing.text.View and its subclasses are not impl The JS document model does not allow two text fields to address the same underlying document. +JavaScript is slightly different from Java in that the field value is changed asynchronously after +the keypressed event, so Java actions that are keyed to KEY_PRESSED may not pick up the new +key value even after SwingUtilities.invokeLater() is called. Thus, key pressed actions may need +to be recorded after a key released event instead. Formatter/Regex limitations --------------------------- diff --git a/swingjs/ver/3.2.9/net.sf.j2s.core.jar b/swingjs/ver/3.2.9/net.sf.j2s.core.jar index 6e3c4f0..ab277a9 100644 Binary files a/swingjs/ver/3.2.9/net.sf.j2s.core.jar and b/swingjs/ver/3.2.9/net.sf.j2s.core.jar differ diff --git a/swingjs/ver/3.2.9/timestamp b/swingjs/ver/3.2.9/timestamp index d7eef9d..df5be44 100644 --- a/swingjs/ver/3.2.9/timestamp +++ b/swingjs/ver/3.2.9/timestamp @@ -1 +1 @@ -20200615125140 +20201206115202