On 5/27/20 12:24 AM, David Holmes wrote:
Hi Mandy,
On 27/05/2020 7:46 am, Mandy Chung wrote:
Lookup::defineHiddenClass currently throws IAE by ASM if the given
bytes are of unsupported class file version. The implementation
should catch and throw UnsupportedClassVersionError instead.
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/
I modify this patch to check the class file version and throws CFE if
unsupported before creating ClassReader. This also fixes JDK-8245061
that it reads the value of `this_class` as a constant (as ASM will
I'll wait for your thumbs up on the explanation.
I'm good with the explanation. Thanks!
Dan
On 5/27/20 10:08 PM, David Holmes wrote:
Hi Dan,
Thanks for taking a look.
On 28/05/2020 1:09 am, Daniel D. Daugherty wrote:
On 5/26/20 12:59 AM, David Holmes wrote:
bug:
Hi Dan,
Thanks for taking a look.
On 28/05/2020 1:09 am, Daniel D. Daugherty wrote:
On 5/26/20 12:59 AM, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8242504
webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
src/hotspot/os/posix/os_posix.hpp
No comments.
Hi Raffaello,
Finishing the fdlibm port remains on my to-do list. Given the review
investment needed, I would not find it helpful for someone else to
contribute a port.
Thanks,
-Joe
On 5/25/2020 9:24 AM, Raffaello Giulietti wrote:
Hi,
[1] enumerates 14 StrictMath native functions that
Hi David,
Please review this updated webrev:
Incremental webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/
full webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/
It includes the following changes:
* Indentation and simplification changes
On 2020-05-27 22:00, Paul Sandoz wrote:
That’s rather elegant. Nicely done.
Paul.
Thanks, Paul!
/Claes
On 2020-05-27 21:34, fo...@univ-mlv.fr wrote:
http://cr.openjdk.java.net/~redestad/8245969/open.01
OK?
Ok !
Thanks, Rémi!
/Claes
That’s rather elegant. Nicely done.
Paul.
> On May 27, 2020, at 8:50 AM, Claes Redestad wrote:
>
> Hi Rémi,
>
> thanks for looking at this.
>
> On 2020-05-27 17:12, Remi Forax wrote:
>> Hi Claes,
>> so instead of having a prefix and a suffix, there is only a prefix, a suffix
>> being seen
- Mail original -
> De: "Claes Redestad"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 27 Mai 2020 17:50:19
> Objet: Re: RFR: 8245969: Simplify String concat constant folding
> Hi Rémi,
>
> thanks for looking at this.
>
> On 2020-05-27 17:12, Remi Forax wrote:
>> Hi
Hi Lance, thanks for taking a look at this.
On 5/27/20 4:56 AM, Lance Andersen wrote:
I think this looks good. I will add myself as a reviewer for the CSR.
I would probably create an issue for the release note and create a draft I
believe I was asked for that when I was going through my CSR
On 5/27/20 6:34 AM, Roger Riggs wrote:
rmid.properties: 134; avoid breaking "have\n been" in to separate lines.
I would break after the ",".
Line break adjusted.
module-info.java: 35: "version" -> "release" for consistency across the
messages.
package-info.java: 41: "version" ->
Thanks, Paul!
/Claes
On 2020-05-27 21:20, Paul Sandoz wrote:
Looks good.
Paul.
On May 27, 2020, at 5:54 AM, Claes Redestad wrote:
Hi,
Since JDK-8222852 the default String concat strategy aggressively folds
string constants into prepender method handles, which means an
expression like foo
Looks good.
Paul.
> On May 27, 2020, at 5:54 AM, Claes Redestad wrote:
>
> Hi,
>
> Since JDK-8222852 the default String concat strategy aggressively folds
> string constants into prepender method handles, which means an
> expression like foo + bar and one like "x" + foo + "y" + bar + "z" will
Hi,
not sure if the lack of replies means that my previous post has been
overlooked?
Greetings
Raffaello
On 2020-05-25 18:24, Raffaello Giulietti wrote:
Hi,
[1] enumerates 14 StrictMath native functions that still need a Java
porting from the original C code.
As of changeset
I'm reconsidering this fix along with JDK-8245061 that may require to do
its own checking (a similar issue w.r.t. ASM validation but in this case
the constant pool entry of `this_class` item is not validated).
thanks
Mandy
On 5/27/20 10:39 AM, fo...@univ-mlv.fr wrote:
Hi Alan,
We (the ASM
Hi Alan,
We (the ASM team) recommend to our users to check the byte 6 (and perhaps 7)
instead of relying on ASM throwing an exception,
because you may update the version of ASM but not the visitors your are using
in your code.
It's less brittle than catching the IAE thrown by ASM.
Rémi
-
http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00
> 8 lines changed: 2 ins; 0 del; 6 mod;
Hi all,
could you please review this small and trivial cleanup in TEST.ROOT files of
test/jdk/ and test/hotspot/jtreg test suites?
from JBS:
> to make sure that classes listed in
On 26/05/2020 22:46, Mandy Chung wrote:
Lookup::defineHiddenClass currently throws IAE by ASM if the given
bytes are of unsupported class file version. The implementation
should catch and throw UnsupportedClassVersionError instead.
webrev:
Hi Rémi,
thanks for looking at this.
On 2020-05-27 17:12, Remi Forax wrote:
Hi Claes,
so instead of having a prefix and a suffix, there is only a prefix, a suffix
being seen as a prefix for the next iteration
and if at the end instead of just allocating an array, you allocate an array
and
Hi Claes,
so instead of having a prefix and a suffix, there is only a prefix, a suffix
being seen as a prefix for the next iteration
and if at the end instead of just allocating an array, you allocate an array
and stuff it with the last prefix.
Are you sure having a suffix at the end is
On 5/26/20 12:59 AM, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8242504
webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
src/hotspot/os/posix/os_posix.hpp
No comments.
src/hotspot/os/posix/os_posix.inline.hpp
No comments.
Hello Aleks,
I mean “com.sun.jndi.ldap.connect.timeout” property.
The positive value forces to start TLS handshake and wait for it completion
during the connectTimeout milliseconds:
Connection.java
>> if (connectTimeout > 0) {
>> int socketTimeout = sslSocket.getSoTimeout();
>>
Hi,
please review this patch to StringConcatFactory which (I think)
simplifies the folding of constants around arguments by folding any
suffix constant into the newArray combinator instead.
This simplifies the code in all prependers and in the general flow of
the bootstrap code, at the cost of
Hi Max,
You are right, It is possible that algorithm name is not confirm
With format.
As soon as RFC5929 does not specify this situation I would suggest to use
“SHA-256” hash instead of throwing SaslException exception.
Regards
Alexey
> On 27 May 2020, at 13:25, Weijun Wang wrote:
>
>
>
looks good
curious why app.identifier was added to cfg file. I don't see it used
anywhere.
/Andy
On 5/26/2020 3:26 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Get rid of duplicated code parsing version strings. Move the code
parsing version strings to dedicated
Hi Stuart,
Looks good.
rmid.properties: 134; avoid breaking "have\n been" in to separate lines.
I would break after the ",".
module-info.java: 35: "version" -> "release" for consistency across the
messages.
package-info.java: 41: "version" -> "release" and "it may" -> "may" to
be
Hi Alexey,
I have question about timeouts:
LdapCtx has 2 timeout properties: connectTimeout and readTimeout.
First one is for controlling the Socket::connect timeout
(Connection::createSocket), another - for reading out the replies
(Connection::readReply).
Both of them have default values set
Hi,
Since JDK-8222852 the default String concat strategy aggressively folds
string constants into prepender method handles, which means an
expression like foo + bar and one like "x" + foo + "y" + bar + "z" will
have similar shape, but take slightly different paths through generated
code.
This
Hi Stuart,
I think this looks good. I will add myself as a reviewer for the CSR.
I would probably create an issue for the release note and create a draft I
believe I was asked for that when I was going through my CSR review for removal
of the Java EE modules and CORBA.
Best
Lance
> On May
Hello Bernd,
> On 27 May 2020, at 13:12, Bernd Eckenfels wrote:
>
> LdapCtxt:
> 2568 /**
> 2569 * Sets the read timeout value
> 2570 */
> 2571 private void setChannelBindingType(String cbTypeProp) {
Thank you. This is misprint. Should be “Sets the channel binding type”
About
> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>
> The hash algorithm is selected on the base of the certificate
> signature algorithm.
> Also, the client should use SHA-256 algorithm, in case of the
> certificate signature algorithm is SHA1 or MD5
According to
LdapCtxt:
2568 /**
2569 * Sets the read timeout value
2570 */
2571 private void setChannelBindingType(String cbTypeProp) {
Not sure if that javadoc is the right one? And I also wonder if enforcing the
timeout is needed, and if yes if it should be documented why. Was not
Hello Valerie,
Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not
accept GSS_C_AF_NULLADDR address type.
This is exact reason of these changes.
I’ve tried to fix inconsistency of address type value in the latest webrev:
Hi Mark,
On 27/05/2020 2:15 am, Mark Kralj-Taylor wrote:
David,
Thanks for taking this enhancement, and making it work on the older
glibc (pre 2.17) Linux platforms currently supported by openjdk.
I like that it is a small change to split the JVM startup check on
availability of Posix
Hi Daniel,
Thanks for the review on the API side, and for the detailed
consideration of any potential spec issues - of which they are none I'm
glad to say.
Cheers,
David
On 27/05/2020 1:35 am, Daniel Fuchs wrote:
Hi David,
This is not a review for the posix code.
Your webrev looks good
Hi Mandy,
On 27/05/2020 7:46 am, Mandy Chung wrote:
Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes
are of unsupported class file version. The implementation should catch
and throw UnsupportedClassVersionError instead.
webrev:
Thanks Roger!
David
On 27/05/2020 12:28 am, Roger Riggs wrote:
Looks good.
Thanks to Mark and you for the improvement and testing.
On 5/26/20 12:59 AM, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8242504
webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
38 matches
Mail list logo
