Hi All,
I was advised (on the OpenJDK IRC channel) that supplying a fix is better
than
proposing the idea of one, so I've gone ahead and written a "silent exit"
fix for the
example case:
java -agentlib:jdwp=help
This fix solves that bug, and also creates the tools for other code, VM
and
Regards
Adam Farley
P.S. Thank you both for your efforts on this. :)
From: David Holmes <david.hol...@oracle.com>
To: Alan Bateman <alan.bate...@oracle.com>, Adam Farley8
<adam.far...@uk.ibm.com>, core-libs-dev@openjdk.java.net,
hotspot-runtime-...@openjdk.ja
a silent exit.
Best Regards
Adam Farley
P.S. Thank you both for your efforts on this. :)
From: David Holmes <david.hol...@oracle.com>
To: Alan Bateman <alan.bate...@oracle.com>, Adam Farley8
<adam.far...@uk.ibm.com>, core-libs-dev@openjdk.java.net,
hotspot-runtime-..
after we've
integrated the code that can handle a silent exit.
Best Regards
Adam Farley
P.S. Thank you both for your efforts on this. :)
From: David Holmes <david.hol...@oracle.com>
To: Alan Bateman <alan.bate...@oracle.com>, Adam Farley8
<adam.far...@uk.ibm.com&
Hi All,
I've included the full text of my reply in-line below.
A summary is: I continue to support the idea of a new return code on the
basis
that, when the VM is nonusable but no error has occurred, we have no
suitable
option.
Right now we can:
- Report an error that has not occurred.
- Die
Hi All,
Problem: Several of Java's "c" files call exit(0) if you pass certain
command-line options to JNI_CreateJavaVM, which can terminate the C++ code
JNI users use to initialise the JVM.
Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses
the option
Hi Alan, David, and Tom,
First, thanks again for your efforts on this. As a new guy to OpenJDK
contributions, it means a lot to see so much progress on this so quickly.
:)
>On 24/08/2017 07:33, David Holmes wrote:
>> Hi Adam,
>>
>> cc'ing hotspot runtime dev as runtime own JNI and the
return codes to JNI callers, not java executable
users.
From: Thomas Stüfe <thomas.stu...@gmail.com>
To: Adam Farley8 <adam.far...@uk.ibm.com>
Cc: Java Core Libs <core-libs-dev@openjdk.java.net>
Date: 23/08/2017 18:45
Subject:Re: [BUG PROPOSAL]: C++ code t
ed, should only cover the exit(0) cases. I believe we
have consensus here.
From: David Holmes <david.hol...@oracle.com>
To: Adam Farley8 <adam.far...@uk.ibm.com>, Alan Bateman
<alan.bate...@oracle.com>, core-libs-dev@openjdk.java.net,
hotspot-runtime-...@openjdk.java.net,
Hi All,
Currently, GenModuleInfoSource.java does not allow you to merge extra
module-info files into the primary module-info file (for a given module)
at build time.
Put simply; I think it should have this functionality. Can committers
please review and opine?
You can already see this code
Hi All,
We have a bug in OpenJDK where if you pass an info-only option (like
-agentlib:jdwp=help) in through the JNI interface, it can exit your code
with RC 0.
I think this is a bug because if you planned to do anything after starting
a Java VM, you have to do it in an exit hook.
If an
likely to
want to invest the time and effort in trying to clean
this up this way.
From: David Holmes <david.hol...@oracle.com>
To: Adam Farley8 <adam.far...@uk.ibm.com>
Cc: Alan Bateman <alan.bate...@oracle.com>,
core-libs-dev@openjdk.java.net, hotspot-runti
Bump.
Best Regards
Adam Farley
> On 13/04/2018 15:14, Adam Farley8 wrote:
> >> Hi Alan, Peter,
> >>
> >> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
> >>
> >> When t
Hi David,
Good catch. Copying to the Hotspot list.
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
From: David Holmes <david.hol...@oracle.com>
To: Adam Farley8 <adam.far...@uk.ibm.com>, core-libs-dev
<core-libs-dev@openjdk.java.net>
Date: 16/05/2018 22:32
Hi All,
In bug JDK-8190187, hotspot_hg_diff and jdk_hg_diff are out-of-date.
Please can someone delete these files?
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Hi All,
The code to resolve JDK-8190187 has been added to the bug, in hg_diff.txt.
Could a committer please take the fix and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and 2 for the jdwp agent
Hi All,
There's a typo here on line 258, where is says "Magin number" but means
"Magic number".
http://hg.openjdk.java.net/jdk/jdk/file/ec881a19d294/src/java.base/share/classes/sun/text/normalizer/ICUBinary.java
Can a committer review and correct the typo?
Thanks.
Best Regards
Adam Farley
der authentication
failed";
> >> Â }
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> On May 21, 2018, at 9:50 AM, Brian Burkhalter
> >> <brian.burkhal...@oracle.com> wrote:
> >>
> >>> Hi Adam,
> >>>
&g
Hi All,
Native memory allocation for DBBs is tracked in java.nio.Bits, but that
only includes what the user thinks they are allocating.
When the VM adds extra memory to the allocation amount this extra bit is
not represented in the Bits total. A cursory glance
shows, minimum, that we round
d hotspot *and* core libs.
- Adam
>
> On 14/02/2018 9:32 PM, Adam Farley8 wrote:
>> Hi All,
>>
>> Currently, diagnostic core files generated from OpenJDK seem to lump
all
>> of the
>> native memory usages together, making it near-impossible for someone to
>
t Byte Buffers. This makes native memory OOM
debugging easier.
Think of it as an NMT upgrade.
Here's an example of what the output should look like:
https://developer.ibm.com/answers/questions/288697/why-does-nativememinfo-in-javacore-show-incorrect.html?sort=oldest
- Adam
>
>> David
Hi All,
-- Short version --
Could a committer please take the fix for JDK-8190187 (full code included
in the bug) and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain (a) the new return code, and (b) the
non-Hotspot code that handles the new code.
On 15/02/2018 12:13 AM, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for the new JNI Return code.
&
On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for the new JNI Return code.
>>
anything the parsing code
mistakes for that class+method) can only ever allocate native
memory for DBBs.
What do you think?
Best Regards
Adam Farley
>
>> On Feb 14, 2018, at 3:32 AM, Adam Farley8 <adam.far...@uk.ibm.com>
wrote:
>>
>> Hi All,
>>
>
snwer this? I'll put the message in IRC as
well, and
update here if I get any answers.
Best Regards
Adam Farley
From: Paul Sandoz <paul.san...@oracle.com>
To: Adam Farley8 <adam.far...@uk.ibm.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>, hotspot-dev
d
-- Bump --
Hi Folks,
> Zhengyu Gu wrote on 06/06/2018 01:58:18:
> From: Zhengyu Gu
> To: "Thomas Stüfe" , Adam Farley8
>
> Cc: "hotspot-...@openjdk.java.net developers" d...@openjdk.java.net>, core-libs-dev
> Date: 06/06/2018 01:58
> Subject:
Hi All,
This bug could be fixed by comparing the Class Loader with a blank
static volatile Object (defined outside the method scope) at the
end of the getBundleImpl class.
E.g.
-
+1322
/**
* volatile reference object to guard the ClassLoader
; >
> > Hi Adam,
> >
> > Have you tried Peter's suggestion if an empty static method taking
an
> > Object parameter? Does it work for you?
> >
> > Your proposed approach seems fine and I would suggest to put the
> > check in a stati
; >
> > Hi Adam,
> >
> > Have you tried Peter's suggestion if an empty static method taking
an
> > Object parameter? Does it work for you?
> >
> > Your proposed approach seems fine and I would suggest to put the
> > check in a stati
chung wrote on 15/08/2018 17:49:51:
> From: mandy chung
> To: Adam Farley8 , Hans Boehm
> Cc: core-libs-dev ,
i18n-...@openjdk.java.net
> Date: 15/08/2018 17:50
> Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix
included)
>
> Hi Adam,
>
> Thi
Hi Mandy,
The extra space is fine.
In hindsight, you could probably rename "loaderone" to just "loader" too.
Thanks for helping with this. :)
Best Regards
Adam Farley
OpenJDK Team
Runtimes
IBM
mandy chung wrote on 16/08/2018 18:57:01:
> From: mandy chung
&
> Alan Bateman wrote on 16/07/2018 15:00:16:
> From: Alan Bateman
> To: Peter Levart , Adam Farley8
> , core-libs-dev
> Date: 16/07/2018 14:59
> Subject: Re: RFR (Unraised): JDK8 ResourceBundle vulnerable to GC
>
> On 16/07/2018 14:12, Peter Levart wrote:
> >
Hi Folks,
> Zhengyu Gu wrote on 06/06/2018 01:58:18:
> From: Zhengyu Gu
> To: "Thomas Stüfe" , Adam Farley8
>
> Cc: "hotspot-...@openjdk.java.net developers" d...@openjdk.java.net>, core-libs-dev
> Date: 06/06/2018 01:58
> Subject: Re: RFR Bug-pe
Hi All,
-- Summary:
When calling "ResourceBundle.getBundle(String, Locale, ClassLoader)" on
JDK8, the ClassLoader can get GC'd before we're finished with it.
This can result in us getting the wrong result back, like if we asked for
"Stuff" with the locale "fr, CA" and got back
Hi All,
I've attached the code to resolve JDK-8190187
Could a committer please take the fix (amended code attached, and
available on request) and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and
Hi Alan, Peter,
I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
When the VM adds extra memory to the allocation amount this extra bit is
not represented in the Bits total.
A cursory glance shows, minimum, that we round the
Hi All,
Here is the code to resolve JDK-8190187:
http://cr.openjdk.java.net/~mhorie/8190187/hg_diff.txt
Could a committer please take the fix and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and
Hi All,
I've attached the code to resolve JDK-8190187
Could a committer please take the fix (amended code attached, and
available on request) and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and
> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount t
> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount t
Hi All,
Here is the code to resolve JDK-8190187:
http://cr.openjdk.java.net/~mhorie/8190187/hg_diff.txt
Could a committer please take the fix and:
1) Complete the CSR process for the new JNI Return code.
2) Commit the changes that contain the Return code.
And, optionally, 3) Perform 1 and
Bump :)
Best Regards
Adam Farley
Last email
Hi Alan
Thanks for getting back to me on this. :)
I've changed the hg_diff as described below, see the attached.
> On 27/02/2018 15:04, Adam Farley8 wrote:
>
> Resending. Bump. :)
>
> On 14/02/2018 14:13, Adam Farley8
of the Bits variables at crash-time.
Best Regards
Adam Farley
From: Alan Bateman <alan.bate...@oracle.com>
To: Peter Levart <peter.lev...@gmail.com>, Adam Farley8
<adam.far...@uk.ibm.com>
Cc: "hotspot-...@openjdk.java.net developers"
<hotspot-...@o
Resending. Bump. :)
On 14/02/2018 14:13, Adam Farley8 wrote:
>> Hi All,
>>
>> -- Short version --
>>
>> Could a committer please take the fix for JDK-8190187 (full code
included
>> in the bug) and:
>>
>> 1) Complete the CSR process for t
Hi Alan
Thanks for getting back to me on this. :)
I've changed the hg_diff as described below, see the attached.
> On 27/02/2018 15:04, Adam Farley8 wrote:
>
> Resending. Bump. :)
>
> On 14/02/2018 14:13, Adam Farley8 wrote:
>>> Hi All,
>>>
>&g
Hi All,
Some comments below.
> A CSR request will need to be filed.
>
> >>>
> >>> Of course, as this is a spec change.
> >>
> >> I'm unclear what spec is actually to be changed here and in what way?
As am I.
> >
> > I expect Adam will send a revised webrev to include the proposed
ps he means it will still fail, but for the reasons we've discussed
rather than anything connected to access control?
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 16/01/2019 23:52:03:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 16/01/
Alan Bateman wrote on 11/12/2018 15:32:31:
> From: Alan Bateman
> To: Adam Farley8 , core-libs-dev d...@openjdk.java.net>
> Date: 11/12/2018 15:33
> Subject: Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words
>
> On 11/12/2018 15:03, Adam Farley8 wrote:
>
provide them as a zip file.
>
> Thank you and best regards,
> Volker
> On Tue, Dec 11, 2018 at 4:04 PM Adam Farley8
wrote:
> >
> > Hey All,
> >
> > I've spotted 12 instances of swear words in OpenJDK source comments,
and
> >
Hey All,
I've spotted 12 instances of swear words in OpenJDK source comments, and
it seems appropriate to remove them.
Bug: https://bugs.openjdk.java.net/browse/JDK-8215217
I've created a webrev and attached to the bug.
Also, I've mentioned in the bug that there are additional swears in more
Hi Stuart,
A good compromise. Well referenced.
Yes, could you sponsor this change?
Thanks,
- Adam
Stuart Marks wrote on 12/12/2018 00:38:32:
...
>
>
> # HG changeset patch
> # User afarley
> # Date 1544574289 28800
> # Tue Dec 11 16:24:49 2018 -0800
> # Node ID
Update: The revised webrev can be found here:
http://cr.openjdk.java.net/~afarley/8215217/webrev/
It can also be found in the zip attached to the bug.
Best Regards
Adam Farley
IBM Runtimes
Adam Farley8/UK/IBM wrote on 13/12/2018 11:49:12:
> From: Adam Farley8/UK/IBM
> To: Stuart
ibs
> Date: 20/11/2018 17:59
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> using the xlc 13.1 compiler
>
> On Tue, Nov 20, 2018 at 6:15 PM Thomas Stüfe
wrote:
> >
> > On Tue, Nov 20, 2018 at 6:12 PM Adam Farley8
wrote:
> > >
> &
to link the change to the error. Also, it's shorter.
My 2 cents. Volker, Ichiroh?
Best Regards
Adam Farley
IBM Runtimes
"Ichiroh Takiguchi" wrote on 27/11/2018
12:36:41:
> From: "Ichiroh Takiguchi"
> To: "Volker Simonis"
> Cc: Adam Farley8/UK/IBM@IBMGB,
OpenJDK will not build on AIX while
> using the xlc 13.1 compiler
>
> On Wed, Nov 21, 2018 at 1:46 PM Adam Farley8
wrote:
> >
> > Hi Volker,
> >
> > The NativeImageBuffer.cpp changes are best explained by the full text
of
> > the referenced GitHub Pull Requ
> On Wed, Nov 21, 2018 at 1:46 PM Adam Farley8
wrote:
> >
> > Hi Volker,
> >
> > The NativeImageBuffer.cpp changes are best explained by the full text
of
> > the referenced GitHub Pull Request, copied here for simplicity:
> >
> > --
ault")))
#else
#define JNIEXPORT
--
Best Regards
Adam Farley
IBM Runtimes
"Thomas Stüfe" wrote on 19/11/2018 18:11:34:
> From: "Thomas Stüfe"
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 19/11/2018 18:12
>
20/11/2018 16:44:07:
> From: "Thomas Stüfe"
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 20/11/2018 16:48
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> using the xlc 13.1 compiler
>
> Hi Adam,
>
> On Tue, Nov 20, 2018 at
m Farley
IBM Runtimes
Volker Simonis wrote on 22/11/2018 14:25:04:
> From: Volker Simonis
> To: adam.far...@uk.ibm.com
> Cc: Java Core Libs , "Stuefe,
> Thomas"
> Date: 22/11/2018 14:25
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> using
us to build on versions of xlC other than 12.1.
I propose we call that "Plan B".
Best Regards
Adam Farley
IBM Runtimes
Adam Farley8/UK/IBM wrote on 26/11/2018 13:16:18:
> From: Adam Farley8/UK/IBM
> To: Volker Simonis
> Cc: Java Core Libs , "Stuefe,
> Thomas
mpiling "NativeImageBuffer.cpp"?
>
> - If yes, did you fix them by excluding the inclusion of
> "osSupport.hpp" ? That would be strange, because it doesn't seem to
> related to the problems reported until now at all.
>
> - If no, I'm totally confused...
&g
Hi All
Both the problem and the solution appear straight-forward enough.
Details included in the bug description.
Thoughts and opinions welcome.
Best Regards
Adam Farley
IBM Runtimes
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Hi All,
I posit that you shouldn't be able to change the contents of a a final
field.
However, if you use Field.setAccessible(true) before calling
Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows
you to set the (reflected) value of a static final field.
This seems
l
field, I think we can agree that unreflectSetter should fail to create a
setter MethodHandle for this same field.
Best Regards
Adam Farley
IBM Runtimes
Remi Forax wrote on 11/01/2019 13:11:48:
> From: Remi Forax
> To: David Holmes
> Cc: Adam Farley8 , core-libs-dev d...@openjdk
: Adam Farley8 , Joe Darcy
> Cc: core-libs-dev
> Date: 26/03/2019 03:51
> Subject: 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 webr
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
>
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 IllegalAccessExcep
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 IllegalAccessExcep
/pipermail/core-libs-dev/2019-March/059191.html
Also, I have read the guide (finally), and I see the tests should have a
bug tag. I'll add that now, in a versioned webrev.
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 25/03/2019 17:34:42:
> From: Joe Darcy
> To: Adam F
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
es
Mandy Chung wrote on 21/02/2019 17:37:54:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 21/02/2019 17:41
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> Hi Adam,
>
) nobody is meant to be changing
final fields anyway.
Open for review.
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 01/03/2019 17:50:49:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 01/03/2019 17:50
> Subject: Re: RFR: JDK-8216558: Lookup.
Mandy Chung , Adam Farley8
>
> Cc: core-libs-dev
> Date: 12/03/2019 03:34
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
>
> On 3/11/2019 3:49 PM, Mandy Chung wrote:
> >
> >
> >
: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 07/03/2019 15:40
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> Hi Adam,
>
> On 3/6/19 8:28 AM, Adam Farley8 wrote:
> >
: Adam Farley8
> Cc: core-libs-dev
> Date: 07/03/2019 23:19
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
>
>
> On 3/7/19 9:44 AM, Adam Farley8 wrote:
> > Hi Mandy,
> >
> >
un against a non-patched java, so I think we're ok.
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 20/03/2019 05:08:37:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 20/03/2019 05:10
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter
Hi Mandy,
Answers below. :)
Mandy Chung wrote on 22/03/2019 00:35:00:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 22/03/2019 00:35
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for fina
rcy
> To: Adam Farley8 , Mandy Chung
>
> Cc: core-libs-dev
> Date: 22/03/2019 15:42
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> A quick comment below...
>
> On 3/22/2019 4:33 AM,
+ }
+
@Test
public void testFindSetter() throws Throwable {
CodeCacheOverflowProcessor.runMHTest(this::testFindSetter0);
}
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 31/01/2019 18:58:25:
> From:
on 23/01/2019 19:18:09:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 23/01/2019 19:17
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails
> to throw IllegalAccessException for final fields
>
> Hi Adam,
>
> On 1/23/19 8:3
is not a suitable test?
Please advise.
Best Regards
Adam Farley
IBM Runtimes
Mandy Chung wrote on 30/01/2019 18:22:40:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 30/01/2019 18:22
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fa
Hi All,
Reviews and feedback requested for the fix.
http://cr.openjdk.java.net/~afarley/8222930.1/jdk13/webrev
Martin: Thanks for the testcase. I've replaced the old test in the webrev
with your generalized one. :)
Best Regards
Adam Farley
IBM Runtimes
Adam Farley8/UK/IBM wrote on 25/04
mes
> To: Martin Buchholz , core-libs-dev d...@openjdk.java.net>, Doug Lea , Chris Hegarty
> , Adam Farley8 ,
> Jonathan Gibbons
> Date: 30/04/2019 08:52
> Subject: Re: RFR: jsr166 integration 2019-05
>
> Hi Martin,
>
> On 30/04/2019 4:00 am, Martin Buchholz wrote:
> &g
Thanks Martin. :)
Best Regards
Adam Farley
IBM Runtimes
Martin Buchholz wrote on 02/05/2019 15:14:32:
> From: Martin Buchholz
> To: Adam Farley8
> Cc: David Holmes , Chris Hegarty
> , core-libs-dev d...@openjdk.java.net>, Doug Lea , Jonathan Gibbons
>
> Date: 02/05
Good job. :)
On to the next bug! Hehe.
Best Regards
Adam Farley
IBM Runtimes
Martin Buchholz wrote on 07/05/2019 19:46:26:
> From: Martin Buchholz
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 07/05/2019 19:46
> Subject: Re: RFR: JDK-8222930: ConcurrentSkipLi
Hi All,
ConcurrentSkipListMapTest.clone() produces a clone that shares the array
size variable of the original, and then doubles it.
So both arrays, original and clone, tell the user that each is twice as
big as it actually is.
The proposed fix is to simply set the clone's array size variable
Hi Stuart,
Whoops, typo. Thanks for catching that.
Ditto for Martin, who has modified the bug. :)
Best Regards
Adam Farley
IBM Runtimes
Stuart Marks wrote on 24/04/2019 17:59:17:
> From: Stuart Marks
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 24/04/2019 17:59
> S
ntimes
Florian Weimer wrote on 03/10/2019 21:42:52:
> From: Florian Weimer
> To: Adam Farley8
> Cc: "Java Core Libs" , jdk-updates-
> d...@openjdk.java.net
> Date: 03/10/2019 21:43
> Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception
>
>
Hi Joe,
That sounds reasonable.
Would you, or another Oracle employee, mind sponsoring the change?
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 03/10/2019 23:30:14:
> From: Joe Darcy
> To: Florian Weimer , Adam Farley8
> Cc: jdk-updates-...@openjdk.java.net, Java
Hi Mandy,
Sorry for the delay in responding.
Mandy Chung wrote on 29/10/2019 19:30:55:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 29/10/2019 19:31
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
> for Specific Classes
>
Thanks Paul. :)
Best Regards
Adam Farley
IBM Runtimes
"Hohensee, Paul" wrote on 10/12/2019 20:16:31:
> From: "Hohensee, Paul"
> To: Severin Gehwolf , Adam Farley8
> , Java Core Libs
> Cc: jdk8u-dev
> Date: 10/12/2019 20:16
> Subject: [EXTERNAL]
Hi All,
I'm asking for reviewers, sponsors, and opinions on the changes proposed
below.
Right now, there are four files in OpenJDK 8 that have a GPL V2 License,
with no Classpath Exception.
Based on the conversation so far, here's a summary of the proposed
actions:
1) Remove this file,
Hey All,
This one goes out to anyone who's struggled to figure out
why OpenJDK isn't loading their class.
The requirement is for OpenJDK to give more detailed
information while loading user-specified classes (e.g. the
one OpenJDK is failing to load). Some debug information is
available while
/webrev/
Best Regards
Adam Farley
IBM Runtimes
From: David Holmes
To: Martin Buchholz
Cc: Ioi Lam , core-libs-dev
, Adam Farley8
Date: 24/10/2019 05:22
Subject:[EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
for Specific Classes
Hi Martin
Hi Alan,
Thanks for the quick response.
Stewart, if you have a moment, could you please advise on the section with
the @Stewart tag?
Alan Bateman wrote on 22/10/2019 12:36:26:
> From: Alan Bateman
...
> This looks very messy and I don't think is in any state to be reviewed.
I'm sorry to
wrong version
of a class" problem, but does not seem to give us
information in the case of class loading failure.
Also, thanks for moving the bug to the correct component. :)
Best Regards
Adam Farley
IBM Runtimes
David Holmes wrote on 22/10/2019 14:12:55:
> From: David Holmes
in a build, so some may only need to be
considered as source.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
Best Regards
Adam Farley
IBM Runtimes
Joe Darcy wrote on 04/10/2019 17:28:59:
> From: Joe Darcy
> To: Adam F
/fix_empty_sec_hdr_flags.c
Best Regards
Adam Farley
IBM Runtimes
Alan Bateman wrote on 07/10/2019 13:57:53:
> From: Alan Bateman
> To: Adam Farley8 , Joe Darcy
> , sergey.bylok...@oracle.com,
> lana.ste...@oracle.com, magnus.ihse.bur...@oracle.com
> Cc: Java Core Libs , Florian Weimer
Hey all,
Four GPLv2 files in 8u seem to be missing the classpath exception from the
copyright section.
Requesting reviews and a sponsor.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
Best Regards
Adam Farley
IBM Runtimes
1 - 100 of 109 matches
Mail list logo
