Re: RFR: 8277090 : jsr166 refresh for jdk19

Hi Alan, >Is this a Future implementation that doesn't implement the spec >correctly? The get method shouldn't throw CancellationException if done >and not-cancelled. What you say makes sense. I should have checked this before I brought it up but CancellationException is an

Re: RFR: 8277090 : jsr166 refresh for jdk19

Hi Doug, In Future::exceptionNow() and Future::state() I would think we would want to catch CancellationException since the implementation of the Future is not known. Even though we pre-screen the state I would imagine there could be an implementation that prefers cancellation over normal

Re: fast way to infer caller

Perhaps https://bugs.openjdk.java.net/browse/JDK-4515935 for the MemoryHandler could be used to determine if StackWalker is fast enough for the lowest rung on the StackWalker performance ladder. Currently the MemoryHandler doesn't not infer the caller and the target handler sees the callsite

Re: fast way to infer caller

Ceki, Looks like the benchmark code is from https://github.com/qos-ch/slf4j/pull/271 Looks like the benchmark code is doing a collection so perhaps that is some of the performance hit? Have you benchmarked java.util.LogRecord.getSourceClassName() to compare with your StackWalker benchmark?

Re: OutputStreamWriter (not) flushing stateful Charsetencoder

Here are the old details I can dig up when we ran into this on JavaMail: https://bugs.openjdk.java.net/browse/JDK-6995537 https://github.com/javaee/javamail/commit/145d18c1738d3cf33b52bc005835980ff78ce4af I recall digging through the code years ago and I don't recall if adding w.write("");

Re: Monitoring wrapped ThreadPoolExecutor returned from Executors

Hi Doug, What are your thoughts on promoting monitoring methods from TPE and or FJP to AbstractExecutorService? The default implementations could just return -1. An example precedent is OperatingSystemMXBean::getSystemLoadAverage. The Executors.DelegatedExecutorService could then be

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v4]

Ian, Should IllegalFormatArgumentIndexException.java provide an override of getMessage? It appears that is done in the following: https://github.com/openjdk/jdk/blob/9b07ef33b6e07afae1a8bfa034200eb3aab1f94f/src/java.base/share/classes/java/util/IllegalFormatWidthException.java

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Yu Li, You should consider changing the equals implementation to include an identity self check. public boolean equals(Object o) { return this == o || entrySet.equals(o); } This is consistent with the collection wrapper classes in j.u.Collections. Jason

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

: Alan Snyder Sent: Wednesday, May 20, 2020 1:53 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes Do you believe that Set.equals() should behave this way on SortedSets? On May 20, 2020, at 11

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

ring or unwrap to find a singleton. //Avoid calling equals on comparator. return Collections.reverseOrder(s1.comparator()) == Collections.reverseOrder(s2.comparator()); } } Jason ________ From: Alan Snyder Sent: Thursd

Re: RFR: 8215401: Add isEmpty default method to CharSequence

Claes, I would think CharBuffer would require some testing in your test cases too. Also it looks like some of the CharSequence methods in CharBuffer are declared final. Not sure what is appropriate here as far as CharBuffer::isEmpty modifiers are concerned. Jason

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

e.removeIf(e -> removals.contains(e)); long end = System.currentTimeMillis(); System.out.println("Time taken: " + (end - start) + "ms " + modified); } Jason From: Stuart Marks Sent: Tuesday, May 12, 2020 3:34 PM To: Jason Mehrens Cc:

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

HashSet/TreeSet could do what ConcurrentHashMap/ConcurrentSkipListSet do by using the "this contains that and that contains this" logic. Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new ConcurrentHashMap().keySet(""); Set s2 = new ConcurrentSkipListSet<>(cc);

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Marks Sent: Monday, May 4, 2020 7:25 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes On 5/1/20 10:41 PM, Jason Mehrens wrote: > 1. I assume you are using "c instanceof List&qu

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If

Re: Collections.synchronizedXXX() and internal mutex (aka SyncRoot)

Background on this can be found here: https://bugs.openjdk.java.net/browse/JDK-4335520 Jason From: core-libs-dev on behalf of dmytro sheyko Sent: Wednesday, April 29, 2020 2:58 AM To: core-libs-dev Subject: Collections.synchronizedXXX() and internal

Re: LinkedHashMap/LinkedHashSet enhancement: OrderedMap/OrderedSet

