I noticed that List.copyOf() allocates an array twice. The first allocation
is coll.toArray(), the second one is in ListN constructor. Can we do
something with it?
2018-03-22 7:51 GMT+07:00 Stuart Marks :
> Hi Claes,
>
> I'm finally finally getting back to this. I reviewed the current state of
>
Hi,
on the 10th of March I wrote here about duplicated code of idnexOf/lastIndexOf
methods in array-based collections.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051968.html
Later I've found one more related issue. Here's the code of
CopyOnWriteArrayList$COWSubList.remove(
+1
Mandy
On 3/22/18 1:33 PM, Phil Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8200129
webrev: http://cr.openjdk.java.net/~prr/8200129/
It was noted in another thread [1] that we had a couple of qualified
exports
from java.base to java.desktop that are platform-specific but are
> On Mar 22, 2018, at 2:46 PM, Aleksey Shipilev wrote:
>
> On 03/22/2018 10:37 PM, Paul Sandoz wrote:
>> Test looks good, but do you need to declare the source/target for
>> compilation?
>
> Thanks! source/target are from the times when default source/target was not
> 9, all other tests have
On 03/22/2018 10:37 PM, Paul Sandoz wrote:
> Test looks good, but do you need to declare the source/target for compilation?
Thanks! source/target are from the times when default source/target was not 9,
all other tests have
it (I copypasted the test from the existing ones). We should probably dit
Test looks good, but do you need to declare the source/target for compilation?
Paul.
> On Mar 22, 2018, at 10:56 AM, Aleksey Shipilev wrote:
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200118
>
> Webrev:
> http://cr.openjdk.java.net/~shade/8200118/webrev.01/
>
> This adds the relev
On 23/03/2018 12:18 AM, Kumar Srinivasan wrote:
David,
Why would the VM emit these warnings if the deprecated vm flag
is not being used ?
The warnings are not deprecation warnings. The warnings are for flags
that should have been made obsolete in this version but are still
present. It is a r
On 22/03/2018 20:33, Phil Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8200129
webrev: http://cr.openjdk.java.net/~prr/8200129/
This looks okay to me.
-Alan
Looks fine.
On 22/03/2018 13:33, Phil Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8200129
webrev: http://cr.openjdk.java.net/~prr/8200129/
It was noted in another thread [1] that we had a couple of qualified
exports
from java.base to java.desktop that are platform-specific but a
bug: https://bugs.openjdk.java.net/browse/JDK-8200129
webrev: http://cr.openjdk.java.net/~prr/8200129/
It was noted in another thread [1] that we had a couple of qualified exports
from java.base to java.desktop that are platform-specific but are in the
main module-info.java.
It was suggested to
Сергей: Thanks for the benchmarking.
I would always do benchmarking with latest available jdk, i.e. jdk11.
You don't say which variant is better and which is best!
But the difference is small enough we should go with the simpler one you
originally suggested
return "true".equalsIgnoreCase(s);
I su
On 2018-03-22 19:03, Stuart Marks wrote:
One small issue is with this comment:
295 * Constructs a sublist of an arbitrary AbstractList,
which is
296 * not a SubList itself.
This supports sublists of an arbitrary AbstractImmutableList, not
AbstractList.
Other than thi
The performance concern is a fair point and it'll need the benchmark and
proper perf measurement. It's okay with me to follow up as a separate
clean up and you already have the work started any way.
Mandy
On 3/22/18 12:01 PM, Roger Riggs wrote:
Hi Mandy,
This is just one step in untangling
Hi Mandy,
This is just one step in untangling and improving property initialization.
I'm also working on a change similar to what you suggest to remove
some/more of the upcalls
and replace them with setting fields. In that case, the adjustments to
the values would be handled in java.
I have
To be clear, SLF4J only provides an MDC API and doesn’t implement the MDC. It
delegates that to an implementation - Log4j 2 or Logback. Obviously, my concern
would be to get Log4j 2 to work the way it needs to. If it requires additional
help from the JDK library then there is only so much I can
Seems you need to run it on all platforms to be sure.
This one is used on Windows :
exports jdk.internal.perf to java.desktop
This one is used on Linux + Solaris :
exports sun.nio.cs to java.desktop
-phil.
On 03/22/2018 11:01 AM, mandy chung wrote:
On 3/22/18 10:44 AM, Alan Bateman
I already pushed 8200072 but I'll file a new bug.
-phil.
On 03/22/2018 11:28 AM, mandy chung wrote:
Yes it needs to run all platforms because some qualified exports are
platform-specific.
On 3/22/18 11:22 AM, Phil Race wrote:
Seems you need to run it on all platforms to be sure.
This one i
My point is that I don’t think this is the only place the problem occurs. I
have seen similar questions on the Log4j mailing list where users want to be
able to do this for thread pools they create via Executors and don’t want to
have to do the ThreadLocal propagation themselves. If a Completeab
Yes it needs to run all platforms because some qualified exports are
platform-specific.
On 3/22/18 11:22 AM, Phil Race wrote:
Seems you need to run it on all platforms to be sure.
This one is used on Windows :
exports jdk.internal.perf to java.desktop
This one is used on Linux + Solaris
Hi Roger,
Thanks for adding the test that should have created when JDK-4700857 was
resolved.
Since this fix changes the setting of those i18n properties to later
after JVM_InitProperties is called, it would be a good opportunity to
set these properties in Java and remove the native fillI18nP
Great, thanks for doing those cleanups!
They're small, but I think they make a big difference in the comprehensibility
of the code, because of all the little classes in this file.
Looks like you went ahead and consolidated everything into ListItr, which is
used by the iterator() and listItera
On 3/22/18 10:44 AM, Alan Bateman wrote:
On 22/03/2018 17:41, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8200072
webrev: http://cr.openjdk.java.net/~prr/8200072/
jdk.internal.math is exported to java.desktop but it has never been
needed,
except briefly, in the jake for
Bug:
https://bugs.openjdk.java.net/browse/JDK-8200118
Webrev:
http://cr.openjdk.java.net/~shade/8200118/webrev.01/
This adds the relevant test to StringConcat family of tests, which asserts all
strategies do the
right thing. There was a bug in MH_* strategies caused by the already fixed bug
+1
Mandy
On 3/22/18 10:41 AM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8200072
webrev: http://cr.openjdk.java.net/~prr/8200072/
jdk.internal.math is exported to java.desktop but it has never been
needed,
except briefly, in the jake forest during JDK 9 development.
Histo
On 22/03/2018 17:41, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8200072
webrev: http://cr.openjdk.java.net/~prr/8200072/
jdk.internal.math is exported to java.desktop but it has never been
needed,
except briefly, in the jake forest during JDK 9 development.
History is in
Having read several of the threads I think I have a better understanding of the
problem. This sounds similar to problems that occur with any application that
has a way of doing asynchronous processing with with thread pools. Java has
unfortunately not provided a good way that I know of to pass a
Bug: https://bugs.openjdk.java.net/browse/JDK-8200072
webrev: http://cr.openjdk.java.net/~prr/8200072/
jdk.internal.math is exported to java.desktop but it has never been needed,
except briefly, in the jake forest during JDK 9 development.
History is in the bug.
-phil.
If parseBoolean is worth optimizing (barely, but only because Boolean is
very popular), then let's do the usual ASCII bit-twiddling:
public static boolean parseBoolean(String s) {
// return "true".equalsIgnoreCase(s);
return s != null
&& s.length() == 4
Log4j 2 supports a ThreadContext which is analogous to the SLF4J MDC. Both are
based on ThreadLocal variables. If I understand what you are saying, the
problem is that ThreadLocals do not work as you you would expect when using
CompleteableFutures?
Ralph
> On Mar 22, 2018, at 7:05 AM, Dean Hil
slf4j is pretty much the defacto logging standard these days allowing one
to bring in libraries using any logging framework. (commons logging fell
short and had classloading bugs).
Summary: MDC works fine in twitter scala Futures but not java
CompletableFutures.
Unfortunately, one of the best fe
Looks good. Thanks Roger for the clean up.
Naoto
On 3/22/18 8:24 AM, Roger Riggs wrote:
Hi,
The webrev[1] has been updated with a new test added to verify that if a
user.* property
is defined on the command line, then corresponding property has the same
value and
correctly overrides any val
Hi Stuart,
On 2018-03-22 01:51, Stuart Marks wrote:
Hi Claes,
I'm finally finally getting back to this. I reviewed the current state
of the patch located here:
http://cr.openjdk.java.net/~redestad/8193128/open.06/
I think this is mostly fine as it is.
thanks!
There are some things a
Hi,
The webrev[1] has been updated with a new test added to verify that if a
user.* property
is defined on the command line, then corresponding property has the same
value and
correctly overrides any value from the platform.
After verification, the comment (line 304) has been corrected to ref
Hi Roger,
Thanks for the comments. It seems like we have agreement on using @apiNote
instead of @implSpec.
Brian
On Mar 22, 2018, at 8:02 AM, Roger Riggs wrote:
> The use of the word 'equivalent' regardless of the context, only says the
> behavior is the same
> it does not mandate the implem
Hi Brian,
The use of the word 'equivalent' regardless of the context, only says
the behavior is the same
it does not mandate the implementation except that it behaves the same.
Since the behavior of the method is already specified, adding the
'equivalent' statement
only makes it easier for th
David,
Why would the VM emit these warnings if the deprecated vm flag
is not being used ?
Andrey,
As for the reviews I am ok with InfoStreams, wrt. ToolOpts it is not at
all apparent,
maybe more comments explaining what is going on ?
Kumar
Hi Andrei,
On 22/03/2018 11:12 AM, Andrey Nazarov
36 matches
Mail list logo
