Re: Incorrect validation of DST in java.util.SimpleTimeZone

AFAICS SimpleTimeZone is simply not thread-safe. It has state that can be modified concurrently without synchronization and with fields not even declared volatile. Only the "cache" makes an attempt to use synchronization. So clone() is never guaranteed to actually produce a copy with

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Thanks Sean. I am pasting the patch here: --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 2017-11-11 11:17:38.643867420 +0530 +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 2017-11-11 11:17:38.375870421 +0530 @@ -868,7 +868,11 @@   */ public

Re: Change in properties for logging: deliberate?

Hi Jeremy, On 10/11/17 23:24, Jeremy Manson wrote: Thanks for the attention, Daniel.  You may want to consider adjusting it so that the behavior of .level and .handlers are consistent with each other, if they aren't...  I don't think that should break anyone significantly. I think the way

Re: Change in properties for logging: deliberate?

Hi Jeremy, I will propose a fix then. However be aware that logging configuration files that use ".handlers" instead of "handlers" to configure the root logger are fragile, as it seems that any subsequent call to LogManager.readConfiguration() will remove this configuration. Though I agree this

Re: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

On 11/10/17 1:55 AM, Jaroslav Tulach wrote: Hi. I believe I have a fix for JDK-8189116 - the jdk.internal.vm.compiler.management needs only few permissions as shown in my webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/ The change looks fine.  This mainly depends on the test

Re: Change in properties for logging: deliberate?

Can’t you just deprecate java.util.logging? While I am half kidding, can someone explain why it doesn’t use a ServiceLoader to locate the LogManager implementation? Ralph > On Nov 10, 2017, at 9:04 AM, Daniel Fuchs wrote: > > Hi Jason, > > I have done a few tests

Re: Change in properties for logging: deliberate?

Hi Jason, I have done a few tests with JDK 8 & 7. I have created custom handlers and added some debug traces in their constructors and debug methods. Then I have added these two lines to my logging.properties: handlers = custom.Handler .handlers = custom.DotHandler What I see is this: - the

Re: Incorrect validation of DST in java.util.SimpleTimeZone

I think the OpenJDK mailing lists accept attachments if in patch format. If it's a simple short patch, it's acceptable to paste it into email body. Easiest solution is to use webrev[1]. If you can't upload this to cr.openjdk.java.net - then one of your colleagues may be able to help. [1]

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Hello! Looks good to me, thanks! With best regards, Tagir Valeev. 9 нояб. 2017 г. 4:02 AM пользователь "Paul Sandoz" написал: > Hi, > > Please review this patch to ensure that a parallel stream obeys the > parallelism of a custom fork join pool when it is executed

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Looks like the patch attached earlier is not visible. As this is my first contribution, please let me know how I can send the patch for review. On 10/11/17 5:37 PM, Venkateswara R Chintala wrote: Hi, In a multi-threaded environment, when java.util.SimpleTimeZone object is used to create a

Incorrect validation of DST in java.util.SimpleTimeZone

Hi, In a multi-threaded environment, when java.util.SimpleTimeZone object is used to create a default timezone, there can be a race condition between the methods java.util.Timezone.getDefault() and java.util.Timezone.getDefaultRef() which can result in inconsistency of cache that is used to

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

On Thu, Nov 9, 2017 at 8:06 PM, Paul Sandoz wrote: > Hi Volker, > >> On 9 Nov 2017, at 01:01, Volker Simonis wrote: >> >> Hi Paul, >> >> just some quick process-related questions. >> >> Is this intended to be targeted for jdk 10? >> > > Yes,

RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

Hi. I believe I have a fix for JDK-8189116 - the jdk.internal.vm.compiler.management needs only few permissions as shown in my webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/ I have executed all the tests I found and it seems none of them regressed. Also the Graal Compiler MX

Re: JDK-8067661: transferTo proposal for Appendable

An updated webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01 > A few comments: > > Readable.java: > 67: + it may be worth mentioning that the input might not fit in output (as > seen in the CharBuffer case) > Though I see we didn’t call that out in the other transferTo

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

On 10.11.2017 0:13, Paul Sandoz wrote: <...> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don’t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi Stuart, After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would seem to me a logical enhancement in the sense of the existing