Looks like It is intentional that unmodifiable queues are not present. See: https://bugs.openjdk.java.net/browse/JDK-5030930. The same logic would have been used for when Deque was added in the following release. Jason From: core-libs-dev on behalf

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Would it work to fix this by making DeleteOnExitHook::runHooks deal with dependencies? 1. Remove If deleted, or not directory which also takes care of not exists. 2. Sort remaining files by deepest child files/directories first. 3. Run delete again on the list. Otherwise files need to be

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Would the SecurityManager need to for permissions (checkWrite or some new permission) before cancelDeleteOnExit() is allowed? Jason From: core-libs-dev on behalf of Brian Burkhalter Sent: Tuesday, July 9, 2019 1:08 PM To: core-libs-dev Subject: Re:

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Brian, Just a note, one issue I see with webrev.01 is that JDK-7092892 is not resolved. On one hand more calls to DeleteOnExitHook should trigger class init sooner avoiding the issue. On the other it seems this could be more methods that could fail by throwing ExceptionInInitializerError

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Brian, Previously File.delete wouldn't throw IllegalStateException and with this patch it looks like that is possible (and not desirable). I would think that this change could the break java.util.logging.FileHandler because Handler.close runs in a shutdown hook. Jason

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Maybe rename the catch variable from 'cause' or 'ignored' to 'unreachable' and then wrap java.io.IOException in java.io.IOError? From: core-libs-dev on behalf of Raffaello Giulietti Sent: Thursday, April 18, 2019 3:37 PM To: Brian Burkhalter;

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi Goetz, Looking at the test cases I didn't see any tests for the single argument java.util.Objects.requireNonNull. Using this prototype is that method treated like a hidden frame? Cheers, Jason From: core-libs-dev on behalf of Lindenmaier, Goetz

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi Goetz, For NullPointerException, I don't think you want writeReplace() to call a public method that can be overridden. You probably should create a private helper method that both getMessage and writeReplace() call into. Jason From: core-libs-dev

Re: java.lang.CharSequence#compare - lexicographical ordering of custom Comparable CharSequence(s)

Hi Peter, The initial implementation was only optimized to call into String.compare if the arguments were string [1]. I proposed the current code a general form to catch java.nio.CharBuffer and any new JDK implementations of CharSequence + Comparable. Naively, I lean towards "- CharSequence

Re: Proposal: ArrayList constructor perforrmance improvement

>Sorry for not having remembered the history. **Start the wavy motion effect because we are going back in time! == Date: Wed, 27 Sep 2006 16:49:47 -0700 From: Martin Buchholz Subject: 6347106 (coll) Make ArrayList(Collection) more threadsafe Sender: To: Jason Mehrens Hi Jason, Tha

Re: Proposal: ArrayList constructor perforrmance improvement

The reason the patched code is faster is because it will avoid an array resize that is triggered in the benchmark by: "// once a new ArrayList is created add a new element al.add(new Integer(900));" http://cr.openjdk.java.net/~sgroeger/perf/arraylist/ArrayListBenchmark.java If you look

Re: Proposal: ArrayList constructor perforrmance improvement

Hi Steve, >ArrayList has a constructor which takes an arbitrary Collection as a >parameter. This constructor will create an iterator over the collection >;and it will add each entry returned to the ArrayList. >We have found that quite a lot of the time the object passed as a >parameter is in

Re: RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given

Looks good. I like the change of making setCause final. Jason From: mandy chung Sent: Thursday, September 13, 2018 3:50 PM To: Jason Mehrens; joe darcy; Peter Levart Cc: core-libs-dev Subject: Re: RFR JDK-8209553: ExceptionInInitializerError can have

Re: RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given

Hi Mandy, Like in previous patches, I advocated for using 'super.getCause()' in writeObject to avoid any subclass hooking into serialization. I even lean towards the legacy getXXX methods call super.getCause too so they are compatible with previous behavior. Does Throwable.setCause need a

Re: RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given

Hi Mandy, This what we were doing in the past and has examples of removing fields with expected tests: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html However, this case is a little

Re: RFR JDK-8066709 Make some JDK system properties read only

