Hello!
This is inspired by a recent fix for JDK- 8210004 (Thread.sleep(millis,
nanos) timeout returns early).
Currently, Object.wait(Long.MAX_VALUE, 1) would throw
"IllegalArgumentException: timeout value is negative", which is not
accurate.
Would you please help review the fix?
BUGURL:
Hello Peter,
On 14/09/18 1:03 PM, Peter Levart wrote:
>
> The check for main class is performed after compilation (which
> actually produces the main class name).
>
> I think it would be possible to check for all classes compiled from
> the source file after compilation without to much
Hello!
Tomasz, Peter, Stuart, Remi, thank you for review and comments. I
updated the webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r5/
1. ? extends R -> R
2. parameter names c1, c2 -> downstream1, downstream2;
Objects.requireNonNull messages updated correspondingly
merger is left as
On 9/14/18 10:57 AM, Alan Bateman wrote:
http://cr.openjdk.java.net/~alanb/8210496/webrev/index.html
This looks good.
I like Peter's suggestion to simplify line 292-301 and 307-316 in
Reflection.java
and replace the loop with filteredNames::contains check.
Mandy
Looks like you got them all - reviewed.
-Brent
On 09/14/2018 04:09 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html
36 lines changed: 0 ins; 0 del; 36 mod;
Hi all,
could you please review this small and trivial follow-up fix for 8182404 and
http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html
> 36 lines changed: 0 ins; 0 del; 36 mod;
Hi all,
could you please review this small and trivial follow-up fix for 8182404 and
8210732? I have forgot to update copyright years as a part of these two
changesets, this patch
2018/9/13 10:21:26 -0700, roger.ri...@oracle.com:
> Consider:
>
> public class SearchPath {
> public static SearchPath of(String searchPath) {...}
> public static SearchPath of(List elements) {...}
> public Stream stream() {...}
> public List asList() {...}
> public String toString() {...}
>
Seth, this is not so much "compiler semantics" vs "launcher semantics"
... it's just "ClassLoader semantics", combined with the fact that an
empty class path defaults to the current directory.
In the source launcher, the compiler is not worried about the classes in
the current directory.
ah - compiler semantics vs launcher semantics, and the source code launcher
lives in both worlds
javac refuses to compile two sources for the same class
javac will compile a source file for a class that exists on the classpath
(and even overwrite a class on the classpath)
java accepts two class
+1
Mandy
On 9/14/18 2:48 PM, Phil Race wrote:
bug : https://bugs.openjdk.java.net/browse/JDK-8210766
The sun.applet implementation was removed a few days ago,
see http://hg.openjdk.java.net/jdk/client/rev/26a17d160081
This removed AppletClassLoader which consumed a class in sun.net.www
and
bug : https://bugs.openjdk.java.net/browse/JDK-8210766
The sun.applet implementation was removed a few days ago,
see http://hg.openjdk.java.net/jdk/client/rev/26a17d160081
This removed AppletClassLoader which consumed a class in sun.net.www
and thus needed a qualified export to java.desktop from
Alan, JC, thank you both for review
-- Igor
> On Sep 13, 2018, at 11:53 PM, Alan Bateman wrote:
>
>
>
> On 14/09/2018 01:07, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
>>> 478 lines changed: 3 ins; 319 del; 156 mod;
>> Hi all,
>>
>> could you
Hi all,
Stuart, thanks for your response and explanations, I really appreciate it!
Good point about function composition - didn't cross my mind, but it could
be confusing indeed.
As for "merger" - good point about "biFinisher", but I'm still unconvinced
about "merger", because usually, you
Hi Alan,
Just a few comments about implementation.
In Reflection:
292 boolean shouldSkip = false;
293 for (String filteredName : filteredNames) {
294 if (member.getName() == filteredName) {
295 shouldSkip = true;
296
Hi,
I've already sent an email to this list regarding this issue, but I'm not
sure if it finally made its way. So here I'm sending something again w.r.t
the name...
duplexing might be OK, but
collectingBothAndThen
is hard to beat.
Arguments:
- Existing collectingAndThen method is the simpler
On 9/13/18 7:52 PM, Stuart Marks wrote:
I'd guess that security-dev would have reviewers for the change to
default.policy. Cc'd.
The default.policy file change looks like this is not specifically
related to this change because the jdk.desktop module no longer exists.
I guess it is ok to
Looks good.
Naoto
On 9/14/18 5:54 AM, Rachna Goel wrote:
Hi,
Kindly review fix to JDK-8210490.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210490
Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/
This is a regression caused by JDK-8202537, where for timezones such as
On 14/09/2018 18:52, Alan Bateman wrote:
Core reflection has a filtering mechanism to hide a number of fields
that are critical to security or the integrity of the runtime. It's a
bit of a band aid but it helps to reduce hacking on fields such as
java.lang.System.security and
Core reflection has a filtering mechanism to hide a number of fields
that are critical to security or the integrity of the runtime. It's a
bit of a band aid but it helps to reduce hacking on fields such as
java.lang.System.security and java.lang.Class.classLoder. I'd like to
extend the filters
Seth,
The reason for reporting an error is to prevent the "wrong" class being
used!
-- Jon
On 09/14/2018 10:14 AM, seth lytle wrote:
this behavior of throwing an error if the class is found twice on the
classpath strikes me as unusual - afaik, in all other cases, java is fine
with finding
On 9/14/18 4:01 AM, Daniel Fuchs wrote:
Hi Mandy,
Looks good to me as well.
If a JDK 12 exception is deserialized by an earlier version of
the JDK, then the deserialized exception will have both its
cause field and custom exception field set to the cause
(instead of having the cause field
Thanks for the status update and insightful details, Sherman, they’re much
appreciated.
Kind regards,
Anthony
From: core-libs-dev on behalf of
Xueming Shen
Sent: Friday, September 14, 2018 12:38:28 AM
To: core-libs-dev@openjdk.java.net
Subject: Re:
this behavior of throwing an error if the class is found twice on the
classpath strikes me as unusual - afaik, in all other cases, java is fine
with finding multiple implementations on the classpath and uses the first
found (similar to the unix path, which also allows overriding by providing
an
Hi Tagir, thanks for the update.
Also thanks Tomasz for keeping everybody honest on the open issues.
First, naming. I think "duplex" as the root word wins! Using "duplexing" to
conform to many of other collectors is fine; so, "duplexing" is good.
Unfortunately "duplex" is not really a verb.
Hi Daniel,
The additional advance is made when the pair has already been written,
which is indicated by the return value of writeUTF16Surrogate being >=
0*. Encodings.isHighUTF16Surrogate(ch) therefore would be redundant.
* Note that the return value is: -1 when nothing is written, 0 when
Hi,
I'd like to remind three little things to which there was no response
(AFAIK):
1) Brian Goetz' suggestion of changing "? extends R" into "R":
-
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054947.html
2) Stuart Marks' suggestion about renaming "c1" and "c2" to
Hi Goetz and Severin,
On 09/14/2018 07:12 AM, Lindenmaier, Goetz wrote:
Hi,
We are only talking about reducing O3 to O2 for the compilation
step of fdlibm, right?
Yes.
As I know, this is being replaced by Java coding, anyways.
Therefore I don't have a strong opinion for any of the
Hi,
Kindly review fix to JDK-8210490.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210490
Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/
This is a regression caused by JDK-8202537, where for timezones such as
Etc/GMT-5, display names got formatted according to default
Hello,
Can I, please, have an approval to backport JDK-8193830 to jdk8u-dev?
Webrev:
http://cr.openjdk.java.net/~aefimov/8193830
JBS:
https://bugs.openjdk.java.net/browse/JDK-8193830
JDK11 review:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051230.html
JDK11 changeset:
Hi Mandy,
Looks good to me as well.
If a JDK 12 exception is deserialized by an earlier version of
the JDK, then the deserialized exception will have both its
cause field and custom exception field set to the cause
(instead of having the cause field null and the custom field
carrying the
I'm neither Stuart nor Peter but this looks good to me.
Rémi
- Mail original -
> De: "Tagir Valeev"
> À: "Stuart Marks"
> Cc: "core-libs-dev"
> Envoyé: Vendredi 14 Septembre 2018 10:41:53
> Objet: Re: RFR: JDK-8205461 Create Collector which merges results of two
> other collectors
>
Hi Chris,
> http://cr.openjdk.java.net/~xyin/8210695/webrev.01/
Looks good to me.
> Yep, fixed as you suggested. My original though is that the stack
trace maybe too verbose if most of runs hit NamingException, leave it to
stderr may make the log more readable, but yes, the exception is
Hi,
We are only talking about reducing O3 to O2 for the compilation
step of fdlibm, right?
As I know, this is being replaced by Java coding, anyways.
Therefore I don't have a strong opinion for any of the
choices.
Best regards,
Goetz.
> -Original Message-
> From: core-libs-dev On
Hi Joe,
Thanks for doing that - it's a far better solution.
ToHTMLStream.java:
1432// move the index if the surrogate pair has been written.
1433if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
1434i++;
1435}
shouldn't this be:
1433if (writeUTF16Surrogate(ch, chars,
On 2018-09-14 10:50, Markus Gronlund wrote:
Hi Magnus, Erik and Alan,
Came to think of this issue in relation to this discussion:
https://bugs.openjdk.java.net/browse/JDK-8207139
It might provide some additional information, especially since it describes an
issue we recently ran into that
Hi Tagir,
I like duplexing more than teeingAndThen. If consensus can be
established about the name, I think you will then want to update the CSR
draft to reflect new name. Then we'll kindly ask Stuart if he has any
more advice before submitting the CSR...
Regards, Peter
On 09/14/2018 10:41
Hi,
On Thu, 2018-09-13 at 20:29 -0300, Gustavo Romero wrote:
> Hello Severin,
>
> On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
> > Hi David,
> >
> > On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> > > Hi Severin,
> > >
> > > Sorry I'm a bit confused now.
> > >
> > > Originally for
Hi Magnus, Erik and Alan,
Came to think of this issue in relation to this discussion:
https://bugs.openjdk.java.net/browse/JDK-8207139
It might provide some additional information, especially since it describes an
issue we recently ran into that was related to static linking.
Thanks
Markus
Hello, Stuart and Peter!
Thank you for valuable comments. I updated the webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
"-ing" suffix shall present and I agree. Hopefully it's final name.
2. I updated the spec as
Hi Jaikiran,
Forwarding to compiler-dev as the core of source file launcher feature
is produced there...
The check for main class is performed after compilation (which actually
produces the main class name).
I think it would be possible to check for all classes compiled from the
source
On 2018-09-14 01:17, Erik Joelsson wrote:
I checked and the copying of java.exe was done in the now legacy jre
installer, so from what I can tell, there is no longer a need for
static linking.
Sounds good. I agree with your reasoning, it seems the main concern was
the copy to the system
On 14/09/2018 01:07, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
478 lines changed: 3 ins; 319 del; 156 mod;
Hi all,
could you please review the next clean up in jdk testlibrary which removes
jdk.testlibrary.Utils class?
webrev:
42 matches
Mail list logo
