May 2014 - core-libs-dev

DecimalFormat rounding changes in 8 (JEP 177)?
by solo-java-core-libs＠goeswhere.com 05 May '14

05 May '14

Hey, Could someone please help me understand what changes have happened in rounding in DecimalFormat in Java 8? new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and Oracle build 1.8.0-b132 win64 tested). My understanding of the RoundingMode.HALF_EVEN (the default) documentation is that 1.04 is the correct answer. In fact, (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware that floating point is more complex than this, and I am by no means an expert. It seems that this may be new code, with a known breaking change in it: http://openjdk.java.net/jeps/177: > Compatibility: On JDK 7, (correct) but altered numerical behavior will > only be enabled under an aggressive optimization flag to limit > behavioral compatibility impact in that release train. In Java SE 8, > the correct numerical behavior will always be required by the > specification. Did this materialise somewhere, and, if so, where's it documented? In summary: My tests fail on Java 8 and I'm not sure they're wrong. Any help would be appreciated, thanks.

5 5

RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV
by Coleen Phillimore 02 May '14

02 May '14

Summary: Redefined class in stack trace may not be found by method_idnum so handle null. This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ bug link https://bugs.openjdk.java.net/browse/JDK-8025238 test case for jdk8 repository: open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk Thanks, Coleen

6 15

8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily
by Neil Toda 02 May '14

02 May '14

Please review Launcher change and test. I've added to the Launcher test : FXLauncherTest.java The test will now check that LauncherHelper$FXHelper is not loaded for non-JavaFX class and jar files. webrev.02 contains only review suggestions from webrev.01 and the new test class. http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ for bug: https://bugs.openjdk.java.net/browse/JDK-8035782 Thanks -neil

4 7

JDK 9 RFC on 8032016: Optimizations of Math.next{After, Up}({float, double})
by Brian Burkhalter 02 May '14

02 May '14

Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8032016 Patch: http://cr.openjdk.java.net/~bpb/8032016/webrev.00/ The performance improvements of this change are marginal but the logic seems reasonable and the code looks cleaner so I am posting this as an RFC. Comments? Thanks, Brian

2 1

RFR: 8042266: [launcher] create test groups for launcher regression tests
by Kumar Srinivasan 02 May '14

02 May '14

Hi, Simple changes to add jdk_launcher to the jdk's Test.groups, this allows anyone working on the launcher to run a set of regression tests which historically have helped shake out launcher regressions. http://cr.openjdk.java.net/~ksrini/8042266/webrev.00/ Usage: jtreg ...... /blah/de/blah/jdk/test:jdk_launcher Thanks Kumar

2 3