Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

On Apr 14 2014, at 18:25 , Martin Buchholz wrote: > I'll retreat to being neutral on the overall idea. > > In general, it *is* a best software engineering practice to do all the > reading and computing before doing all the writing at the end. > > You'll break anyone who does the crazy thing o

Re: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Apr 15, 2014, at 9:24 AM, Brian Burkhalter wrote: > On Apr 15, 2014, at 12:23 AM, Paul Sandoz wrote: > >> My inclination is "if it ain't broke... " and AFAICT nothing indicates >> toString it is particular broken [*], so perhaps just focus on the cleanup >> aspects and revisit the other

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

On 04/15/14 16:47, Ulf Zibis wrote: But where are the original attachments e.g. webrevs, patches ? Are they lost forever ? No, they are there on the new JBS bug reports. For some reason they are not visible to users outside Oracle. I will see if that can be changed. Regards- Tim

Re: String.indexOf optimization

Hi everyone! On 04.04.2014 21:13, Martin Buchholz wrote: Summary: Many people (myself included) have looked at this problem. It's unlikely that String.indexOf will change. It's hard to beat the naive implementation in the typical case. But we can try to speed up this naive implementation a l

Re: Covariant overrides on the Buffer Hierachy

Hi, Am 15.04.2014 10:05, schrieb Richard Warburton: Hi, I'd like to have a discussion about tidying up a few core library method signatures in a way that (I think) is backwards compatible. I've been using ByteBuffer quite a lot recently which is designed to be a fluent API. Unfortunately its q

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

On 4/14/14 8:48 PM, Xueming Shen wrote: Hi, webrev has been updated to use the name space jdk.nio.zipfs. http://cr.openjdk.java.net/~sherman/8038500/webrev/ This patch looks fine. JarFileSystemProvider is currently not used and it's fine to include it as it will need discussion to decide if

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Am 10.04.2014 21:53, schrieb Tim Bell: On 04/10/14 19:26, Ulf Zibis wrote: BTW, where are these links gone: This part of the question I can handle. The six digit Bug numbers came from the legacy OpenJDK bugzilla instance. Before it was shut down, those bug reports were transferred to JBS. In

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Hi David, yes, it's the intent to make it only available in full jre, for now. Thanks! -Sherman On 4/15/14 12:22 AM, David Holmes wrote: Hi Sherman, Can you confirm that the intent is that this remains only available in a full JRE and not in any Compact Profile? Thanks, David On 15/04/201

Re: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