Roger, Looks like StaticProperty.initProperty is never called. I assume that was suppose to be called on lines 40-43? Jason From: core-libs-dev on behalf of Roger Riggs Sent: Tuesday, June 5, 2018 9:18 AM To: Stuart Marks Cc: Core-Libs-Dev Subject:

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Looks good. Jason From: Joe Wang <huizhe.w...@oracle.com> Sent: Monday, February 12, 2018 12:25 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer Done.

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks, Joe On 2/2/2018 12:46 PM, Joe Wang wrote: > Thanks Jason. Will update that accordingly. > > Best, > Joe > > On 2/2/2018 11:22 AM, Jason Mehrens wrote: >> Joe, >> >> The identity check in CS.compare makes sense. However, it won't be >> null hos

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Aleksei, Looks good to me. Jason From: Aleks Efimov <aleksej.efi...@oracle.com> Sent: Wednesday, February 7, 2018 7:24 PM To: Roger Riggs; Jason Mehrens Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR [11] (JAXP): 6857903: SAXException.ini

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

From: Aleks Efimov <aleksej.efi...@oracle.com> Sent: Monday, February 5, 2018 8:46 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception Thank you for your comments, Jason! New webr

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

in readObject. That keeps the readObject contract intact in case something malicious is going on. That is just my preference though. Jason From: Aleks Efimov <aleksej.efi...@oracle.com> Sent: Monday, February 5, 2018 10:51 AM To: Jason Mehrens;

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Joe, The identity check in CS.compare makes sense. However, it won't be null hostile if we call CS.compare(null, null) and that doesn't seem right. Usually when writing comparator classes I end up with: === if (Objects.requireNonNull(o1) == Objects.requireNonNull(o2)) { return 0; } ===

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Joe, 1. Seems odd that StringBuilder and StringBuffer are comparable but don't have an equals/hashcode implementation. Seems like if you are to stick with that you'll have to add the standard "natural ordering is inconsistent with equals" verbiage. 2. For StringBuffer compare, won't you have to

Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

Looks great! Personally, these LogManager startup issues make my head hurt. :) Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Tuesday, January 23, 2018 1:13 PM To: Jason Mehrens; core-libs-dev@openjdk.java.net Cc: Mandy Chung Subject: Re

Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

Daniel, Fantastic! The patch looks good as is. The only thing that sticks out is that both the 'if' and the 'else if' have the same code inside them. That could be refactored a bit. Jason From: core-libs-dev on

Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

Not my call but adding addInitialRootLoggerHandlers() seems too much like a private detail that would be forever published as part of the public API. I would rather have have a protected reportError added to LogManager and redirect all internal errors from directly calling System.err to that

Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

p the read of "handlers" eager. Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday, January 19, 2018 4:13 AM To: Jason Mehrens; core-libs-dev Subject: Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager

Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

er. best regards, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8195096 On 19/01/2018 10:13, Daniel Fuchs wrote: > Hi Jason, > > On 18/01/2018 21:19, Jason Mehrens wrote: >> Daniel, >> >> As long as the org.apache.juli.ClassLoaderLogManager overrides >

Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

Daniel, As long as the org.apache.juli.ClassLoaderLogManager overrides getProperty it shouldn't really matter what the value format is in the file as long as it is translated on return. Is there a code path in j.u.l.LogManager that doesn't call getProperty? If so I would think that is the

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

What are your thoughts on pushing the static EMPTY_XXX declarations from ImmutableCollections down in to each respective inner class? Doing that should allow for on demand class loading instead of getting everything when any factory is used.

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Aleksei, You have to override all of the constructors to always disable initCause. Actually a similar issue was covered in: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html Pretty much

Re: RFR 4358774: Add null InputStream and OutputStream

voked multiple times. Jason From: Brian Burkhalter <brian.burkhal...@oracle.com> Sent: Wednesday, December 6, 2017 2:05 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR 4358774: Add null InputStream and OutputStream Jason, On Dec 6, 2017,

Re: RFR 4358774: Add null InputStream and OutputStream

Brian, For nullInputStream would it make any sense to use the ByteArrayInputStream with a (private static) empty byte array? Maybe 'return new ByteArrayInputStream("".getBytes());'? One side effect is that mark support returns true. Does it make sense to follow the advice in

Re: Change in properties for logging: deliberate?

sistent use of other properties like ".level" and ".filter". If both are defined in the logging.properties, then install the union of the two lines. Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday, November 10, 2

Re: Change in properties for logging: deliberate?

Daniel, I would assume you would fix since it is advertised as a feature over here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html If it helps, I've dug up a lot of the history on this over here a while back:

