Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

Hi Seth, I think we've both been chasing red herrings :) The classloader is not relevant. I can run the test with everything loaded as normal by the app loader and it still gets the ClassCastException. Searching JBS it seems that serialization of lambdas is broken - ref:

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

On 26/03/2019 2:03 pm, seth lytle wrote: it's a nested class, but it's loaded with the same class loader as the toplevel. which is what i thought you thought was the problem when Sorry, hard to see all the diffs inside the email. Not sure what relevance splitting into two files has given the

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

it's a nested class, but it's loaded with the same class loader as the toplevel. which is what i thought you thought was the problem when you wrote: > this test loads a nested type into a different classloader to its enclosing type and: > it is a requirement that all nest members be defined in

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 3/25/19 11:36 AM, Adam Farley8 wrote: Addendum: URL for new webrev: http://cr.openjdk.java.net/~afarley/8216558.1/webrev/ Thanks for sending a versioned webrev. > What is a USA test? UNREFLECT_SETTER_ACCESSIBLE. I was trying to be brief, and I lost readability. Will re-upload with

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

On 26/03/2019 1:06 pm, seth lytle wrote: i still get the same stack trace after breaking the example out into two files. does that sufficiently address the nesting issue ? ?? public static class MyCode ... is still a nested class. David file: SerializedLambdaTest package test; import

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

i still get the same stack trace after breaking the example out into two files. does that sufficiently address the nesting issue ? file: SerializedLambdaTest package test; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi Goetz, On 3/15/19 3:55 AM, Lindenmaier, Goetz wrote: I followed your advice and created a JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 This is a good start.   I include my comments as a reader who does not read TrackingStackCreator and other C++ code. In the "Basic algorithm to

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

Hi Seth, On 26/03/2019 12:16 pm, seth lytle wrote: i haven't changed the assignment from the original test case (which was accepted as valid at the time). i haven't gone through it in depth, but assume that it's ok and used it since people are already familiar with it. it appears to me that

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

i haven't changed the assignment from the original test case (which was accepted as valid at the time). i haven't gone through it in depth, but assume that it's ok and used it since people are already familiar with it. it appears to me that that example uses reflection to allocate an instance

Re: ClassCastException: cannot assign SerializedLambda to field with ClassLoader

Hi Seth, On 26/03/2019 11:22 am, seth lytle wrote: if a lambda is a field and captures `this`, and it's deserialized into a new class loader, it throws a ClassCastException. Not sure I follow. If you load a class into a different classloader then you get a different type. It might appear

ClassCastException: cannot assign SerializedLambda to field with ClassLoader

if a lambda is a field and captures `this`, and it's deserialized into a new class loader, it throws a ClassCastException. i came across this bug independently while writing a test, but then found an old openjdk bug with a similar issue and tweaked the test case (source below). my version differs

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Thanks Andrew! Introducing getCharSequenceCoder() is actually an enhancement, which may improve pre-allocation in certain cases. It's not actually required to restore correctness of StringBuilder/Buffer constructors. I recommend to separate it from this bug fix, so it can be discussed

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Ivan, Here is my updated webrev: http://cr.openjdk.java.net/~aleonard/8221430/webrev.01/ Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: Ivan

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Yes, I think organizing it the same as the (int) constructor would be good for consistency. I will update my patch with that, Thanks Ivan Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email:

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

I was thinking of organizing code similar to what is done in AbstractStringBuilder(int): if (COMPACT_STRINGS && coderHint == LATIN1) { value = new byte[capacity]; coder = LATIN1; } else { value = StringUTF16.newBytesFor(capacity); coder = UTF16; } With kind regards, Ivan On

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Ivan, I think I see what you're saying, you mean we also need to correct this line in AbstractStringBuilder constructor: value = (coder == LATIN1) ? new byte[capacity] : StringUTF16.newBytesFor(capacity); to be maybe: value = (COMPACT_STRINGS && coder == LATIN1)

Re: RFR: JDK-8215019: Allow --install-dir on windows

Hi Andy, http://cr.openjdk.java.net/~almatvee/8215019/webrev.01/ Updated webrev with added missing message in HelpResources_zh_CN.properties and updated messages below: MSG_Help_win_install_dir=\ \Relative sub-path under the default installation location\n\

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Andrew! Thanks for finding this bug! Your fix solves the problem. However, I think the main issue is that the constructor AbstractStringBuilder(byte,int,int) is now broken: as you discovered, it allows to create a string buffer with the coder LATIN1 when COMPACT_STRINGS is false.