Hi Paul, On Apr 15, 2014, at 12:23 AM, Paul Sandoz wrote: > Hi Brian, > > My inclination is "if it ain't broke... " and AFAICT nothing indicates > toString it is particular broken [*], so perhaps just focus on the cleanup > aspects and revisit the other when the JMM is updated (and maybe enha

Re: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

thanks! On 15.04.2014 17:24, Lance Andersen wrote: looks ok On Apr 15, 2014, at 9:11 AM, alexander stepanov > wrote: Sorry, the webrev was updated to include one other minor change in javax/script/ScriptEngineFactory.java to avoid creation of separate

Re: [9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

looks ok On Apr 15, 2014, at 9:11 AM, alexander stepanov wrote: > Sorry, the webrev was updated to include one other minor change in > javax/script/ScriptEngineFactory.java to avoid creation of separate review > request: > http://cr.openjdk.java.net/~yan/8030709/webrev.01/ > > Regards, > Alex

[9] Review Request for 8030709: Tidy warnings cleanup for java.lang package

Sorry, the webrev was updated to include one other minor change in javax/script/ScriptEngineFactory.java to avoid creation of separate review request: http://cr.openjdk.java.net/~yan/8030709/webrev.01/ Regards, Alexander On 10.04.2014 12:24, alexander stepanov wrote: > BigInteger.java from ja

Re: RFR: [8039396] NPE when writing a class descriptor object to a custom ObjectOutputStream

Thank you Alan! I'll reformat the test before pushing to make it fit into the half of the screen. Sincerely yours, Ivan On 15.04.2014 12:56, Alan Bateman wrote: On 11/04/2014 09:01, Ivan Gerasimov wrote: Hello everybody! ObjectStreamClass#forClass() function is allowed to return null, if

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

On 15/04/2014 04:48, Xueming Shen wrote: Hi, webrev has been updated to use the name space jdk.nio.zipfs. http://cr.openjdk.java.net/~sherman/8038500/webrev/ Thanks, I think this makes sense. For further down the road then consideration could be given to make ZipFileAttributes/ZipFileAttrib

Re: RFR: [8039396] NPE when writing a class descriptor object to a custom ObjectOutputStream

On 11/04/2014 09:01, Ivan Gerasimov wrote: Hello everybody! ObjectStreamClass#forClass() function is allowed to return null, if the local VM does not have the corresponding local class. Because of that, NPE can be encountered during serialization through a subclass of ObjectOutputStream. Wou

Re: Improve timezone mapping for AIX platform

You can push it to jdk9-dev directly. No other reviewer is required. Regards, Volker On Tue, Apr 15, 2014 at 9:48 AM, Jonathan Lu wrote: > Hi Masayoshi, Volker, > > Thanks a lot for reviewing ! > Is it OK for me to push the change into JDK9 directly ? or need another > reviewer's approval ? > >

Re: Covariant overrides on the Buffer Hierachy

On 15/04/2014 09:05, Richard Warburton wrote: : The only issue that I'm aware of that is related to this kind of change is the requirement to recompile all the classes in the hierarchy when making a change [0]. If you don't do this its possible for an infinite recursion and eventual stackoverflo

Covariant overrides on the Buffer Hierachy

Hi, I'd like to have a discussion about tidying up a few core library method signatures in a way that (I think) is backwards compatible. I've been using ByteBuffer quite a lot recently which is designed to be a fluent API. Unfortunately its quite inconvenient to use because there's a hierarchy of

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Hello Sherman, The build changes look good to me. /Erik On 2014-04-14 19:52, Xueming Shen wrote: Thanks Mandy and Alan for the review. webrev has been updated accordingly to (1) Removed the basic.sh. The tests are now using test.jdk to access the zipfs.jar directly (2) Updated most of the c

Re: Improve timezone mapping for AIX platform

Hi Masayoshi, Volker, Thanks a lot for reviewing ! Is it OK for me to push the change into JDK9 directly ? or need another reviewer's approval ? Many thanks Jonathan On Mon, Apr 14, 2014 at 2:03 PM, Masayoshi Okutsu < masayoshi.oku...@oracle.com> wrote: > Looks good to me. > > Thanks, > Masa

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

On Apr 15, 2014, at 12:54 AM, Mike Duigou wrote: > Should we proceed forward despite these understood limitations? My vote is a > very soft "Yes". > I think we can proceed, things are not made any worse for the cases we care about, and i think we can slightly improve things as Martin suggests,

Re: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again

On 15/04/2014 4:54 PM, Daniel Fuchs wrote: Hi guys, Should 'actual' and 'reference' be declared as volatile? I see that they are accessed from main() after joining the threads. Or does joining the threads guarantees that 'main' will see the right values? Yes. If you join() a Thread you are g

Re: PING! Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

Hi Brian, My inclination is "if it ain't broke... " and AFAICT nothing indicates toString it is particular broken [*], so perhaps just focus on the cleanup aspects and revisit the other when the JMM is updated (and maybe enhanced volatiles is ready)? Paul. [*] although i still question the us

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Hi Sherman, Can you confirm that the intent is that this remains only available in a full JRE and not in any Compact Profile? Thanks, David On 15/04/2014 1:48 PM, Xueming Shen wrote: Hi, webrev has been updated to use the name space jdk.nio.zipfs. http://cr.openjdk.java.net/~sherman/803850