Re: 8189953: FileHandler constructor throws NoSuchFileException with absolute path

Hi Daniel, For more background on this issue I think you should link to this issue to the following: https://bugs.openjdk.java.net/browse/JDK-8153250 https://bugs.openjdk.java.net/browse/JDK-8130462 https://bugs.openjdk.java.net/browse/JDK-8189862 Thanks, Jason

Re: ThreadPoolExecutor and finalization

Peter, Executors.unconfigurableExecutorService was not modified on purpose because of the following case: http://cs.oswego.edu/pipermail/concurrency-interest/2006-March/002353.html Jason From: core-libs-dev on

Re: ThreadPoolExecutor and finalization

Hi Peter, Most of the discussion is in: https://bugs.openjdk.java.net/browse/JDK-6399443. The linked issue in that report then links to the CI mail thread. Jason >I'm trying to understand the purpose of finalize() in TPE, but can't. >I'm surely missing something. If the pool is no longer

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Makes sense on the sub-sequences having to be string. Looks good. Jason From: Ivan Gerasimov <ivan.gerasi...@oracle.com> Sent: Thursday, September 28, 2017 3:19 PM To: Jason Mehrens; core-libs-dev Subject: Re: [10] RFR 8134512 : provide Alpha-N

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Ivan, Am I correct that subtraction of code points is safe from underflow due to the range of Character.MIN_CODE_POINT and Character.MAX_CODE_POINT? That would explain why you are not using Integer.compare. One alternative to calling CharSequence.subSequence is to use

Re: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

Hi Doug, >However, this technique might apply more usefully to TreeSet. True. The more I think about it, it is probably applicable to CSLS under the context where it is concurrently added to and then reaches some idle state (shutdown) and then performs the equality test. It could be port it

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian, Is there a dangling '}' after Files.readAttributes or missing '{@link '? Jason From: core-libs-dev on behalf of Brian Burkhalter Sent: Friday, May 26, 2017 11:17 AM To: Stuart

Re: [9] RFR: 8177136: Caller sensitive method System.getLogger should specify what happens if there is no caller on the stack.

Hi Daniel, For my own understanding, would it be possible and yet still secure to walk up the call stack to substitute a caller in the case of method being defined with the 'native' keyword assuming it is in the same class? For instance, if you look at the stacktrace in JDK-8145302 there is a

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

From: Patrick Reinhart <patr...@reini.net> Sent: Tuesday, December 27, 2016 8:46 AM To: Jason Mehrens Cc: core-libs-dev Subject: Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors Hi

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Patrick, How is 'withAutoFlush' expected to behave for subclasses of PrintWriter? Jason From: core-libs-dev on behalf of Patrick Reinhart Sent: Wednesday, December 21, 2016 3:08 PM To: Roger

Re: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char

Ivan, Will java.util.StringJoiner be modified too? I assume a nCopies char sequence object doesn't pan out performance wise? Thanks, Jason From: core-libs-dev on behalf of Ivan Gerasimov

Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

<daniel.fu...@oracle.com> Sent: Tuesday, November 01, 2016 5:43 AM To: David Holmes; core-libs-dev Cc: Jason Mehrens Subject: Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError On 28/10/16 20:32, David Holmes wrote: > Hi Daniel, > > I've read

Re: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Daniel, Looks good to me. Thanks for fixing this! Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday, October 28, 2016 6:51 AM To: core-libs-dev Cc: Jason Mehrens Subject: RFR: 8152515: (logging) LogManager.resetLogger should

Re: 8153666: Optimize Formatter.formatMessage

Hi Daniel, Thanks for taking this on. Looks good. This might be a new issue altogether but, if record.getMessage returns null a NPE can be generated during 'catalog.getString' (per RB.handleGetObject contract) or 'java.text.MessageFormat.format' (undocumented) It is handled by the catch

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Brent, Have you considered increasing the visibility of just the EntrySet constructor from private to default access? This should get rid an extra generated class file if you compare the javac output since you are accessing just the constructor from the enclosing class. Jason

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

Hi Peter, >As mentioned, Class.newInstance() has a special cache for constructor >and caller that speeds up repeated invocations from the same caller by >skipping access checks. I'm sure I'm missing something obvious related to performance or security but, couldn't the exact same

Re: 8152436: Add a test to verify that the root logger correctly reports the caller's information