Re: RFR(xs): 8221375: Windows 32bit build (VS2017) broken

Hi all, Snipping much, but commenting on one statement inline below. On Mon, 25 Mar 2019 at 01:58, David Holmes wrote: > Hi Thomas, > > A few queries, comments and concerns ... > > On 25/03/2019 6:58 am, Thomas Stüfe wrote: > > Hi all, > > > > After a long time I tried to build a Windows 32bit

New JBS component/sub-component for jpackage

For all those interested in the proposed jpackage tool: As described in INFRA-15257 , the component/subcomponent for jpackage bug in JBS has been changed from deploy/packager to tools/jpackage. Existing bugs and enhancements in

Re: RFR(xs): 8221375: Windows 32bit build (VS2017) broken

> On Mar 24, 2019, at 4:58 PM, Thomas Stüfe wrote: > > Hi all, > > After a long time I tried to build a Windows 32bit VM (VS2017) and failed; > multiple errors and warnings. Lets reverse the bitrot: > > cr: >

Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi, Please can I request a sponsor for this fix to a JDK-13 regression? Patch with jtreg testcase here: http://cr.openjdk.java.net/~aleonard/8221430/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8221430 Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM

Re: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Looks good. Naoto On 3/25/19 6:53 AM, Deepak Kejriwal wrote: Hi Ramanand / Christoph, Thanks for review. I think Naoto and Ramanand are right, we do update the copyright year when it is not a clean backport. Please find the updated version of webrev.

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 3/25/2019 4:48 AM, Adam Farley8 wrote: Hiya Joe, Responses below. Joe Darcy wrote on 22/03/2019 17:06:38: > From: Joe Darcy > To: Mandy Chung , Adam Farley8 > > Cc: core-libs-dev > Date: 22/03/2019 17:07 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Addendum: URL for new webrev: http://cr.openjdk.java.net/~afarley/8216558.1/webrev/ Adam Farley8/UK/IBM wrote on 25/03/2019 18:04:05: > From: Adam Farley8/UK/IBM > To: Joe Darcy > Cc: core-libs-dev , Mandy Chung > > Date: 25/03/2019 18:04 > Subject: Re: RFR: JDK-8216558:

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi Joe, I've read your reply, and I apologise for any offence my inquiry has caused. My intent was only to ask for information. I would now like to refocus on the bug at hand. Do you, or Mandy, have a position in regards to the response I sent a few days ago?

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 3/25/2019 4:50 AM, Adam Farley8 wrote: Hiya Joe, Response below, Joe Darcy wrote on 22/03/2019 17:05:33: > From: Joe Darcy > To: Adam Farley8 > Cc: core-libs-dev , Mandy Chung > > Date: 22/03/2019 17:06 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw

Re: RFR: 8217338: [Containers] Improve systemd slice memory limit support

On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > Could you maybe combine subsystem_file_contents with > subsystem_file_line_contents > by adding an additional argument? Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ Thanks, Severin

Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes

Looks good, thank you! With kind regards, Ivan On 3/24/19 1:26 PM, Langer, Christoph wrote: Hi Ivan, thanks for looking closely. UnixFileSystem_md.c: Should the second error message be "Could not close file"? Yes, maybe that's better. Though it's really just the fallback, one could at

RE: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hello here is an updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.1/webrev/ > > In JLI_Open(const char* name, int flags), you should remove ret and only > > use fd, I think. I removed ret and adjusted some comments. Additionally I added a test that uses (on

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On 25/03/2019 14:47, Aleksey Shipilev wrote: On 3/25/19 2:40 PM, Thomas Stüfe wrote: Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I just built) is 1400m. That probably means something else is mapped into process memory that prevents

Re: 8219196: DataOutputStream.writeUTF may throw unexpected exceptions

+1 On 03/22/2019 07:41 PM, Brian Burkhalter wrote: Forgot the link: http://cr.openjdk.java.net/~bpb/8219196/webrev.03/ On Mar 22, 2019, at 4:32 PM, Brian Burkhalter wrote: Patch updated for the sake of formality.

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On Mon, Mar 25, 2019 at 3:47 PM Aleksey Shipilev wrote: > On 3/25/19 2:40 PM, Thomas Stüfe wrote: > > Note that this may not be enough for windows 32bit. Highest I can go > there (win32 slowdebug build I > > just built) is 1400m. > > That probably means something else is mapped into process

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

