Hi all,
Please review this changeset that fixes up links around the JDK that point to
the old Collections technotes/guides area. This changeset points them to the
java.util package summary instead.
Most of the changes here simply adjust a link location. The file that's
different is java/util
On 4/6/17 6:38 AM, Timo Kinnunen wrote:
IMHO there should be a notice added in findAll which excludes the behavior of
the stream after an empty match from any compatibility requirements while the
notice remains in place. This would be to ensure that findAll and the stream it
returns can be change
On 4/7/17 11:44 AM, Brian Burkhalter wrote:
On Apr 6, 2017, at 7:09 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
- * imposes orderings that are inconsistent with equals."
+ * imposes orderings that are inconsistent with equals."
Picayune question: W
Hi all,
Please review this small javadoc fix to correct the wording in
Comparator.compare(). There's a sentence defining the sgn() notation, that says
"In the foregoing description" but it occurs *before* the actual use of sgn().
I've moved this to the end of the method spec.
This also makes
On 4/5/17 5:54 PM, Mandy Chung wrote:
On Apr 5, 2017, at 5:44 PM, Stuart Marks wrote:
http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.0/
Other than designfaq.html, these html files such as changes[3-9].html,
index.html, overview.html, and reference.html seem not worthing
to be
Hi all,
Here's another step in the docs cleanup: migration of the collections
technotes/guides into the JDK's javadoc doc-files. This is a webrev containing
two changesets:
JDK-8177787 copy collections technotes/guides html files into jdk doc-files
JDK-8177788 fix links, minor editing, add Ja
On 4/4/17 10:48 PM, Stuart Marks wrote:
On 4/4/17 4:10 PM, Xueming Shen wrote:
Personally I think the use scenario and the expected resulting behavior of
StreamfinaAll(ptn) should be more equivalent/similar to the use case of
while (s.hasNext(p)) { s.next(p); }, or while (m.find
tch at the same location
could even be considered a bug.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *Xueming Shen <mailto:xueming.s...@oracle.com>
*Sent: *Wednesday, April 5, 2017 01:11
*To: *Stuart Marks <mailto:stuart.ma...@o
On 4/4/17 4:10 PM, Xueming Shen wrote:
On 4/4/17, 12:52 PM, Stuart Marks wrote:
I'd at least like to add the API note I proposed in order to document this
issue. I'm reluctant to start tinkering with the behavior of this method at
this late stage in the release.
BTW I used Scann
ked on the
other day. It worked perfectly. :-)
s'marks
On 3/30/17 2:19 PM, Stuart Marks wrote:
Hi Timo, Sherman,
Thanks for looking at this.
Sherman wrote:
This might practically put the api itself almost useless? it might be an easy
task to spot
whether or not it's a 0-width-match-pos
Hi all,
Please review this small change to the spec of Iterator.forEachRemaining. I
claim this change is non-normative, since the text to be added "other mutator
methods of Iterator subtypes" is already covered by existing text "modifies the
collection in any way". However, this bug arose bec
On 3/31/17 6:55 AM, Roger Riggs wrote:
The webrev for deprecating finalize has been updated:
- to improve the advice existing JDK subclasses overriding finalize provides in
@deprecated javadoc,
- to expand Object.finalize() javadoc to reinforce the correct use of
super.finalize() by subclasse
27;
// ''
// 'matcher'
// ''
// 't'
// ''
// ''
// ''
// ''
Sent from Mail for Windows 10
From: Xuem
Hi all,
Please review this small, non-normative textual change to j.u.Observable. This
class, and its companion Observer interface, were deprecated earlier in JDK 9.
Doug Lea suggested adding a link to j.u.c.Flow in case people confused these
APIs with reactive streams. (AFAICS reactive stream
Hi all,
Please review these non-normative textual additions to the Scanner.findAll()
method docs. These methods were added earlier in JDK 9; there's a small pitfall
if the regex can match zero characters.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1490749958 25200
# Tue
02/
<http://cr.openjdk.java.net/%7Ebpb/8177526/webrev.02/>
Thanks,
Brian
On Mar 28, 2017, at 5:06 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
The change looks good, with the exception that it looks like the last bit
"(EOF)." was dropped from the spec of the public readLine() method.
The change looks good, Joe.
s'marks
On 3/28/17 9:43 AM, joe darcy wrote:
Hello,
The tests in jdk/internal/math tests test the floating decimal code which
underlies the base conversion functionality used in the core libraries. This
code is not part of BigInteger or BigDecimal and is not otherwi
Hi Brian,
The change looks good, with the exception that it looks like the last bit
"(EOF)." was dropped from the spec of the public readLine() method.
s'marks
On 3/28/17 2:40 PM, Brian Burkhalter wrote:
Here is a second version as I overlooked the no-arg variant of the method in
version 00
Hi Joe,
The change looks good.
Thanks,
s'marks
On 3/27/17 5:57 PM, joe darcy wrote:
Hello,
The implementation of the method System.runFinalizersOnExit uses API elements
that are deprecated for removal, namely Runtime.runFinalizersOnExit.
System.runFinalizersOnExit is itself deprecated for r
Tagir Valeev asked on Twitter whether System.runFinalization() and
Runtime.runFinalization() should also be deprecated. The obvious answer is "yes"
since we're deprecating finalization, but maybe it's not so obvious.
One view is that we're not deprecating the entire finalization mechanism, we'r
As Dr Deprecator, I approve of this change. :-)
One small comment. Deprecation warnings aren't issued at the use site of a
deprecated API if the use site itself is deprecated. Thus, the @SuppressWarnings
annotation isn't necessary in the following diff hunk:
--- old/src/java.base/share/clas
.. and ObjectOutputStream.enableReplaceObject.
https://bugs.openjdk.java.net/browse/JDK-8066640
Please review this small spec change for these methods. This aligns the
specification to be in agreement with the actual implementation. Essentially the
change replaces the current wording:
<< If
On 3/13/17 5:17 AM, Andrew Dinn wrote:
On 13/03/17 12:15, Andrew Dinn wrote:
On 12/03/17 09:55, Andrew Haley wrote:
Oh, absolutely, I know about that. I was just wondering why now, and
is this something you just came up with, and are we going to have the
compatibility discussion?
Perhaps n
On 3/8/17 4:12 PM, Weijun Wang wrote:
It does not show on the current javadoc page, but I am assigned the bug
8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.*
modules
So maybe there will be a change?
Hm, it looks like somebody is running javadoc over these packag
On 3/8/17 2:38 AM, Weijun Wang wrote:
The class page has:
*Deprecated, for removal: This API element is subject to removal in a future
version.*
The policytool tool has been deprecated and is planned to be removed in a future
release.
Usually, the annotation @Deprecated says that the class/m
On 2/15/17 9:18 AM, Mandy Chung wrote:
On Feb 15, 2017, at 6:21 AM, Mark Sheppard wrote:
please oblige and review the following change:
http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
For the test, can you move @ignore to the top after @test which makes it easier
to tell this te
On 2/2/17 3:23 AM, Alan Bateman wrote:
On 01/02/2017 20:47, Stuart Marks wrote:
The situation with dynamic stubs in UnicastRemoteObject is similar. The logic
is the same, but there can be a mixture of remote interfaces, which
complicates things a bit. Nonetheless I think the rewording came
On 2/1/17 12:52 PM, Martin Buchholz wrote:
Wave 14 now contains a bug fix for a minor mistake in a previous wave.
https://bugs.openjdk.java.net/browse/JDK-8173706
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/Vector-setSize/
Hi Martin, thanks for picking this up.
On 2/1/17 12:33 AM, Alan Bateman wrote:
On 01/02/2017 00:22, Stuart Marks wrote:
+*
+* If the class to be activated and the special activation
contructor are both public,
+* the class must reside in a package that is exported or open to the
+* {@code java.rmi} module.
I think
On 1/31/17 10:08 PM, Mandy Chung wrote:
Except a typo “contructor”, looks okay.
Oh yes, thanks, I'll fix this.
s'marks
Hi all,
Please review these small spec changes that adjust RMI specifications for the
modular environment in Java 9. RMI does some reflection to handle stubs and to
activate objects. The changes specify what kind of accessibility (package
exports/opens, and class/method/constructor accessibili
Hi all,
Please review this small patch to Date.java to remove the reference to the
USNO's Directorate of Time, and to make minor adjustments to the text and the links.
Thanks.
s'marks
# HG changeset patch
# User smarks
# Date 1484261274 28800
# Thu Jan 12 14:47:54 2017 -0800
# Node I
On 1/11/17 2:30 PM, Louis Wasserman wrote:
I haven't followed this much, but an observation: in Guava, we avoided
creating lots of specialized implementations for small collections, because
the JVM, at least at the time, had a sweet spot for bimorphic dispatch:
method calls where the real imple
Whoops, we all missed this one. Thanks for the quick fix.
On 1/12/17 8:07 AM, Claes Redestad wrote:
Thanks Chris!
/Claes
On 2017-01-12 17:03, Chris Hegarty wrote:
On 12 Jan 2017, at 15:42, Claes Redestad wrote:
Hi,
there was an issue with my patch for JDK-8037325 where the
hashCode imple
On 1/11/17 5:43 AM, Claes Redestad wrote:
List2.hashCode()
ListN.hashCode()
MapN.hashCode()
aren't overridden.
I'd like to see them added at some point, but if your benchmarks don't justify
them, maybe they're not necessary right now. If not, we should make a note to
add them later.
As they
On 1/10/17 3:50 AM, Claes Redestad wrote:
please review this change to improve startup/warmup characteristics
and performance of the immutable collection factories:
Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
Webrev: http://cr.openjdk.java.net/~redestad/8166365/webrev.01/
While filed
Hi Roger,
Change looks good. Thanks.
s'marks
On 12/7/16 1:20 PM, Roger Riggs wrote:
Please review a change to an warning message from rmid when the security policy
is incorrectly configured.
There is no reliable link to the rmid documentation that will remain accurate
across JDK versions.
The
Hi all,
Please review this small spec change to the Collectors.partitioningBy() methods,
appended below. This collector returns Map. The change
requires the implementation always to populate the returned map with entries for
both false and true keys.
The implementation already does this; the
));
to that method.
On Tue, Dec 6, 2016 at 1:28 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
Hi all,
Please review this small fix to adjust the behavior of
SingletonIterator.forEachRemaining in the case where its action throws an
exception:
http://
Hi all,
Please review this small fix to adjust the behavior of
SingletonIterator.forEachRemaining in the case where its action throws an exception:
http://cr.openjdk.java.net/~smarks/reviews/8166446/webrev.0/
Strictly speaking, this behavior is undefined (see the spec adjustment
JDK-8168
On 11/4/16 12:08 AM, Remi Forax wrote:
the static methods in ImmutableCollections do not need to be final there are
already static.
Oh yes, good point. I'll fix it. Thanks.
s'marks
Hi all,
Please review this small set of changes to the immutable collections to make the
zero-size instances singletons. (JDK-8156079)
This also includes a couple other small optimizations (JDK-8169222) to change
the expansion factor from floating point to integer, and also to avoid creating
+1
On 10/31/16 2:58 PM, Paul Sandoz wrote:
Hi,
Please review the following JavDoc fix for j.u.stream.Collectors::
collectingAndThen.
Thanks,
Paul.
diff -r 2e076c7e72d6
src/java.base/share/classes/java/util/stream/Collectors.java
--- a/src/java.base/share/classes/java/util/stream/Collectors.
Hi Roger,
The change looks good.
Thanks,
s'marks
On 10/31/16 11:05 AM, Roger Riggs wrote:
The client side support for the RMI multiplex protocol was removed in 1999, JDK
1.2.2 [1]
and is unused.
Please review a change to disable the server side RMI multiplex protocol by
default
and provide
On 10/18/16 11:00 AM, Martin Buchholz wrote:
There's already a certain amount of mixing, e.g. stream tests sometimes test
j.u.c. and Queue tests sometimes test all the Queue implementations. Unlike
non-test code, some redundancy and divergence of testing frameworks and styles
is fine. I still
On 10/17/16 6:34 PM, Martin Buchholz wrote:
Most of this is for Stuart - very collection-y.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
This includes a rewrite of ArrayDeque to bring it to parity with ArrayList
(except for List features).
The patch includes pu
On 10/17/16 5:16 PM, Paul Sandoz wrote:
On 17 Oct 2016, at 16:36, John Rose wrote:
On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote:
On 17 Oct 2016, at 15:01, Stuart Marks wrote:
Usually I wrinkle my nose at a throw that's caught by a catch clause later on,
but in this case it&
Hi all, please review this tiny fix to the javadoc markup in the Deprecated
annotation type.
Thanks,
s'marks
--- a/src/java.base/share/classes/java/lang/Deprecated.java Thu Oct 13 23:02:35
2016 +
+++ b/src/java.base/share/classes/java/lang/Deprecated.java Mon Oct 17 16:18:26
2016 -070
Hi Paul,
I took a look at the jdk changes. They look good to me.
One section of code gave me pause, which is the throw of ClassCastException at
339 of CallSite.java, and the throw of the exception returned from
wrongTargetType() at 344 of CallSite.java. This appears odd given the "rethrow
any
Tests passed, spec change approved, changeset pushed:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af71f6a36731
Jonathan, thanks for your contribution. And Patrick, thanks again for hosting
the webrev.
s'marks
On 10/12/16 6:53 AM, Jonathan Bluett-Duncan wrote:
Hi all,
Thank you very mu
to
On 10/11/16 4:03 PM, Stuart Marks wrote:
On 10/10/16 11:26 PM, Andrej Golovnin wrote:
src/java.base/share/classes/java/util/ResourceBundle.java
2490 public static class Control {
2491 /**
2492 * The default format List, which contains
the strings
2493 * &
On 10/10/16 11:26 PM, Andrej Golovnin wrote:
src/java.base/share/classes/java/util/ResourceBundle.java
2490 public static class Control {
2491 /**
2492 * The default format List, which contains the strings
2493 * "java.class" and "java.properties", in
2494
-1 (character)
j/k, LGTM
On 10/11/16 2:30 PM, Joseph D. Darcy wrote:
+1
-Joe
On 10/11/2016 2:27 PM, Paul Sandoz wrote:
Hi,
I accidentally fat fingered the JavaDoc of Stream which got consumed into an
unrelated patch that i pushed [1]. Thanks go to Martin for noticing this.
Paul.
[1] http:
gt;
> Kind regards,
> Jonathan
>
> On 6 October 2016 at 09:38, Stephen Colebourne mailto:scolebou...@joda.org>> wrote:
> On 6 October 2016 at 00:00, Stuart Marks mailto:stuart.ma...@oracle.com>> wrote:
> >> I think you shou
On 10/7/16 3:12 PM, Stefan Zobel wrote:
... After having looked at lots of generic APIs, it seems to me that a
style has emerged where wildcards are used whenever possible, and type
parameters are used only when necessary, ...
Yes, I'm familiar with that kind of reasoning (I think Josh Bloch
On 10/7/16 12:40 PM, Stefan Zobel wrote:
What's wrong with the alternative "additional bounded type parameter" approach?
Couldn't we also get by with something like
Optional flatMap(Function> mapper)
and
Optional or(Supplier> supplier)
Personally, I find that much easier to digest. But tha
On 10/7/16 1:09 PM, Andrej Golovnin wrote:
267 public Optional flatMap(Function> mapper)
I think there should be a space between “public” and “”.
Sure, I'll add this. There's also a space missing at a similar spot at the map()
declaration; I'll fix that too.
thanks
s'marks
On 10/7/16 11:23 AM, Paul Sandoz wrote:
flatMap(Function> mapper)
Optional is final so why do you need to express “? extends Optional” ?
The short answer is, it doesn't work if you don't have it. :-)
The theoretical answer is that in this context, "? extends P" means "some
subtype of P
Hi all,
Please review this small API adjustment to Optional.or and flatMap to add
wildcards. This provides a bit more flexibility to callers about the types of
functions they can provide to these methods.
The or() method is new in 9 so there is no compatibility issue.
The flatMap() method wa
On 10/5/16 10:04 AM, Andrew Haley wrote:
On 05/10/16 17:55, Vladimir Ivanov wrote:
On 10/5/16 7:39 AM, Justin Sampson wrote:
My interpretation of Martin's comment is that using deprecation for
things that aren't actually broken just means that people will live
with lots of deprecation warning
On 10/5/16 12:32 PM, Stephen Colebourne wrote:
On 5 October 2016 at 17:07, Jonathan Bluett-Duncan
wrote:
Stephen, thank you for getting back about DateTimeFormatter. It's not clear
to me what should be done with
TCKDateTimeFormatter::test_resolverFields_listOfOneNull in this case. Do I
delete
Stephen,
Thanks for the quick followup clarifications. I'm not entirely sure how you'd
like to proceed; see discussion below.
Jonathan, also see below.
On 10/5/16 9:07 AM, Jonathan Bluett-Duncan wrote:
Stuart, thank you very much for your continued review of this changeset, and for
finding
eeded much better than the comment itself does. So
I wonder if it's worth adding the link to the bug report in the comment.
E.g.
// prevent generation of synthetic class required for access to private
// constructor. See: https://bugs.openjdk.java.net/browse/JDK-8167005
Kind rega
On 9/30/16 6:57 AM, Jonathan Bluett-Duncan wrote:
1) It actually didn't occur to me that there was a potential TOCTOU problem in
ModuleFinder.compose, despite the fact that I found a potential problem in
FileTreeIterator - it completely missed me, so thank you for finding it! I'll
see if I can
On 10/4/16 3:55 AM, Claes Redestad wrote:
On 2016-10-04 12:52, Aleksey Shipilev wrote:
On 10/04/2016 12:50 PM, Claes Redestad wrote:
Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/
OK.
Thanks for the speedy review! :-)
Thanks for looking at this. The shorter text in the
On 9/28/16 4:48 AM, Claes Redestad wrote:
as discussed recently on hotspot-compiler-dev[1], having a private class with no
default constructor can lead to C2 failing to inline, due to the synthetic
bridge constructor using a dummy argument of an uninitialized class. This is
really a problem in
On 9/22/16 11:13 PM, Kasper Nielsen wrote:
I accidently bumped into an old friend today
https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html
There are couple of questions that might need an update after Java 8. Such
as
Why don't you provide an "apply" method in Col
tml/StreamParallelGuidance.html> is pretty much
the iconic document on that subject, and explains circumstances under which
parallelism is good, and when it is likely to be harmful.
Stuart Marks and Brian Goetz gave an excellent talk on this at JavaOne last
week.
You can view it here. The talk is called "
methods
which either return instances of `Serializable` classes or whose javadoc
mention that the returned object is serializable. So I'm somewhat certain that
my changes are serialization-compatible, but only somewhat, because I'm not
that familiar with the intricacies of seriali
Hi all,
Unfortunately I don't have time to work on any of this at the moment, because of
JavaOne preparation, and JavaOne next week.
Jonathan, thanks for pushing forward with this. I'm glad that others have picked
it up.
Patrick, thanks for posting the changeset on Jonathan's behalf. This i
s proposed that will cover the needs of implementations currently
using java.lang.Compiler, this can change. Perhaps in the Java SE 10 timeframe.
Thanks,
Kris (OpenJDK username: kmo)
On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
Hi al
676 <https://bugs.openjdk.java.net/browse/JDK-8041676> java.compiler
property is uninitialized
On 9/7/2016 4:52 PM, Stuart Marks wrote:
Hi all,
Please review this small patch to deprecate java.lang.Compiler for removal.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 14732
in point/ in the program.
What JEP 165 is proposing can only statically configure JIT behaviors for
HotSpot. The same approach doesn't seem to cover what J9 used to support.
Could you please share more background on the discussions that led to the
decision?
Thanks,
Kris
On Wed, Sep 7, 2016
e with the
method compileClasses(String).
I'm glad this class will disappear soon.
Rémi
- Mail original -
De: "Aleksey Shipilev"
À: "Stuart Marks" , "core-libs-dev"
Envoyé: Mercredi 7 Septembre 2016 23:34:02
Objet: Re: RFR(s): 4285505: deprecate
Hi all,
Please review this very small patch to add a bit of boilerplate text to the
@deprecated text for Runtime.traceInstructions() and Runtime.traceMethodCalls()
specifications.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1473283632 25200
# Wed Sep 07 14:27:12 2016 -070
Hi all,
Please review this small patch to deprecate java.lang.Compiler for removal.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1473281459 25200
# Wed Sep 07 13:50:59 2016 -0700
# Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d
# Parent 76ba1b74f268f1acc4847e242a2cfcd29880
On 9/1/16 8:41 PM, Martin Buchholz wrote:
Looks good to me!
Thanks!
Another idea for another day: I would like the immutable collections to be
more optimal than they currently are, even if we have to write more code. It
bugs me is that all of these collections have a modCount, despite never b
ood deal more rigor,
and they go through extra rounds of review.)
Anyway, I hope you find something of interest. I'm going heads-down to prepare
for JavaOne (Sep 18-22) but I'll try to keep an eye out for followup messages.
s'marks
[1] http://mail.openjdk.java.net/pipermail/jd
Hi all,
Please review this change to make the immutable collections (List.of, Set.of,
Map.of) throw UnsupportedOperationException unconditionally. That is, they
should throw UOE even if a mutator method is called with arguments that make it
a no-op. Calling a mutator method on an immutable col
Hi Paul,
Overall looks good.
A couple minor wording comments. For the 3-arg collectors, the combiner arg is
defined as
* @param combiner an associative,
*href="package-summary.html#NonInterference">non-interfering,
*stateless
*f
On 7/7/16 12:16 PM, mark.reinh...@oracle.com wrote:
New JEP Candidate: http://openjdk.java.net/jeps/293
Hi Jon,
Good writeup and rundown of the issues.
I have a few questions to raise.
options can allow an argument to be provided
This describes an option with an optional argument. I rec
Great, the test looks much better now.
Thanks!
s'marks
On 6/14/16 3:34 PM, Xueming Shen wrote:
Thanks Stuart!
webrev has been updated accordingly based on your suggestion.
http://cr.openjdk.java.net/~sherman/8072582_8139414/webrev
-Sherman
On 6/14/16, 1:22 PM, Stuart Marks wrote
Hi Sherman,
The fix looks good.
It would be helpful if the test for 8072582 generated the string instead of
using a literal that's more than 1K long. The exact length is significant
because Scanner's default buffer size is 1024, so the delimiter has to straddle
the buffer boundary.
The 8139
On 6/1/16 4:15 PM, Richard Hillegas wrote:
[deprecation warnings]
This was the issue which I faced. The Derby community has spent considerable
effort on maintaining a clean build, one which doesn't swamp real error
indications in a blizzard of diagnostic noise. At the same time, we are
relucta
I think "frequently" is an understatement. :-)
This looks fine; please go ahead with it.
Thanks.
s'marks
On 6/2/16 11:48 AM, Rajan Halade wrote:
May I request you to review this patch to mark DGCDeadLock.java test with key
intermittent. This test fails frequently.
Bug: https://bugs.openjdk.j
On 5/31/16 6:31 PM, Joseph D. Darcy wrote:
The String.join javadoc contains some sample code to demonstrate how to use the
method. The sample code can be improved with the new-in-JDK-9 List convenience
factory method. Please review this patch to update the sample code:
--- a/src/java.base/share/
On 5/30/16 11:48 AM, Richard Hillegas wrote:
Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my
feedback after ameliorating the deprecation warnings which surfaced when I
compiled and tested Apache Derby with early access builds 116 and 118 of JDK 9.
Derby is a pur
Hi all,
Please review this small test fix to improve the reliability of an RMI test.
Basically this waits for a subprocess to exit instead of proceeding immediately.
webrev:
http://cr.openjdk.java.net/~smarks/reviews/815/webrev.0/
bug:
https://bugs.openjdk.java.net/browse/JDK-81
On 5/26/16 2:28 PM, Mandy Chung wrote:
-return h.keySet();
+return Set.of(h.keySet().toArray(new String[0]));
}
The patch looks fine. It’d be good to add a test case.
If you use Collections.unmodifiableSet, you would not need to convert the key
sets to an array. Any ben
On 5/25/16 5:27 PM, Mandy Chung wrote:
On May 25, 2016, at 5:11 PM, Stuart Marks wrote:
On 5/25/16 4:58 PM, Mandy Chung wrote:
Have you considered fixing this method to return a unmodifiable set and make
this spec in JDK 9? It’s a small change.
I did think about changing the behavior
On 5/25/16 4:58 PM, Mandy Chung wrote:
Have you considered fixing this method to return a unmodifiable set and make
this spec in JDK 9? It’s a small change.
I did think about changing the behavior here but I decided against it because of
the small compatibility risk. The main issue here is t
Hi all,
Please review this small spec change. Properties.stringPropertyNames() seems to
imply that the Set it returns is modifiable. It is, but only partially. Since
it's a keySet() from a Hashtable, it supports removal but not addition. This
change removes the implication that the returned se
Hi all,
Please review this updated webrev/specdiff. Changes since previous:
- removal of mention of CollSer from the API specification
- make CollSer's Object[] field transient, and handle its contents
as custom serial data in readObject/writeObject
- specification changes to reflect t
On 5/18/16 2:42 AM, Stephen Colebourne wrote:
My original blog on the topic was in 2010:
http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html
Bear in mind that a key reason for sharing the serialization proxy is
to share the "serialized object header, serial version UID, class
d
On 5/17/16 1:09 PM, Peter Levart wrote:
I don't think it's possible to have a single form for all new serializable
objects in java.util. The java.util package isn't as cohesive as java.time.
There's a bunch of random stuff in it. Consider the non-serializable things
currently in java.util:
On 5/17/16 3:43 AM, Chris Hegarty wrote:
The JSR 310 Serialization framework is a little more involved, as you know.
I wonder if it is worth following that pattern more closely here? That way
java.util.Ser could be a generic proxy for all new Serializable types in the
java.util package, and not j
On 5/17/16 1:55 AM, Stephen Colebourne wrote:
Stuart, I disagree with using an int for the flags, it should be a byte. If
you need future expansion you can use 0xff to indicate it with the parser
reacting accordingly. That is the strategy for JSR 310
These techniques have different goals.
I do
On 5/17/16 3:33 AM, Peter Levart wrote:
On 05/17/2016 10:55 AM, Stephen Colebourne wrote:
CollSer should not be public, especially not just for serialization
reasons.
I don't see a compelling reason why. Javadocs mention it by name. By making it
Serializable, it is effectively public, so it ca
Hi all,
Please review this changeset that adds specifications of the serialized forms
(really, a single serialization proxy class) for the immutable collections
implementation. There are no code changes in this changeset, just documentation.
It's somewhat odd, but the class doc for the serial
On 5/11/16 2:37 PM, Martin Buchholz wrote:
The problem is again that the library maintainer is not the same as
the compiler invoker.
A conscientious library maintainer does not stop at ensuring that
their own builds are warning free; they want to ensure as much as they
can that their users can al
701 - 800 of 1414 matches
Mail list logo