rch 22, 2016 11:29 AM To: Jason Mehrens; core-libs-dev Subject: Re: 8152436: Add a test to verify that the root logger correctly reports the caller's information On 22/03/16 17:11, Jason Mehrens wrote: > Hi Daniel, > > I think we just need to add a test where a subclass logger l

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

So for C2 it doesn't matter. From what I can tell using javap, the xor generates the fewest number of bytecode operations. Not that this breaks the bank but, one would think that fewer bytecodes would help C1. Jason From: core-libs-dev

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Claes, For the cases where boolean was being assigned to 'true' (ASSCI and FileLockImpl) does it hurt performance since the accessor methods will now include a branch at the bytecode level? See: "Speed-kings of inverting booleans" at http://www.javaspecialists.eu/archive/Issue042.html Jason

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

Alexander, >What is wrong with get/serErrorManager for Formatter? It should be just >a way for Formatter to report its internal errors. 1. You can't inherit the Handler error manager until after construction of the formatter. That means the concept of inheriting an error manager from a

Re: RFR: jsr166 jdk9 integration wave 2

Hi Peter, I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) 2. Walk

Re: Deprecation of LogRecord.getMillis in JDK9

unit tests which seems like a fair trade off since that keeps the code smell out of the released production code. Jason From: Stuart Marks <stuart.ma...@oracle.com> Sent: Tuesday, December 1, 2015 7:13 PM To: Daniel Fuchs Cc: Jason Mehrens; Core-Libs

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

+1 From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Wednesday, December 2, 2015 2:10 PM To: core-libs-dev Cc: Stuart Marks; Jason Mehrens Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecat

Re: Deprecation of LogRecord.getMillis in JDK9

niel Fuchs <daniel.fu...@oracle.com> Sent: Tuesday, December 1, 2015 12:48 PM To: Jason Mehrens; Core-Libs-Dev; Stuart Marks Subject: Re: Deprecation of LogRecord.getMillis in JDK9 Hi Jason, Stuart, Here is a potential fix for the issue: http://cr.openjdk.java.net/~dfuchs/webrev_81442

Deprecation of LogRecord.getMillis in JDK9

Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use getInstant". I can see marking

Re: Deprecation of LogRecord.getMillis in JDK9

would mark getMillis as SUPERSEDED only but, it still seems questionable that I would suppress the warning. Which leads me toward removing the deprecation. Thanks, Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Monday, November 30, 2015 11

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

ackTrace(pw); return sw.toString(); } There is wiggle room in the API docs for modifying the output string which would avoid a CCC. Jason From: Alexander Fomin <alexander.fo...@oracle.com> Sent: Monday, November 23,

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

ion of the spec. It pains me to say it but, as long as you don't break the SLF4J bridge handler then you have covered most of the JUL users. Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday, November 20, 2015 9:32 AM To: Jason Mehrens;

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday, November 20, 2015 11:04 AM To: Jason Mehrens; Alexander Fomin; core-libs-dev@openjdk.java.net; mandy.ch...@oracle.com Subject: Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exce

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

:27 AM To: Jason Mehrens; core-libs-dev@openjdk.java.net; Daniel Fuchs; mandy.ch...@oracle.com Subject: Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions Hi Jason On 20.11.2015 17:47, Jason Mehrens wrote: > Alexander, > > Why not just cache the

Re: Proposed API for JEP 259: Stack-Walking API

Mandy, Thread.dumpStack should generate the stacktrace elements then capture System.err into a local var and lock it while writing the output. That would be compatible with what was done before. Jason From: core-libs-dev

Re: RFR 8135248: Add utility methods to check indexes and ranges

Hi Paul, Would it make sense to add these methods to the IndexOutOfBoundsException class itself or is there a compatibility worry? Seems better to use the room in IndexOutOfBoundsException class file and keep these methods out of the Arrays class. It is also odd that in the future the

RE: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

. Thanks, Brian On Jun 24, 2015, at 1:03 PM, Jason Mehrens jason_mehr...@hotmail.com wrote: Not sure on this but, isn't it a little risky to import AtomicBoolean into such low level class? I vaguely remember there was an issue with using AtomicXXX in java.lang.Thread. Not sure if this case

RE: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Brian, Not sure on this but, isn't it a little risky to import AtomicBoolean into such low level class? I vaguely remember there was an issue with using AtomicXXX in java.lang.Thread. Not sure if this case suffers the same fate. Jason From:

