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
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
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
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
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
//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
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
___
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
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,
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
___
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
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
___
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
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
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
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
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
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
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
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
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
Typo in the javadocs. "is either.." should be "if either..".
Jason
> Date: Wed, 15 Jun 2011 11:00:27 -0700
> From: [email protected]
> To: [email protected]
> Subject: Code review request for 7021922:
> java.lang.annoation.IncompleteExceptions throws NPE when type is null
>
>
Mike,
The history is in the evaluation of
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6394757
I don't think that even adding a empty check can be considered an optimization
when dealing with two abstract things. The iterator creation here is 'good
garbage' and worst case AbstractCol
> What's about moving
>
> public boolean equals(Object o) {return o == this || c.equals(o);}
>
> to CheckedCollection and remove it in CheckedSet (L2394), CheckedList (L2506)
>
> and
>
> public int hashCode() {return c.hashCode();}
>
> to CheckedCollection and remove it in CheckedSet (L2395)
Darryl,
I would get rid of the public static field so this class can be lazy loaded
like EmptyIterator and ReverseComparator (in 1.7). What about accepting a
comparator as an argument? I bet the bug report is predates 1.6, so maybe you
should target NavigableSet instead of sorted set.
Reg
Darryl,
CheckedQueue.offer should call 'this.queue.offer' instead of 'this.add'. If
you pass a Queue with bounded capacity (ArrayBlockingQueue) the CQ.offer method
should return false when the queue is full but will instead throw an
IllegalStateException. The current version also is perform
Mike,
These 'simple' classes are really hard to get right. Here is my review of the
change:
1. Why not extend EmptySet? You wouldn't have to implement so many methods.
2. The comparator method is using raw types.
3. The readResolve method comment is just wrong. Create a default access
sta
Darryl,
>> 2. The comparator method is using raw types.
>The SortedSet.comparator() method spec allows returning of null.
Right. But, the return type of the implementation is a raw comparator not
Comparator defined by the interface.
>> 4. Only the IAE if statement is need for your range che
Brandon,
> Are there any opinions on this from other Collections experts?
> http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/
Shouldn't the test include all collections included with the JDK? Any override
of these methods could repeat the same (bad) behavior.
Jason
> Date: Tue, 20 Dec 2011 10:12:02 +1000
> From: [email protected]
> To: [email protected]
> Subject: Re: Code Review Request for Bug #4802647
> CC: [email protected]
>
> Brandon,
>
> I don't see the purpose of NewAbstractSet. It is identical to
> NewAbstractCollect
ch to fix Bug #7129185. This
> fix addresses comments made by Jason Mehrens to the commit of the fix
> for bug #4533691, including adding a Collections.emptyNavigableSet
> method. Tests are included.
>
> Webrev, can be found here:
> http://cr.openjdk.java.net/~dmocek/7129185/webrev.00
>
> Thanks,
> Darryl
> > 3. What if I want to create an empty set navigable set with supplied
> > comparator? Extending is not an option.
> This is the one issue I wanted to discuss...is this necessary? I was
> thinking about how this would be implemented. You would need to supply
> a comparator to the emptyNavigabl
Darryl,
Per the SortedSet docs: .null if this set uses the natural ordering of its
elements.
Per the NavigableSet.descendingSet docs: "The returned set has an ordering
equivalent to Collections.reverseOrder(comparator())"
=
NavigableSet fwd = new TreeS
Sherman,
As a workaround, what about allowing a write of empty string or empty char
array to call flushBuffer? If you call PrintStream.print("") then flushBuffer
is called on the internal writers. But if you try the same by doing
OuputStreamWriter.write("") the flushbuffer call is trapped b
t back the encoder.flush() into
osw.flushBuffer (in StreamWriter.implFlushBuffer()).
-Sherman
On 02/09/2012 10:24 AM, Jason Mehrens wrote:
Sherman,
As a workaround, what about allowing a write of empty string or empty char
array to call flushBuffer? If you call PrintStream.print("") then fl
David,
For completeness, you might want to link this bug to bug id 6360946 "(coll)
SetFromMap.equals should perform identity check". Most of the wrapper classes
were fixed to include an identity check for that bug. Digging up some old
messages from December 2005, the synchXXX wrappers were
What about exception cases where the single element is not comparable?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5045147
Consider the following:
=
Object[] a = new Object[]{new Object()};
Arrays.sort(a);
List l = Arrays.asList(a); //Evil raw type
Collections.sort(l);
>>I'm not really confident about proposing "assertions as lint detection"
>>rather than adding explicit checks. We wouldn't (and don't) use optional
>>assertions for array bounds checking. This has clearly been the right choice.
>>I'm still considering my >>feelings about whether to be hardline
> Well it's not a bug it is a RFE. :) But I agree that the example is a
> little flawed in that generate() would not reasonably be able to
> generate mutable lists in some cases and immutable lists in others.
> I find the restriction on empty/singleton lists unnecessary, but not
> sure it is
Rob,
It looks like waitFor is calling Object.wait(long) without owning this objects
monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't waitFor return if the
early if the process ends?
Jason
> Date: Tue, 17 Apr 2012 15:56:30 +0100
> From: [email protected]
> To: alan.bate...@ora
Rob,
> 2) As Alan noted, there is really no need for isAlive() if people are
> happy with the idea of waitFor(long, TimeUnit). I'd appreciate any
> feedback on this aspect of the fix.
Process.isAlive is similar to Future.isDone(). I think isAlive fills that need
to have a simple query metho
Mike, Why not implement subSequence as 'java.nio.CharBuffer.wrap(data,
beginIndex, endIndex).asReadOnlyBuffer()' ? Easy to implement and test. The
nice thing is that parsers would know what a 'CharBuffer' vs. a sub sequence
String internal class. Jason
> Subject: String.subSequence and CR#69
e coder gets smacked with an error.
Jason Mehrens
>The JDK project has unusually high compatibility concerns.
>I and Josh believe the introduction of a possible IAE if the
>comparator doesn't satisfy its contract is the right thing,
>but we'd also be willing to chang
Joe,
Wouldn't LinkageException be a better fit than ReflectiveOperationException?
Shorter name and it would mimic the LinkageError inheritance tree introduced in
JDK1.0. I.E. LinkageError -> NoClassDefFoundError, LinkageException ->
ClassNotFoundException
> This request seems dangerou
Joe,
> * null safe toString(Object), returning "null" for a null argument
Doesn't String.valueOf do the same thing?
http://java.sun.com/javase/6/docs/api/java/lang/String.html#valueOf(java.lang.Object)
What about a toIdentityString(Object) instead? Some of the nice properties of
an id
> By toIdentityString, do you mean the String that would be returned by
> toString if toString is not overridden?
>
> -Joe
Yep. As in:
return o != null ? o.getClass().getName() +'@'+
Integer.toHexString(System.identityHashCode(o)) : "null";
I suppose the name should be identityToStr
> I think a better name would be "defaultToString" since it is the default
> toString from Object. However, I haven't ever heard anyone else request
> easier access to the default toString before so I'm not convinced this
> should go into Objects.
>
> -Joe
One use case is implementing toSt
> Hi Stephen,
>
> [...]
> > In key places there are multiple options. NIO Path vs File and
> > Calendar vs Date are examples.
>
> As you know, Path (resp. Calendar) is just an attempt to correct the
> mess introduced by File (resp. Date).
> So yes, there is duplication but this duplication is
+1, return empty string for the one arg and add the two arg variant. The
j.u.Properties.getProperty(String, String) could use it first. Just curious,
what does project jigsaw think of j.u.Objects?
Jason
> Date: Thu, 8 Oct 2009 11:47:49 +0100
> Subject: Objects.toString [Re: What method
Joe,
I'll volunteer some "find usage" stats from the code base I work on for a
living:
565 ObjectUtils.toString(Object) calls.
487 String.valueOf(Object) calls.
Hopefully others can contribute their "find usage" stats. It seems to me that
both behaviors are useful.
Jason
>
Kelly,
Are any of the tests run with "-Xcheck:jni"? If not, it might be something to
consider.
Jason Mehrens
> Date: Fri, 11 Dec 2009 11:20:53 -0800
> From: [email protected]
> Subject: Need reviewer - adding -ea -esa to testing via jdk/test/Makefile
Alan,
Shouldn't the loading of 'this.count' into 'len' be only performed if 'h' is
zero? Otherwise, when hash is not zero we perform a little unnecessary work
every time hashCode is called.
Jason
> Date: Thu, 25 Feb 2010 21:17:37 +0100
> From: [email protected]
> To: [email protected]
Here are two more variants you might want to throw into the benchmark.
public int hashCode6() {
int h = hash;
if (h == 0 && count > 0) {
int off = offset;
char val[] = value;
int len = count;
for (int i = 0; i < len; i++) {
, you will see that, am I wrong ?
-Ulf
Am 27.02.2010 18:50, schrieb Jason Mehrens:
Here are two more variants you might want to throw into the benchmark.
public int hashCode6() {
int h = hash;
if (h == 0 && count > 0) {
int off = offset;
ch
String.hash should only have two known states, zero and the actual computed
hash code.
http://bugs.sun.com/view_bug.do?bug_id=6611830
Jason
> Date: Sun, 28 Feb 2010 17:09:15 +0100
> From: [email protected]
> To: [email protected]
> Subject: Re: Need reviewer for forward port of 6815
Stephen,
I'm all for adding support for unmodifiableIterable, unmodifableNavigableMap,
and unmodifableNavigableSet. However, I think adding public access to such a
iterator decorator goes against the guidelines of the collections design faq (4
and 5):
http://java.sun.com/javase/6/docs/tec
> I wonder the design for Proxy and InvocationHandler can be
> enhanced by creating a default equals/toString/hashCode implementation
> for Proxy correctly, not ask developers to do it again and again
> whenever he uses Proxy. Anyway, this may be another story.
See: http://bugs.sun.com/bugdat
> > About the name, I propose:
> > iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
>
> But there are two methods we want to rename this to, and we can't use
> this name twice. I propose we generate random method names instead.
You don't want to violate trademarks either.
How about 'vetoN
I understand why the previous code leaks but, why is a null value safe to use
for the CCL? Is it because this code is part of the JDK (not ext classloader)
or is it because no more class loading is done on that thread? For 3rd party
libs, should the CCL be set to null or set to the classloade
> Lance is the best person to comment on this but I don't think the
> JDBC-ODBC bridge has been maintained for a few years and probably isn't
> up to the latest JDBC version. No problem proposing a patch but I just
> wonder if it is actually used these days.
The only thing I've used the JDBC-O
Hi Steve,
I was one of the people that provided feedback on Mike's patch. In my case, it
was a mishap of reply to sender vs. reply to all. I don't have the original
email but, the result are visible in the test case that Mike wrote. My main
concern with the old patch that if you use a raw
Is it necessary for 'NULL' in EnumMap to have hashCode of zero? If so, would
using new Integer(0) be better than creating a subclass with regards to
footprint and classloading?
A similar issue was brought up before:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-March/006154.html
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.
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
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
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
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
From: Daniel Fuchs
Sent: Friday, November 20, 2015 11:04 AM
To: Jason Mehrens; Alexander Fomin; [email protected];
[email protected]
Subject: Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage()
swallows Exceptions
On 20/11/15 17:55, Jason
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
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
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
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
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
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
+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
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
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
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
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
Daniel
I think you should be able to remove the 'other instanceof
ConfigurationListener' branch in the ConfigurationListener.equals method.
Should work the same with or without that branch.
Jason
> Date: Wed, 10 Sep 2014 11:49:51 +0200
> From: dan
Daniel,
I suppose that the propagating uncaught exceptions to the caller was the
previous behavior of the old property change methods but it seems out of place
for the LogManager. The LogManager is a global resource so broken listener
code in web app A could suppress notifications in web app
[email protected]
> CC: [email protected]
> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to
> listen for LogManager configuration changes
>
> On 9/12/14 5:39 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> I suppose
s a new webrev - with updated test case:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
>
> best regards
>
> -- daniel
>
> On 9/12/14 7:21 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> Agreed. My preference would be to:
>>
>>
Hi Daniel,
The only thing I noticed is a missing @since tag on the FileHandler.
Jason
> Date: Tue, 7 Oct 2014 15:13:13 +0200
> From: [email protected]
> To: [email protected]
> Subject: RFR: 8059767: FileHandler should allow 'long' li
Daniel,
The evaluation on this bug is not quite correct. What is going on here is the
child logger is garbage collected which makes the FileHandler unreachable from
the LogManager$Cleaner which would have closed the attached FileHandler. In
the example, there is no hard reference that escape
out 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,
&
was different.
>>
>> Now what you describe looks indeed like a bug that should still be
>> present
>> in the code base. I didn't think about that scenario, thanks for
>> pointing it out!
>> If i can write a reproducer (which should not be too difficult), it
&
Daniel,
Looks good. As always, thanks for fixing this.
Jason
> Date: Fri, 10 Oct 2014 17:39:55 +0200
> From: [email protected]
> To: [email protected]; [email protected]
> CC: [email protected]
> Subject: Re: RFR: 8060132: H
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
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
.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,
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
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
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
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: [email protected]
> Date: Fri, 6 Mar 2015 11:59:28 +
> To: [email protected]
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
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
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
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..
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
1 - 100 of 199 matches
Mail list logo
