From david.katleman at oracle.com Sat Feb 1 18:25:50 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:25:50 +0000 Subject: hg: jdk8/jdk8: Added tag jdk8-b128 for changeset 101e42de4686 Message-ID: <20140202022550.8A2E962944@hg.openjdk.java.net> Changeset: 1e5fe8654913 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/1e5fe8654913 Added tag jdk8-b128 for changeset 101e42de4686 ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:27:34 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:27:34 +0000 Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b128 for changeset 874c0b4a946c Message-ID: <20140202022736.B0DAD62946@hg.openjdk.java.net> Changeset: cb39165c4a65 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cb39165c4a65 Added tag jdk8-b128 for changeset 874c0b4a946c ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:29:44 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:29:44 +0000 Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b128 for changeset de172acc095b Message-ID: <20140202022946.1EBC062948@hg.openjdk.java.net> Changeset: aabc90596123 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/aabc90596123 Added tag jdk8-b128 for changeset de172acc095b ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:29:54 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:29:54 +0000 Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b128 for changeset f644211c59fd Message-ID: <20140202023006.A504D6294B@hg.openjdk.java.net> Changeset: 3c9473004f38 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3c9473004f38 Added tag jdk8-b128 for changeset f644211c59fd ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:29:37 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:29:37 +0000 Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b128 for changeset b1839922f10c Message-ID: <20140202022939.7F8F262947@hg.openjdk.java.net> Changeset: b7752cea7c81 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/b7752cea7c81 Added tag jdk8-b128 for changeset b1839922f10c ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:31:50 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:31:50 +0000 Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b128 for changeset 09cdd3b493c0 Message-ID: <20140202023153.311016294C@hg.openjdk.java.net> Changeset: 8fe7202d3c38 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/8fe7202d3c38 Added tag jdk8-b128 for changeset 09cdd3b493c0 ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:31:59 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:31:59 +0000 Subject: hg: jdk8/jdk8/nashorn: Added tag jdk8-b128 for changeset 73cbad0c5d28 Message-ID: <20140202023200.72D9E6294D@hg.openjdk.java.net> Changeset: 9cc3fd32fbab Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/nashorn/rev/9cc3fd32fbab Added tag jdk8-b128 for changeset 73cbad0c5d28 ! .hgtags From david.katleman at oracle.com Sat Feb 1 18:25:54 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sun, 02 Feb 2014 02:25:54 +0000 Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b128 for changeset 113e7569b49b Message-ID: <20140202022554.C35E862945@hg.openjdk.java.net> Changeset: 5c72d74c6805 Author: katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/5c72d74c6805 Added tag jdk8-b128 for changeset 113e7569b49b ! .hgtags From mathias.axelsson at oracle.com Tue Feb 4 06:31:10 2014 From: mathias.axelsson at oracle.com (Mathias Axelsson) Date: Tue, 4 Feb 2014 15:31:10 +0100 Subject: Update on JDK 8 builds and release candidate status In-Reply-To: <41AB805B-3E50-4B41-8821-3171AD85718A@oracle.com> References: <41AB805B-3E50-4B41-8821-3171AD85718A@oracle.com> Message-ID: Hi, I'd like to give you an update on the below. We've promoted b128 and this is the first release candidate build of JDK 8. b128 is available on java.net [1] so you can download it and try it out. I'll continue to monitor incoming bugs. If a showstopper bug shows up that is deemed critical for the JDK 8 release then we'll have to create a new build to include it. Kind regards, Mathias Axelsson, Oracle JDK Release Manager [1] https://jdk8.java.net/download.html On 31 jan 2014, at 12:55, Mathias Axelsson wrote: > Hi, > > It's been a while since my last update so I wanted to give you an update on > where we are. > > Focus has been on getting the final RI (Reference Implementation) build for > the Java SE 8 specification completed and ready. The current RI build is > b126 [1] and unless any TCK blockers shows up, this build will be the RI > for Java SE 8. > > With the RI build in place focus has now shifted to get the remaining > showstopper fixes for JDK 8 into the master. We had a number of fixes lined > up and got them integrated earlier this week so that we could do a new > promoted build (b127). This build will be posted on java.net [2] shortly. > > b127 is not a release candidate build as there are still a few critical > issues that must be fixed and integrated. I'm following up on the bugs on a > daily basis and hope we can cut the first release candidate of JDK 8 > shortly. > > I will send out an update once we have a release candidate build of JDK 8. > > Kind regards, > Mathias Axelsson, Oracle JDK 8 Release Manager > > > [1] https://jdk8.java.net/java-se-8-ri/ > > [2] https://jdk8.java.net/download.html > From nobeh5 at gmail.com Wed Feb 5 09:42:09 2014 From: nobeh5 at gmail.com (Behrooz N) Date: Wed, 5 Feb 2014 18:42:09 +0100 Subject: Javadoc for default methods of an interface Message-ID: Hi, I was wondering if there is a way to specify the "default" value returned by a defender method of an interface that would be processed specifically by javadoc of Java 8? And, how fair this expectation is or what is the argument not to have it? Thanks in advance, Behrooz From brian.goetz at oracle.com Wed Feb 5 11:42:34 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Feb 2014 14:42:34 -0500 Subject: Javadoc for default methods of an interface In-Reply-To: References: Message-ID: <52F2942A.2050003@oracle.com> There are some new javadoc tags to let you separate normative from non-normative, and how it applies separately to the interface vs the default implementation. They are: @implSpec -- *specification* about what the default implementation does, such as "the default implementation throws UOE". This can be counted on by subclasses to make decisions about "should I override this or not". @implNote -- non-normative notes about the implementation, which historically have been prefaced by "implementation note". @apiNote -- non-normative notes about the API, such as examples of how to use it. The fourth quadrant, normative spec about the interface, needs no tag since that's what the spec is for. On 2/5/2014 12:42 PM, Behrooz N wrote: > Hi, > > I was wondering if there is a way to specify the "default" value returned > by a defender method of an interface that would be processed specifically > by javadoc of Java 8? And, how fair this expectation is or what is the > argument not to have it? > > Thanks in advance, > Behrooz > From mike.duigou at oracle.com Wed Feb 5 15:42:21 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Feb 2014 15:42:21 -0800 Subject: Javadoc for default methods of an interface In-Reply-To: <52F2942A.2050003@oracle.com> References: <52F2942A.2050003@oracle.com> Message-ID: The new tags are used in JDK docs but aren't standard javadoc tags. It's necessary to use the -tag option to define them so that javadoc tool will recognize then in source outside the JDK. On 2014-02-05, at 11:42, Brian Goetz wrote: > There are some new javadoc tags to let you separate normative from non-normative, and how it applies separately to the interface vs the default implementation. They are: > > @implSpec -- *specification* about what the default implementation does, such as "the default implementation throws UOE". This can be counted on by subclasses to make decisions about "should I override this or not". > > @implNote -- non-normative notes about the implementation, which historically have been prefaced by "implementation note". > > @apiNote -- non-normative notes about the API, such as examples of how to use it. > > The fourth quadrant, normative spec about the interface, needs no tag since that's what the spec is for. > > > > On 2/5/2014 12:42 PM, Behrooz N wrote: >> Hi, >> >> I was wondering if there is a way to specify the "default" value returned >> by a defender method of an interface that would be processed specifically >> by javadoc of Java 8? And, how fair this expectation is or what is the >> argument not to have it? >> >> Thanks in advance, >> Behrooz >> From nobeh5 at gmail.com Thu Feb 6 05:30:05 2014 From: nobeh5 at gmail.com (Behrooz N) Date: Thu, 6 Feb 2014 14:30:05 +0100 Subject: Javadoc for default methods of an interface In-Reply-To: References: <52F2942A.2050003@oracle.com> Message-ID: Thanks for your examples and explanations. On Thu, Feb 6, 2014 at 12:42 AM, Mike Duigou wrote: > The new tags are used in JDK docs but aren't standard javadoc tags. It's > necessary to use the -tag option to define them so that javadoc tool will > recognize then in source outside the JDK. > > > > On 2014-02-05, at 11:42, Brian Goetz wrote: > > > There are some new javadoc tags to let you separate normative from > non-normative, and how it applies separately to the interface vs the > default implementation. They are: > > > > @implSpec -- *specification* about what the default implementation does, > such as "the default implementation throws UOE". This can be counted on by > subclasses to make decisions about "should I override this or not". > > > > @implNote -- non-normative notes about the implementation, which > historically have been prefaced by "implementation note". > > > > @apiNote -- non-normative notes about the API, such as examples of how > to use it. > > > > The fourth quadrant, normative spec about the interface, needs no tag > since that's what the spec is for. > > > > > > > > On 2/5/2014 12:42 PM, Behrooz N wrote: > >> Hi, > >> > >> I was wondering if there is a way to specify the "default" value > returned > >> by a defender method of an interface that would be processed > specifically > >> by javadoc of Java 8? And, how fair this expectation is or what is the > >> argument not to have it? > >> > >> Thanks in advance, > >> Behrooz > >> > -- -- Behrooz Nobakht From lana.steuck at oracle.com Thu Feb 6 14:59:18 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 06 Feb 2014 22:59:18 +0000 Subject: hg: jdk8/jdk8/jdk: 4 new changesets Message-ID: <20140206230006.F00DA62A9E@hg.openjdk.java.net> Changeset: ab6e7bb8ff9f Author: pchelko Date: 2014-01-22 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ab6e7bb8ff9f 7155984: Security problems in regression test java/awt/PrintJob/Security/SecurityDialogTest.java Reviewed-by: anthony, serb ! src/macosx/classes/apple/laf/JRSUIUtils.java Changeset: eef10feca8ca Author: lana Date: 2014-02-06 13:28 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/eef10feca8ca Merge Changeset: 7534523b4174 Author: henryjen Date: 2014-02-06 10:30 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7534523b4174 8033590: java.util.Comparator::thenComparing has unnecessary type restriction Reviewed-by: psandoz ! src/share/classes/java/util/Comparator.java ! test/java/util/Comparator/TypeTest.java Changeset: 80568a19aab7 Author: lana Date: 2014-02-06 13:29 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/80568a19aab7 Merge From lana.steuck at oracle.com Thu Feb 6 15:47:33 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 6 Feb 2014 15:47:33 -0800 (PST) Subject: jdk8-b129: JSN, Tools, Core Libraries, Serviceability, 2d, Awt, and Swing Message-ID: <201402062347.s16NlXGM009255@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk8/jdk8/rev/1e5fe8654913 http://hg.openjdk.java.net/jdk8/jdk8/nashorn/rev/9cc3fd32fbab http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/8fe7202d3c38 http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/80568a19aab7 http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/aabc90596123 http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/b7752cea7c81 http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cb39165c4a65 http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/5c72d74c6805 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7155984 client-libs [macosx] no "os.version" read permission due missing doPrivileged() blocks JDK-8033590 core-libs java.util.Comparator::thenComparing has unnecessary type restriction From david.katleman at oracle.com Fri Feb 7 10:08:49 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:08:49 +0000 Subject: hg: jdk8/jdk8: Added tag jdk8-b129 for changeset 1e5fe8654913 Message-ID: <20140207180849.4581762ACC@hg.openjdk.java.net> Changeset: 839546caab12 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/839546caab12 Added tag jdk8-b129 for changeset 1e5fe8654913 ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:09:09 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:09:09 +0000 Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b129 for changeset 5c72d74c6805 Message-ID: <20140207180910.1AF7362ACD@hg.openjdk.java.net> Changeset: eea0d7dfcbe2 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/eea0d7dfcbe2 Added tag jdk8-b129 for changeset 5c72d74c6805 ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:10:26 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:10:26 +0000 Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b129 for changeset cb39165c4a65 Message-ID: <20140207181028.D7A5562ACE@hg.openjdk.java.net> Changeset: 1dbaf664a611 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/1dbaf664a611 Added tag jdk8-b129 for changeset cb39165c4a65 ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:12:41 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:12:41 +0000 Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b129 for changeset b7752cea7c81 Message-ID: <20140207181244.5D25A62ACF@hg.openjdk.java.net> Changeset: 0cb0cd015218 Author: katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/0cb0cd015218 Added tag jdk8-b129 for changeset b7752cea7c81 ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:13:39 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:13:39 +0000 Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b129 for changeset 80568a19aab7 Message-ID: <20140207181355.73DC762AD1@hg.openjdk.java.net> Changeset: 43386cc9a017 Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43386cc9a017 Added tag jdk8-b129 for changeset 80568a19aab7 ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:13:05 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:13:05 +0000 Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b129 for changeset aabc90596123 Message-ID: <20140207181308.480CA62AD0@hg.openjdk.java.net> Changeset: 4195c0956930 Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/4195c0956930 Added tag jdk8-b129 for changeset aabc90596123 ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:16:25 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:16:25 +0000 Subject: hg: jdk8/jdk8/nashorn: Added tag jdk8-b129 for changeset 9cc3fd32fbab Message-ID: <20140207181626.21A7462AD4@hg.openjdk.java.net> Changeset: f87eba70e9ee Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/nashorn/rev/f87eba70e9ee Added tag jdk8-b129 for changeset 9cc3fd32fbab ! .hgtags From david.katleman at oracle.com Fri Feb 7 10:16:04 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 07 Feb 2014 18:16:04 +0000 Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b129 for changeset 8fe7202d3c38 Message-ID: <20140207181608.0365362AD2@hg.openjdk.java.net> Changeset: 9d81ae1c417a Author: katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/9d81ae1c417a Added tag jdk8-b129 for changeset 8fe7202d3c38 ! .hgtags From mark.reinhold at oracle.com Tue Feb 11 14:31:52 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 Feb 2014 14:31:52 -0800 Subject: JDK 8: Second Release Candidate Message-ID: <20140211143152.649634@eggemoggin.niobe.net> Last week a serious flaw in a new API was reported [1]. We decided to fix that bug, along with an unrelated JCK failure on Mac OS X [2], so we now have a second JDK 8 Release Candidate, build 129. Binaries available here, as usual: https://jdk8.java.net/download.html - Mark [1] https://bugs.openjdk.java.net/browse/JDK-8033590 [2] https://bugs.openjdk.java.net/browse/JDK-8033642 From leventov at ya.ru Fri Feb 14 01:20:20 2014 From: leventov at ya.ru (Roman Leventov) Date: Fri, 14 Feb 2014 13:20:20 +0400 Subject: Why isEmpty(), retainAll() and containsAll() not supported with default implementations in JDK8? Message-ID: <410201392369620@web16h.yandex.ru> I'm sure there was a discussion somewhere in JDK mailing lists, but I couldn't find. Please, give me a link. I've tried to ask on SO: http://stackoverflow.com/questions/21758081/why-many-methods-in-jcf-interfaces-not-made-default-in-java-8, proved that JDK developers doesn't read SO :) From rob.mckenna at oracle.com Fri Feb 14 05:03:18 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 14 Feb 2014 13:03:18 +0000 Subject: Why isEmpty(), retainAll() and containsAll() not supported with default implementations in JDK8? In-Reply-To: <410201392369620@web16h.yandex.ru> References: <410201392369620@web16h.yandex.ru> Message-ID: <52FE1416.7080702@oracle.com> Hi Roman, I think the core-libs-dev at openjdk.java.net list would make more sense for this question. Also, you could try a google search of mail.openjdk.java.net/pipermail/core-libs-dev/ -Rob On 14/02/14 09:20, Roman Leventov wrote: > I'm sure there was a discussion somewhere in JDK mailing lists, but I couldn't find. Please, give me a link. > > I've tried to ask on SO: http://stackoverflow.com/questions/21758081/why-many-methods-in-jcf-interfaces-not-made-default-in-java-8, proved that JDK developers doesn't read SO :) From jaroslav.bachorik at oracle.com Fri Feb 14 05:12:09 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Feb 2014 14:12:09 +0100 Subject: Why isEmpty(), retainAll() and containsAll() not supported with default implementations in JDK8? In-Reply-To: <52FE1416.7080702@oracle.com> References: <410201392369620@web16h.yandex.ru> <52FE1416.7080702@oracle.com> Message-ID: <52FE1629.6020006@oracle.com> On 14.2.2014 14:03, Rob McKenna wrote: > Hi Roman, > > I think the core-libs-dev at openjdk.java.net list would make more sense > for this question. > > Also, you could try a google search of > mail.openjdk.java.net/pipermail/core-libs-dev/ > > -Rob > > On 14/02/14 09:20, Roman Leventov wrote: >> I'm sure there was a discussion somewhere in JDK mailing lists, but I >> couldn't find. Please, give me a link. >> >> I've tried to ask on SO: >> http://stackoverflow.com/questions/21758081/why-many-methods-in-jcf-interfaces-not-made-default-in-java-8, >> proved that JDK developers doesn't read SO :) Stuart Marks gave you a pretty exhausting explanation there, hasn't he? -JB- > From brendentowey at gmail.com Fri Feb 14 10:54:07 2014 From: brendentowey at gmail.com (Brenden Towey) Date: Fri, 14 Feb 2014 10:54:07 -0800 Subject: JDK 8: Second Release Candidate In-Reply-To: <20140211143152.649634@eggemoggin.niobe.net> References: <20140211143152.649634@eggemoggin.niobe.net> Message-ID: <52FE664F.8090308@gmail.com> I'd like to make a bug report. Java has had for a while now a bug in its regex system which I'd like to see fixed. The short of it is that the \z pattern does not return 'requiresEnd' and it should. public void endTest() { Matcher m = Pattern.compile( "\\z" ).matcher( "" ); m.find(); System.out.println( m.requireEnd() ); assert ( m.requireEnd() ); } This prints 'false'. It shouldn't take much thought to convince yourself that if the end of input is required, then 'requiresEnd()' should always be true. There's never a case for the \z pattern that you want to match less than all of input. The above code snippet would make a fine unit test for this bug, btw. You can see the results of this bug if you use other parts of the API, for example java.util.Scanner. Since the the requiresEnd() method always returns false, the Scanner will match its own internal buffer (usually 1024 characters) and not the end of input. public void demo() { StringBuilder str = new StringBuilder( 4 * 1024 ); for( int i = 0; i < 1024; i++ ) { str.append( i ); str.append( ',' ); } Scanner s = new Scanner( str.toString() ); String result = s.useDelimiter( "\\z" ).next(); String expected = str.toString(); System.out.println( result.length()+", "+expected.length() ); assert( expected.equals( result ) ); } Output: C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b129) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) C:\Users\Brenden\Dev\proj\Test2\build\classes>java -cp . quicktest.RegexBug 1024, 4010 You can see that the length of the matched string is 1024, not 4010 from the original string. Finally, if you need more convincing, you can test the \Z (capital Z) pattern, which does essentially the same thing as \z. \Z always sets its requiresEnd() flag, and it works as expected in the tests above. Summary: \z should always set its 'requiresEnd' flag. Thanks for taking the time to read this! On 2/11/2014 2:31 PM, mark.reinhold at oracle.com wrote: > Last week a serious flaw in a new API was reported [1]. We decided to > fix that bug, along with an unrelated JCK failure on Mac OS X [2], so > we now have a second JDK 8 Release Candidate, build 129. > > Binaries available here, as usual: https://jdk8.java.net/download.html > > From brendentowey at gmail.com Fri Feb 14 12:48:17 2014 From: brendentowey at gmail.com (Brenden Towey) Date: Fri, 14 Feb 2014 12:48:17 -0800 Subject: JDK 8: Second Release Candidate In-Reply-To: <20140211143152.649634@eggemoggin.niobe.net> References: <20140211143152.649634@eggemoggin.niobe.net> Message-ID: <52FE8111.5050105@gmail.com> Also, I have another gripe. I was reminded of this as I was installing the new Java 8 bits, and I temporarily removed the older Java 8 version. C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version java version "1.7.0_45" Java(TM) SE Runtime Environment (build 1.7.0_45-b18) Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) C:\Users\Brenden\Dev\proj\Test2\build\classes> C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b129) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) This is before and after. Notice that the Java 7 version is not updated (it should be update 51, I think, not 45). Your updater fails to update an older version if it detects a newer version of Java. That is, if the updater sees Java 8 is installed, it won't ever update Java 7 to the latest patch level. In light of all the recent bad press Java has received because of security issues (especially not updating older versions of Java) I think this is unacceptable. Always, always, always update a version of Java if is possible to do so. Sure, don't make an old version of Java the default installation, but please update the bits that are sitting on the disc. There's really no good reason not to, and if this sort of scenario ever happens (a user uninstalls a current version to expose an older version) you're left with known bad bits running on a live installation. I hope I don't have to expound on how lousy an idea that is. When you do update an older version, you need to check if *any* part of that version is still in use. For example, I don't think the Java 8 RC installs a browser plug-in, so I'm still actually using an (unupdated, old, u45) Java 7 plug-in. Getting the most recent plug-in updated to all browsers should be a high priority during a Java update. Thanks again for reading my little missive. On 2/11/2014 2:31 PM, mark.reinhold at oracle.com wrote: > Last week a serious flaw in a new API was reported [1]. We decided to > fix that bug, along with an unrelated JCK failure on Mac OS X [2], so > we now have a second JDK 8 Release Candidate, build 129. > > Binaries available here, as usual: https://jdk8.java.net/download.html > > From martijnverburg at gmail.com Sat Feb 15 05:31:24 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 15 Feb 2014 13:31:24 +0000 Subject: JDK 8: Second Release Candidate In-Reply-To: <52FE664F.8090308@gmail.com> References: <20140211143152.649634@eggemoggin.niobe.net> <52FE664F.8090308@gmail.com> Message-ID: Hi Brenden, Thanks for reporting this issue, but it should be submitted via bugs.sun.com:-). Cheers, Martijn On 14 February 2014 18:54, Brenden Towey wrote: > I'd like to make a bug report. Java has had for a while now a bug in its > regex system which I'd like to see fixed. > > The short of it is that the \z pattern does not return 'requiresEnd' and > it should. > > public void endTest() > { > Matcher m = Pattern.compile( "\\z" ).matcher( "" ); > m.find(); > System.out.println( m.requireEnd() ); > assert ( m.requireEnd() ); > } > > This prints 'false'. It shouldn't take much thought to convince yourself > that if the end of input is required, then 'requiresEnd()' should always be > true. There's never a case for the \z pattern that you want to match less > than all of input. The above code snippet would make a fine unit test for > this bug, btw. > > You can see the results of this bug if you use other parts of the API, for > example java.util.Scanner. Since the the requiresEnd() method always > returns false, the Scanner will match its own internal buffer (usually 1024 > characters) and not the end of input. > > > public void demo() > { > StringBuilder str = new StringBuilder( 4 * 1024 ); > for( int i = 0; i < 1024; i++ ) { > str.append( i ); > str.append( ',' ); > } > Scanner s = new Scanner( str.toString() ); > String result = s.useDelimiter( "\\z" ).next(); > String expected = str.toString(); > System.out.println( result.length()+", "+expected.length() ); > assert( expected.equals( result ) ); > } > > Output: > C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b129) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) > > C:\Users\Brenden\Dev\proj\Test2\build\classes>java -cp . > quicktest.RegexBug > 1024, 4010 > > You can see that the length of the matched string is 1024, not 4010 from > the original string. > > Finally, if you need more convincing, you can test the \Z (capital Z) > pattern, which does essentially the same thing as \z. \Z always sets its > requiresEnd() flag, and it works as expected in the tests above. > > Summary: \z should always set its 'requiresEnd' flag. > > Thanks for taking the time to read this! > > > > On 2/11/2014 2:31 PM, mark.reinhold at oracle.com wrote: > >> Last week a serious flaw in a new API was reported [1]. We decided to >> fix that bug, along with an unrelated JCK failure on Mac OS X [2], so >> we now have a second JDK 8 Release Candidate, build 129. >> >> Binaries available here, as usual: https://jdk8.java.net/download.html >> >> >> > > From martijnverburg at gmail.com Sat Feb 15 05:32:57 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 15 Feb 2014 13:32:57 +0000 Subject: JDK 8: Second Release Candidate In-Reply-To: <52FE8111.5050105@gmail.com> References: <20140211143152.649634@eggemoggin.niobe.net> <52FE8111.5050105@gmail.com> Message-ID: Hi Brenden, Oracle's installer is separate from OpenJDK itself, I'm afraid you'll also need to report this issue to bugs.sun.com! Cheers, Martijn On 14 February 2014 20:48, Brenden Towey wrote: > Also, I have another gripe. I was reminded of this as I was installing > the new Java 8 bits, and I temporarily removed the older Java 8 version. > > > C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > > > C:\Users\Brenden\Dev\proj\Test2\build\classes> > C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b129) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) > > This is before and after. Notice that the Java 7 version is not updated > (it should be update 51, I think, not 45). Your updater fails to update an > older version if it detects a newer version of Java. That is, if the > updater sees Java 8 is installed, it won't ever update Java 7 to the latest > patch level. In light of all the recent bad press Java has received > because of security issues (especially not updating older versions of Java) > I think this is unacceptable. > > Always, always, always update a version of Java if is possible to do so. > Sure, don't make an old version of Java the default installation, but > please update the bits that are sitting on the disc. There's really no > good reason not to, and if this sort of scenario ever happens (a user > uninstalls a current version to expose an older version) you're left with > known bad bits running on a live installation. I hope I don't have to > expound on how lousy an idea that is. > > When you do update an older version, you need to check if *any* part of > that version is still in use. For example, I don't think the Java 8 RC > installs a browser plug-in, so I'm still actually using an (unupdated, old, > u45) Java 7 plug-in. Getting the most recent plug-in updated to all > browsers should be a high priority during a Java update. > > Thanks again for reading my little missive. > > > > > > On 2/11/2014 2:31 PM, mark.reinhold at oracle.com wrote: > >> Last week a serious flaw in a new API was reported [1]. We decided to >> fix that bug, along with an unrelated JCK failure on Mac OS X [2], so >> we now have a second JDK 8 Release Candidate, build 129. >> >> Binaries available here, as usual: https://jdk8.java.net/download.html >> >> >> > From david at code.davidpcaldwell.com Mon Feb 24 10:09:31 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Mon, 24 Feb 2014 13:09:31 -0500 Subject: Update on JDK 8 builds and release candidate status In-Reply-To: References: <41AB805B-3E50-4B41-8821-3171AD85718A@oracle.com> Message-ID: <98674B6E-F961-4CA9-932B-CC5350CD2533@code.davidpcaldwell.com> Here's a bug report for b129. Mac OS X 10.8.5, although I doubt this is platform-dependent. DecimalFormatTest.java public class DecimalFormatTest { public static void main(String[] args) { System.out.println("java.version: " + System.getProperty("java.version")); System.out.println("85.55 rounded to one digit: " + new java.text.DecimalFormat("##.#").format(85.55)); } } DecimalFormatTest.sh #!/bin/bash javac -source 1.6 -target 1.6 $(dirname $0)/DecimalFormatTest.java /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java DecimalFormatTest /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java DecimalFormatTest /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java DecimalFormatTest /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java DecimalFormatTest /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -version uname -a Output: $ ./DecimalFormatTest.sh warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning java.version: 1.6.0_65 85.55 rounded to one digit: 85.6 java.version: 1.7.0_25 85.55 rounded to one digit: 85.6 java.version: 1.7.0_45 85.55 rounded to one digit: 85.6 java.version: 1.8.0 85.55 rounded to one digit: 85.5 java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b129) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) Darwin mabosdcaldwell-m1.corp.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 The DecimalFormat specification says it should use HALF_EVEN as the rounding mode. The getRoundingMode() method for the DecimalFormat (examined in debugger) does in fact return HALF_EVEN, but the output is incorrect. -- David P. Caldwell http://www.davidpcaldwell.com/ On Feb 4, 2014, at 9:31 AM, Mathias Axelsson wrote: > Hi, > > I'd like to give you an update on the below. We've promoted b128 and this > is the first release candidate build of JDK 8. b128 is available on > java.net [1] so you can download it and try it out. > > I'll continue to monitor incoming bugs. If a showstopper bug shows up that > is deemed critical for the JDK 8 release then we'll have to create a new > build to include it. > > Kind regards, > Mathias Axelsson, Oracle JDK Release Manager > > [1] https://jdk8.java.net/download.html > > On 31 jan 2014, at 12:55, Mathias Axelsson wrote: > >> Hi, >> >> It's been a while since my last update so I wanted to give you an update on >> where we are. >> >> Focus has been on getting the final RI (Reference Implementation) build for >> the Java SE 8 specification completed and ready. The current RI build is >> b126 [1] and unless any TCK blockers shows up, this build will be the RI >> for Java SE 8. >> >> With the RI build in place focus has now shifted to get the remaining >> showstopper fixes for JDK 8 into the master. We had a number of fixes lined >> up and got them integrated earlier this week so that we could do a new >> promoted build (b127). This build will be posted on java.net [2] shortly. >> >> b127 is not a release candidate build as there are still a few critical >> issues that must be fixed and integrated. I'm following up on the bugs on a >> daily basis and hope we can cut the first release candidate of JDK 8 >> shortly. >> >> I will send out an update once we have a release candidate build of JDK 8. >> >> Kind regards, >> Mathias Axelsson, Oracle JDK 8 Release Manager >> >> >> [1] https://jdk8.java.net/java-se-8-ri/ >> >> [2] https://jdk8.java.net/download.html >> > From joe.darcy at oracle.com Mon Feb 24 10:18:51 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 24 Feb 2014 10:18:51 -0800 Subject: Update on JDK 8 builds and release candidate status In-Reply-To: <98674B6E-F961-4CA9-932B-CC5350CD2533@code.davidpcaldwell.com> References: <41AB805B-3E50-4B41-8821-3171AD85718A@oracle.com> <98674B6E-F961-4CA9-932B-CC5350CD2533@code.davidpcaldwell.com> Message-ID: <530B8D0B.9040908@oracle.com> Hello, You've observed a known change in behavior: JDK-7131459 [Fmt-De] DecimalFormat produces wrong format() results when close to a tie https://bugs.openjdk.java.net/browse/JDK-7131459 The new result is actually numerically correct since the text string "85.55" does not get converted to a double value actually equal to 85.55 it is converted to a value slightly less than 85.55. HTH, -Joe On 02/24/2014 10:09 AM, David P. Caldwell wrote: > Here's a bug report for b129. Mac OS X 10.8.5, although I doubt this is platform-dependent. > > DecimalFormatTest.java > public class DecimalFormatTest { > public static void main(String[] args) { > System.out.println("java.version: " + System.getProperty("java.version")); > System.out.println("85.55 rounded to one digit: " + new java.text.DecimalFormat("##.#").format(85.55)); > } > } > > DecimalFormatTest.sh > #!/bin/bash > javac -source 1.6 -target 1.6 $(dirname $0)/DecimalFormatTest.java > /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java DecimalFormatTest > /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java DecimalFormatTest > /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java DecimalFormatTest > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java DecimalFormatTest > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -version > uname -a > > Output: > $ ./DecimalFormatTest.sh > warning: [options] bootstrap class path not set in conjunction with -source 1.6 > 1 warning > java.version: 1.6.0_65 > 85.55 rounded to one digit: 85.6 > java.version: 1.7.0_25 > 85.55 rounded to one digit: 85.6 > java.version: 1.7.0_45 > 85.55 rounded to one digit: 85.6 > java.version: 1.8.0 > 85.55 rounded to one digit: 85.5 > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b129) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) > Darwin mabosdcaldwell-m1.corp.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 > > The DecimalFormat specification says it should use HALF_EVEN as the rounding mode. The getRoundingMode() method for the DecimalFormat (examined in debugger) does in fact return HALF_EVEN, but the output is incorrect. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ > > On Feb 4, 2014, at 9:31 AM, Mathias Axelsson wrote: > >> Hi, >> >> I'd like to give you an update on the below. We've promoted b128 and this >> is the first release candidate build of JDK 8. b128 is available on >> java.net [1] so you can download it and try it out. >> >> I'll continue to monitor incoming bugs. If a showstopper bug shows up that >> is deemed critical for the JDK 8 release then we'll have to create a new >> build to include it. >> >> Kind regards, >> Mathias Axelsson, Oracle JDK Release Manager >> >> [1] https://jdk8.java.net/download.html >> >> On 31 jan 2014, at 12:55, Mathias Axelsson wrote: >> >>> Hi, >>> >>> It's been a while since my last update so I wanted to give you an update on >>> where we are. >>> >>> Focus has been on getting the final RI (Reference Implementation) build for >>> the Java SE 8 specification completed and ready. The current RI build is >>> b126 [1] and unless any TCK blockers shows up, this build will be the RI >>> for Java SE 8. >>> >>> With the RI build in place focus has now shifted to get the remaining >>> showstopper fixes for JDK 8 into the master. We had a number of fixes lined >>> up and got them integrated earlier this week so that we could do a new >>> promoted build (b127). This build will be posted on java.net [2] shortly. >>> >>> b127 is not a release candidate build as there are still a few critical >>> issues that must be fixed and integrated. I'm following up on the bugs on a >>> daily basis and hope we can cut the first release candidate of JDK 8 >>> shortly. >>> >>> I will send out an update once we have a release candidate build of JDK 8. >>> >>> Kind regards, >>> Mathias Axelsson, Oracle JDK 8 Release Manager >>> >>> >>> [1] https://jdk8.java.net/java-se-8-ri/ >>> >>> [2] https://jdk8.java.net/download.html >>> From david at code.davidpcaldwell.com Mon Feb 24 10:28:15 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Mon, 24 Feb 2014 13:28:15 -0500 Subject: Update on JDK 8 builds and release candidate status In-Reply-To: <530B8D0B.9040908@oracle.com> References: <41AB805B-3E50-4B41-8821-3171AD85718A@oracle.com> <98674B6E-F961-4CA9-932B-CC5350CD2533@code.davidpcaldwell.com> <530B8D0B.9040908@oracle.com> Message-ID: Well, I'm not an expert on floating-point standards and all of that. It may be that no other decision is possible, but I think I can predict this will confuse people. I think I'd argue for the edge case -- where the actual number being processed is the closest value to the half-way point -- to be processed as though the value actually *were* at the half-way point. (Maybe that's the way it worked before?) Thanks so much for pointing me to the issue report so that I understand what's happening. -- David. On Feb 24, 2014, at 1:18 PM, Joe Darcy wrote: > Hello, > > You've observed a known change in behavior: > > JDK-7131459 [Fmt-De] DecimalFormat produces wrong format() results when close to a tie > https://bugs.openjdk.java.net/browse/JDK-7131459 > > The new result is actually numerically correct since the text string "85.55" does not get converted to a double value actually equal to 85.55 it is converted to a value slightly less than 85.55. > > HTH, > > -Joe > > On 02/24/2014 10:09 AM, David P. Caldwell wrote: >> Here's a bug report for b129. Mac OS X 10.8.5, although I doubt this is platform-dependent. >> >> DecimalFormatTest.java >> public class DecimalFormatTest { >> public static void main(String[] args) { >> System.out.println("java.version: " + System.getProperty("java.version")); >> System.out.println("85.55 rounded to one digit: " + new java.text.DecimalFormat("##.#").format(85.55)); >> } >> } >> >> DecimalFormatTest.sh >> #!/bin/bash >> javac -source 1.6 -target 1.6 $(dirname $0)/DecimalFormatTest.java >> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java DecimalFormatTest >> /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java DecimalFormatTest >> /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java DecimalFormatTest >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java DecimalFormatTest >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -version >> uname -a >> >> Output: >> $ ./DecimalFormatTest.sh >> warning: [options] bootstrap class path not set in conjunction with -source 1.6 >> 1 warning >> java.version: 1.6.0_65 >> 85.55 rounded to one digit: 85.6 >> java.version: 1.7.0_25 >> 85.55 rounded to one digit: 85.6 >> java.version: 1.7.0_45 >> 85.55 rounded to one digit: 85.6 >> java.version: 1.8.0 >> 85.55 rounded to one digit: 85.5 >> java version "1.8.0" >> Java(TM) SE Runtime Environment (build 1.8.0-b129) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) >> Darwin mabosdcaldwell-m1.corp.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 >> >> The DecimalFormat specification says it should use HALF_EVEN as the rounding mode. The getRoundingMode() method for the DecimalFormat (examined in debugger) does in fact return HALF_EVEN, but the output is incorrect. >> >> -- David P. Caldwell >> http://www.davidpcaldwell.com/ >> >> On Feb 4, 2014, at 9:31 AM, Mathias Axelsson wrote: >> >>> Hi, >>> >>> I'd like to give you an update on the below. We've promoted b128 and this >>> is the first release candidate build of JDK 8. b128 is available on >>> java.net [1] so you can download it and try it out. >>> >>> I'll continue to monitor incoming bugs. If a showstopper bug shows up that >>> is deemed critical for the JDK 8 release then we'll have to create a new >>> build to include it. >>> >>> Kind regards, >>> Mathias Axelsson, Oracle JDK Release Manager >>> >>> [1] https://jdk8.java.net/download.html >>> >>> On 31 jan 2014, at 12:55, Mathias Axelsson wrote: >>> >>>> Hi, >>>> >>>> It's been a while since my last update so I wanted to give you an update on >>>> where we are. >>>> >>>> Focus has been on getting the final RI (Reference Implementation) build for >>>> the Java SE 8 specification completed and ready. The current RI build is >>>> b126 [1] and unless any TCK blockers shows up, this build will be the RI >>>> for Java SE 8. >>>> >>>> With the RI build in place focus has now shifted to get the remaining >>>> showstopper fixes for JDK 8 into the master. We had a number of fixes lined >>>> up and got them integrated earlier this week so that we could do a new >>>> promoted build (b127). This build will be posted on java.net [2] shortly. >>>> >>>> b127 is not a release candidate build as there are still a few critical >>>> issues that must be fixed and integrated. I'm following up on the bugs on a >>>> daily basis and hope we can cut the first release candidate of JDK 8 >>>> shortly. >>>> >>>> I will send out an update once we have a release candidate build of JDK 8. >>>> >>>> Kind regards, >>>> Mathias Axelsson, Oracle JDK 8 Release Manager >>>> >>>> >>>> [1] https://jdk8.java.net/java-se-8-ri/ >>>> >>>> [2] https://jdk8.java.net/download.html >>>> > From joe.darcy at oracle.com Mon Feb 24 10:43:23 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 24 Feb 2014 10:43:23 -0800 Subject: Update on JDK 8 builds and release candidate status In-Reply-To: References: <41AB805B-3E50-4B41-8821-3171AD85718A@oracle.com> <98674B6E-F961-4CA9-932B-CC5350CD2533@code.davidpcaldwell.com> <530B8D0B.9040908@oracle.com> Message-ID: <530B92CB.90901@oracle.com> On 02/24/2014 10:28 AM, David P. Caldwell wrote: > Well, I'm not an expert on floating-point standards and all of that. > > It may be that no other decision is possible, but I think I can predict this will confuse people. That is often unavoidable when floating-point is involved ;-) > > I think I'd argue for the edge case -- where the actual number being processed is the closest value to the half-way point -- to be processed as though the value actually *were* at the half-way point. (Maybe that's the way it worked before?) > > Thanks so much for pointing me to the issue report so that I understand what's happening. A short explanation: floating-point numbers are fundamentally discrete values. Since Java uses IEEE 754 double values, the representable floating-point numbers are sums of powers of two. Consequently, many interesting decimal fractions cannot be exactly represented. A finite floating-point number represents some particular point on the real number line, say x. Under the round to nearest even rounding mode, a range of the real number line, some values less than x and some values greater than x, get rounded to x. Once you have x, you don't have any history about where x came from, maybe it was exactly computed, maybe the exact result before roundoff was greater than x, maybe it was less than. The most reasonable thing to do is to assume the value you have now is exact for the purposes of future computation and carry on. Therefore, once "85.55" is converted to a double value, the fact that is came from "85.55" is lost. Now it is some numerical value slightly less than 85.55 and should be treated accordingly. For exact computation on decimal quantities, BigDecimal should be used instead of double. For some more general information about floating-point see: "What Every Computer Programmer Should Know about Floating-Point Arithmetic" https://blogs.oracle.com/darcy/resource/Wecpskafpa-ACCU.pdf Cheers, -Joe > > -- David. > On Feb 24, 2014, at 1:18 PM, Joe Darcy wrote: > >> Hello, >> >> You've observed a known change in behavior: >> >> JDK-7131459 [Fmt-De] DecimalFormat produces wrong format() results when close to a tie >> https://bugs.openjdk.java.net/browse/JDK-7131459 >> >> The new result is actually numerically correct since the text string "85.55" does not get converted to a double value actually equal to 85.55 it is converted to a value slightly less than 85.55. >> >> HTH, >> >> -Joe >> >> On 02/24/2014 10:09 AM, David P. Caldwell wrote: >>> Here's a bug report for b129. Mac OS X 10.8.5, although I doubt this is platform-dependent. >>> >>> DecimalFormatTest.java >>> public class DecimalFormatTest { >>> public static void main(String[] args) { >>> System.out.println("java.version: " + System.getProperty("java.version")); >>> System.out.println("85.55 rounded to one digit: " + new java.text.DecimalFormat("##.#").format(85.55)); >>> } >>> } >>> >>> DecimalFormatTest.sh >>> #!/bin/bash >>> javac -source 1.6 -target 1.6 $(dirname $0)/DecimalFormatTest.java >>> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java DecimalFormatTest >>> /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java DecimalFormatTest >>> /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java DecimalFormatTest >>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java DecimalFormatTest >>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -version >>> uname -a >>> >>> Output: >>> $ ./DecimalFormatTest.sh >>> warning: [options] bootstrap class path not set in conjunction with -source 1.6 >>> 1 warning >>> java.version: 1.6.0_65 >>> 85.55 rounded to one digit: 85.6 >>> java.version: 1.7.0_25 >>> 85.55 rounded to one digit: 85.6 >>> java.version: 1.7.0_45 >>> 85.55 rounded to one digit: 85.6 >>> java.version: 1.8.0 >>> 85.55 rounded to one digit: 85.5 >>> java version "1.8.0" >>> Java(TM) SE Runtime Environment (build 1.8.0-b129) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) >>> Darwin mabosdcaldwell-m1.corp.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 >>> >>> The DecimalFormat specification says it should use HALF_EVEN as the rounding mode. The getRoundingMode() method for the DecimalFormat (examined in debugger) does in fact return HALF_EVEN, but the output is incorrect. >>> >>> -- David P. Caldwell >>> http://www.davidpcaldwell.com/ >>> >>> On Feb 4, 2014, at 9:31 AM, Mathias Axelsson wrote: >>> >>>> Hi, >>>> >>>> I'd like to give you an update on the below. We've promoted b128 and this >>>> is the first release candidate build of JDK 8. b128 is available on >>>> java.net [1] so you can download it and try it out. >>>> >>>> I'll continue to monitor incoming bugs. If a showstopper bug shows up that >>>> is deemed critical for the JDK 8 release then we'll have to create a new >>>> build to include it. >>>> >>>> Kind regards, >>>> Mathias Axelsson, Oracle JDK Release Manager >>>> >>>> [1] https://jdk8.java.net/download.html >>>> >>>> On 31 jan 2014, at 12:55, Mathias Axelsson wrote: >>>> >>>>> Hi, >>>>> >>>>> It's been a while since my last update so I wanted to give you an update on >>>>> where we are. >>>>> >>>>> Focus has been on getting the final RI (Reference Implementation) build for >>>>> the Java SE 8 specification completed and ready. The current RI build is >>>>> b126 [1] and unless any TCK blockers shows up, this build will be the RI >>>>> for Java SE 8. >>>>> >>>>> With the RI build in place focus has now shifted to get the remaining >>>>> showstopper fixes for JDK 8 into the master. We had a number of fixes lined >>>>> up and got them integrated earlier this week so that we could do a new >>>>> promoted build (b127). This build will be posted on java.net [2] shortly. >>>>> >>>>> b127 is not a release candidate build as there are still a few critical >>>>> issues that must be fixed and integrated. I'm following up on the bugs on a >>>>> daily basis and hope we can cut the first release candidate of JDK 8 >>>>> shortly. >>>>> >>>>> I will send out an update once we have a release candidate build of JDK 8. >>>>> >>>>> Kind regards, >>>>> Mathias Axelsson, Oracle JDK 8 Release Manager >>>>> >>>>> >>>>> [1] https://jdk8.java.net/java-se-8-ri/ >>>>> >>>>> [2] https://jdk8.java.net/download.html >>>>> From lana.steuck at oracle.com Wed Feb 26 19:19:20 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 27 Feb 2014 03:19:20 +0000 Subject: hg: jdk8/jdk8/corba: 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only Message-ID: <20140227031922.C28BC62F88@hg.openjdk.java.net> Changeset: 0683ee308085 Author: coffeys Date: 2014-02-26 23:04 +0000 URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/0683ee308085 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only Reviewed-by: mchung, chegar ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java From david.katleman at oracle.com Fri Feb 28 10:20:24 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:20:24 +0000 Subject: hg: jdk8/jdk8: Added tag jdk8-b130 for changeset 839546caab12 Message-ID: <20140228182024.5F8FB62391@hg.openjdk.java.net> Changeset: 0c38dfecab2a Author: katleman Date: 2014-02-28 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/0c38dfecab2a Added tag jdk8-b130 for changeset 839546caab12 ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:20:44 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:20:44 +0000 Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b130 for changeset 0683ee308085 Message-ID: <20140228182045.D8B2E62392@hg.openjdk.java.net> Changeset: 5e5c8f0c45dd Author: katleman Date: 2014-02-28 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/5e5c8f0c45dd Added tag jdk8-b130 for changeset 0683ee308085 ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:22:50 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:22:50 +0000 Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b130 for changeset 1dbaf664a611 Message-ID: <20140228182253.75D5462393@hg.openjdk.java.net> Changeset: b5e7ebfe185c Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b5e7ebfe185c Added tag jdk8-b130 for changeset 1dbaf664a611 ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:25:33 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:25:33 +0000 Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b130 for changeset 0cb0cd015218 Message-ID: <20140228182537.3D28262394@hg.openjdk.java.net> Changeset: 79d8b7fac21d Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/79d8b7fac21d Added tag jdk8-b130 for changeset 0cb0cd015218 ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:25:58 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:25:58 +0000 Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b130 for changeset 4195c0956930 Message-ID: <20140228182601.8168F62395@hg.openjdk.java.net> Changeset: 012b935707fa Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/012b935707fa Added tag jdk8-b130 for changeset 4195c0956930 ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:26:28 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:26:28 +0000 Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b130 for changeset 43386cc9a017 Message-ID: <20140228182645.B033D62396@hg.openjdk.java.net> Changeset: b07a8059dc08 Author: katleman Date: 2014-02-28 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b07a8059dc08 Added tag jdk8-b130 for changeset 43386cc9a017 ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:29:41 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:29:41 +0000 Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b130 for changeset 9d81ae1c417a Message-ID: <20140228182945.655F162399@hg.openjdk.java.net> Changeset: 196ab3dcbd28 Author: katleman Date: 2014-02-28 10:08 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/196ab3dcbd28 Added tag jdk8-b130 for changeset 9d81ae1c417a ! .hgtags From david.katleman at oracle.com Fri Feb 28 10:30:07 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 28 Feb 2014 18:30:07 +0000 Subject: hg: jdk8/jdk8/nashorn: Added tag jdk8-b130 for changeset f87eba70e9ee Message-ID: <20140228183008.D1C2E6239A@hg.openjdk.java.net> Changeset: cca9748cfec7 Author: katleman Date: 2014-02-28 10:09 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/nashorn/rev/cca9748cfec7 Added tag jdk8-b130 for changeset f87eba70e9ee ! .hgtags From lana.steuck at oracle.com Fri Feb 28 11:52:22 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 28 Feb 2014 19:52:22 +0000 Subject: hg: jdk8/jdk8/jdk: 2 new changesets Message-ID: <20140228195308.7C4D1623AD@hg.openjdk.java.net> Changeset: 183a8c520b4a Author: rfield Date: 2014-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/183a8c520b4a 8035777: Consistent Lambda construction Reviewed-by: ahgross, briangoetz, dlsmith ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaReceiver.java + test/java/lang/invoke/lambda/LambdaReceiverBridge.java + test/java/lang/invoke/lambda/LambdaReceiver_anotherpkg/LambdaReceiver_A.java + test/java/lang/invoke/lambda/LambdaReturn.java + test/java/lang/invoke/lambda/MetafactoryArityTest.java + test/java/lang/invoke/lambda/MetafactoryParameterCastTest.java + test/java/lang/invoke/lambda/MetafactorySamReturnTest.java Changeset: e291ac47c9a9 Author: lana Date: 2014-02-28 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e291ac47c9a9 Merge From david.katleman at oracle.com Fri Feb 28 20:21:52 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:21:52 +0000 Subject: hg: jdk8/jdk8: Added tag jdk8-b131 for changeset 0c38dfecab2a Message-ID: <20140301042152.EE7756241F@hg.openjdk.java.net> Changeset: 2a8f4c022aa0 Author: katleman Date: 2014-02-28 13:35 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/rev/2a8f4c022aa0 Added tag jdk8-b131 for changeset 0c38dfecab2a ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:22:02 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:22:02 +0000 Subject: hg: jdk8/jdk8/corba: Added tag jdk8-b131 for changeset 5e5c8f0c45dd Message-ID: <20140301042203.4400E62420@hg.openjdk.java.net> Changeset: 84fed37bbe64 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/84fed37bbe64 Added tag jdk8-b131 for changeset 5e5c8f0c45dd ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:24:48 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:24:48 +0000 Subject: hg: jdk8/jdk8/hotspot: Added tag jdk8-b131 for changeset b5e7ebfe185c Message-ID: <20140301042450.E17B562421@hg.openjdk.java.net> Changeset: 5380dc5d007e Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/5380dc5d007e Added tag jdk8-b131 for changeset b5e7ebfe185c ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:29:14 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:29:14 +0000 Subject: hg: jdk8/jdk8/jaxp: Added tag jdk8-b131 for changeset 79d8b7fac21d Message-ID: <20140301042916.DE16F62422@hg.openjdk.java.net> Changeset: 5993346020d1 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/5993346020d1 Added tag jdk8-b131 for changeset 79d8b7fac21d ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:29:25 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:29:25 +0000 Subject: hg: jdk8/jdk8/jaxws: Added tag jdk8-b131 for changeset 012b935707fa Message-ID: <20140301042927.D4A8262423@hg.openjdk.java.net> Changeset: c2be0dd15dbf Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/c2be0dd15dbf Added tag jdk8-b131 for changeset 012b935707fa ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:29:40 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:29:40 +0000 Subject: hg: jdk8/jdk8/jdk: Added tag jdk8-b131 for changeset e291ac47c9a9 Message-ID: <20140301042952.2412362424@hg.openjdk.java.net> Changeset: 43cb25339b55 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43cb25339b55 Added tag jdk8-b131 for changeset e291ac47c9a9 ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:31:49 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:31:49 +0000 Subject: hg: jdk8/jdk8/langtools: Added tag jdk8-b131 for changeset 196ab3dcbd28 Message-ID: <20140301043152.6E40562425@hg.openjdk.java.net> Changeset: c8a87a58eb3e Author: katleman Date: 2014-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/c8a87a58eb3e Added tag jdk8-b131 for changeset 196ab3dcbd28 ! .hgtags From david.katleman at oracle.com Fri Feb 28 20:32:00 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Sat, 01 Mar 2014 04:32:00 +0000 Subject: hg: jdk8/jdk8/nashorn: Added tag jdk8-b131 for changeset cca9748cfec7 Message-ID: <20140301043201.BF27C62426@hg.openjdk.java.net> Changeset: 5dbdae28a6f3 Author: katleman Date: 2014-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/jdk8/nashorn/rev/5dbdae28a6f3 Added tag jdk8-b131 for changeset cca9748cfec7 ! .hgtags