On 3/25/19 2:40 PM, Thomas Stüfe wrote: > Note that this may not be enough for windows 32bit. Highest I can go there > (win32 slowdebug build I > just built) is 1400m. That probably means something else is mapped into process memory that prevents continuous heap alloc. Does -Xmx2g work with

Re: RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

Looks fine and trivial. Note that this may not be enough for windows 32bit. Highest I can go there (win32 slowdebug build I just built) is 1400m. Cheers, Thomas On Mon, Mar 25, 2019 at 3:33 PM Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221400 > > My major

RFR (XS) 8221401: [TESTBUG] java/math/BigInteger/LargeValueExceptions.java should be disabled on 32-bit platforms

Bug: https://bugs.openjdk.java.net/browse/JDK-8221401 My major concern is to make tier1 passing on x86_32. This is one of the tests that fail. Smaller heap size does not fit this test case, unfortunately. So, we have to disable it for 32-bit builds. In fact, somebody did it already for 8u

RFR (XS) 8221400: [TESTBUG] java/lang/String/StringRepeat.java requests too much heap

Bug: https://bugs.openjdk.java.net/browse/JDK-8221400 My major concern is to make tier1 passing on x86_32. This is one of the tests that fail. It seems the test can just use smaller heap size. Fix: diff -r d25b24c70126 test/jdk/java/lang/String/StringRepeat.java ---

Re: Formatting rules for exception messages

Hi Florian, Appropriate message composition also varies depending on the level of the library or application.  Since you are asking here I'm assuming this is about OpenJDK exception messages. Exception messages are very context dependent both on the exception being thrown and class/method from

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi Ramanand / Christoph, Thanks for review. I think Naoto and Ramanand are right, we do update the copyright year when it is not a clean backport. Please find the updated version of webrev. http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ Regards, Deepak -Original

Re: RFR: 8217338: [Containers] Improve systemd slice memory limit support

On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > Is there ever a situation where the memory.limit_in_bytes could be unlimited > but the > hierarchical_memory_limit is not? Yes. This is the very bug. Under a systemd slice with newer kernels the memory.limit_in_bytes file OpenJDK looks at

Formatting rules for exception messages

Are there any guidelines for formatting exception messages? In particular, I'm interested in the case when the exception message is a (clipped) sentence. Is it supposed to start with a capital letter? If the message refers to a parameter name, the spelling should reflect the name exactly, of

Re: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table

Here's an updated webrev that includes the change to bind to the stub. The jstatd tests continue to pass after this change. Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.01/ It would be good to have a second reviewer from the serviceability team. Longer term it would be good to

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hiya Joe, Response below, Joe Darcy wrote on 22/03/2019 17:05:33: > From: Joe Darcy > To: Adam Farley8 > Cc: core-libs-dev , Mandy Chung > > Date: 22/03/2019 17:06 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > >

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hiya Joe, Responses below. Joe Darcy wrote on 22/03/2019 17:06:38: > From: Joe Darcy > To: Mandy Chung , Adam Farley8 > > Cc: core-libs-dev > Date: 22/03/2019 17:07 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > >

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi Mandy, Mandy Chung wrote on 22/03/2019 16:56:12: > From: Mandy Chung > To: Joe Darcy , Adam Farley8 > Cc: core-libs-dev > Date: 22/03/2019 16:58 > Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails > to throw IllegalAccessException for final fields > > Hi Adam, > On

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi Christoph, I have suggested the changes considering the fact that this is not a clean backport. Both the source and test files are manually edited and review is requested for the same. Thank you for reminding about jdk8u-fix-request label, I think Deepak will add it. Regards, Ramanand. >

RE: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Christoph / Alan, thanks for the reviews. Btw what do you think about the longPathAware setting in the manifest ? https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi there, since this is a downport for jdk/jdk, I think the copyright headers should be the same as upstream. So, for src/share/classes/java/time/format/DateTimeFormatterBuilder.java, you should take 2018 as copyright year. For the test the headers look correct. As for jdk8u push: Will you

RE: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633

Hi Deepak, In particular, the test TestDateTimeFormatterBuilderWithLocale.java should have only one copyright year i.e. 2019, since this is a new file in jdk8u-dev repos. Also I think, you can omit the second copyright info(from line no. 24) for the same reason. Note: I am not a reviewer for