RE: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

For the test shouldn't you include a test for getLoggerNames to check that if the returned Enumeration is an instanceof Iterator then its remove method must throw an UnsupportedOperationException? That makes it clear as to why you are using Collections.enumeration. Jason

RE: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException

wrote: Thanks for the review Jason! On 24/03/15 18:01, Jason Mehrens wrote: Hi Daniel, Looks good. The only other alternative would be to use java.io.CharConversionException over IOException. We could even consider dropping the cause because the subclass of I/O exception would convey

RE: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

The snapshot enumeration is a welcomed change. ConcurrentHashMap has legacy Hashtable methods so you can save a little bit by calling namedLoggers.keys() instead of wrapping the key set. Jason Date: Thu, 26 Mar 2015 14:32:23 +0100 From:

RE: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException

Hi Daniel, Looks good. The only other alternative would be to use java.io.CharConversionException over IOException. We could even consider dropping the cause because the subclass of I/O exception would convey the same meaning. Minor formatting issues with a missing space after the catch

LogManager.readConfiguration doesn't document IAE and NPE.

Daniel, It occurred to me after reading Brian's patch for https://bugs.openjdk.java.net/browse/JDK-8075362 that the LogManager.readConfiguration methods do not document NPE or IAE that can be triggered by Properties.load. Do we need to file a bug just against logging or should larger bug be

RE: JEP 102 Process Updates revised API draft

could be removed from Process.getPid() too, right? Which solves that small API wart. -Chris. Roger On 3/9/2015 6:10 AM, Chris Hegarty wrote: On 06/03/15 19:34, Jason Mehrens wrote: Hi Chris, Since getPid can throw UOE that means that compareTo could now throw UOE. Ooh... I don't like

RE: JEP 102 Process Updates revised API draft

Hi Chris, Since getPid can throw UOE that means that compareTo could now throw UOE. Jason Subject: Re: JEP 102 Process Updates revised API draft From: chris.hega...@oracle.com Date: Fri, 6 Mar 2015 11:59:28 + To: roger.ri...@oracle.com

RE: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...

. On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman alan.bate...@oracle.com wrote: On 19/02/2015 21:54, Jason Mehrens wrote: I'm assuming that compatibility is given more weight vs. correcting choices made in the original design. Yes, I think we've spent more than enough time on it. In this case

RE: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...

Standing with Martin on this, I wanted to note the following from the ProcessBuilder docs: The exact nature of the exception is system-dependent, but it will always be a subclass of IOException The type of exception thrown is the one thing that is defined in the spec. The rest may be vague or

RE: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

Daniel, Was it determined if you were going to modify the existing logger.dtd or create a logger-v2.dtd? If you are going to create a v2 then I think it might make sense to make dtd log manger property for the XMLFormatter instead of useInstant property. So if you are using v2 then instant

RE: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

Subject: Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps Hi Jason, On 2/13/15 10:57 PM, Jason Mehrens wrote: Daniel, In the XMLFormatter.format you can get rid of the double call to getNanoAdjustment() since you have stored the value

RE: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

Daniel, In the XMLFormatter.format you can get rid of the double call to getNanoAdjustment() since you have stored the value in the local var 'nanos'. For the new XMLFormatter constructor what do you think about using Properties, FunctionString, String, or perhaps a builder pattern? That

RE: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

The strong reference is not changed to weak if later on all handlers are removed from the logger. The only other solution I can think of to satisfy all of the previous pain points is to go back to keeping a reference to Logger.handlers in LogManager.LogNode and create a

RE: JDK-6774110 lock file is not deleted when child logger is used

that scenario, thanks for pointing it out! If i can write a reproducer (which should not be too difficult), it will be a good incentive to attempt a fix :-) Thanks again, -- daniel On 10/9/14 9:56 PM, Jason Mehrens wrote: Daniel, The evaluation on this bug is not quite correct. What is going

RE: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

Daniel, Looks good. As always, thanks for fixing this. Jason Date: Fri, 10 Oct 2014 17:39:55 +0200 From: daniel.fu...@oracle.com To: stani...@riflexo.com; core-libs-dev@openjdk.java.net CC: jason_mehr...@hotmail.com Subject: Re: RFR: 8060132:

  1   2   >