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 IllegalStateExceptio
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 comp
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 o
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?
htt
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("");
Will
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 modified
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
https://github.co
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
___
e.
Jason
From: 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,
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
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
___
//source.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: Ja
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);
s1.add("hell
tuart 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 Li
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 splitIterator().characteris
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 mu
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 of
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 processe
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: 819
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 that
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
___
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; core-libs-
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
S
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 o
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 i
>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
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
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
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 a
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 mor
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 differen
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
Looks good.
Jason
From: Joe Wang
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. Thanks Jason!
Joe
On 2/9/18, 1
ll 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 hostile if we call CS.compare(null, null) and that doesn't seem
>>
Aleksei,
Looks good to me.
Jason
From: Aleks Efimov
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.initCause() does not
correctly set
From: Aleks Efimov
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 webrev can be found at this location
sException 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
Sent: Monday, February 5, 2018 10:51 AM
To: Jason Mehrens; 'Roger Riggs
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;
}
===
Jaso
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
Looks great! Personally, these LogManager startup issues make my head hurt. :)
Jason
From: Daniel Fuchs
Sent: Tuesday, January 23, 2018 1:13 PM
To: Jason Mehrens; core-libs-dev@openjdk.java.net
Cc: Mandy Chung
Subject: Re: [JDK 11] RFR: 8195096
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 behalf of
Daniel Fuchs
Sent: Monday, Ja
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 met
d keep the read of "handlers" eager.
Jason
From: Daniel Fuchs
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 on starting Apache Tomcat
se/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
>> getProperty it shouldn't really matter what the value format is
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 core
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.
>http://cr.openjdk.java.net/~redestad/8193128/open.0
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 everythi
be invoked multiple times.
Jason
From: Brian Burkhalter
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, at 11:54 AM, Jason M
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
https://bugs.op
s consistent 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
Sent: Friday, November 10, 2017 10:04 AM
To:
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:
https://stackoverflow.com/questions/36726431/in-a-java-util-loggi
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
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 behalf of Peter
Levart
Sent: Thursday,
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 refe
Makes sense on the sub-sequences having to be string. Looks good.
Jason
From: Ivan Gerasimov
Sent: Thursday, September 28, 2017 3:19 PM
To: Jason Mehrens; core-libs-dev
Subject: Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator
Thank
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
CharBuffer.wrap(CharSequ
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 t
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 Marks
Cc: core-libs-dev
Subject: Re: [REVISED] JDK 9 doc-api-only RFR
Tenghuan He,
You are correct if 'this' is a SortedMap/Set and 'o' is a SortedMap/Set then
both interfaces list a clause in the top level documentation of:
"This order is reflected when iterating over the sorted map's collection views"
and "The set's iterator will traverse the set in ascending el
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 na
ception?
Jason
From: Patrick Reinhart
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 Jason,
A
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 Riggs
Cc: core-libs-dev
Subject: Re: Request for Review and S
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
Sent: Sunday, December 4, 2016 6:07 AM
To: core-libs-dev@openj
: 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 the bug report on this and this issue
Daniel,
Looks good to me.
Thanks for fixing this!
Jason
From: Daniel Fuchs
Sent: Friday, October 28, 2016 6:51 AM
To: core-libs-dev
Cc: Jason Mehrens
Subject: RFR: 8152515: (logging) LogManager.resetLogger should ignore
LinkageError
Hi,
Please find
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 claus
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
___
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 'cachedConstru
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 logs the message
> with
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 on behalf of
Al
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
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
handler
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 the
+1
From: Daniel Fuchs
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 deprecated
Hi,
Please find below a fix
kery"
to 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
Sent: Tuesday, December 1, 2015 7:13 PM
To: Daniel Fuchs
Cc: Jason Mehrens; Core-Libs-Dev
Su
niel Fuchs
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_8144262/webrev.00/src/java.logging/share/cl
277 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
Sent: Monday, November 30, 2015 11:32 AM
To: Jason Mehrens
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 LogRecord.setMillis
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
Sent: Monday, November 23, 2015 9:27 AM
To: Jason Mehrens; core-libs-dev@o
r and
the Handler.errorManager is kind of like the Thread.uncaughtException handler.
Then to fix this bug we could report it to via
LogManager.getLogManager().reportError.
Jason
From: Alexander Fomin
Sent: Friday, November 20, 2015 11:27 AM
To: Jason Mehrens; cor
From: Daniel Fuchs
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 Exceptions
On 20/11/15 17:55, Jason
h is
already a violation 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
Sent: Friday, November 20, 2015 9:32 AM
To: Jason Mehren
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 on behalf of Mandy
Chung
Sen
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 LinkedL
I am not sure of the answer. Let’s see what
>> the experts have to say.
>>
>> Thanks,
>>
>> Brian
>>
>> On Jun 24, 2015, at 1:03 PM, Jason Mehrens wrote:
>>
>>> Not sure on this but, isn't it a little risky to import AtomicBoolean into
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: brian.
Peter,
Have we considered just embracing CharBuffer.wrap(CharSequence, int, int) work
as way to support the old substring behavior? If you dig through the code, that
creates a java.nio.StringCharBuffer which is a view of the wrapped string. We
could then optimize all of the friend classes to s
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
I'm going to
> present to CCC.
>
> best regards,
>
> -- daniel
>
> On 25/03/15 12:41, Daniel Fuchs wrote:
>> Thanks for the review Jason!
>>
>> On 24/03/15 18:01, Jason Mehrens wrote:
>>> Hi Daniel,
>>>
>>> Looks good. The only ot
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: daniel.fu..
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 ke
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
order
>> or use TreeMap. Returning Long.MAX_VALUE as the default might be another
>> option.
>
> That would probably be ok too, and then the UOE could be removed from
> Process.getPid() too, right? Which solves that small API wart.
>
> -Chris.
>
>> Roger
>&g
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
ective Java Item 58: Use checked exceptions
>>> for recoverable conditions and runtime exceptions for programming errors.
>>> I don't think it's worth fixing places in jdk8 where this small mistake
>>> was
>>> made, but we can at least stop the
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 o
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 i
.java.net
> 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
>
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,
Function, or perhaps a builder pattern?
That way if XMLForm
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 LogManager.orphanedHan
1 - 100 of 199 matches
Mail list logo
