Re: RFR: 8284209: Replace remaining usages of 'a the' in source code

[Iris Clark]

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> It's the last issue in the series, and it still touches different areas of 
> the code.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8771

Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base

[Iris Clark]

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8768

Re: Integrated: 8284687: validate-source failure after JDK-8283710

[Iris Clark]

On Mon, 11 Apr 2022 16:20:02 GMT, Daniel D. Daugherty  
wrote:

> A trivial copyright fix to solve validate-source failure after JDK-8283710.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8181

Re: RFR: 8283698: Refactor Locale constructors used in src/test

[Iris Clark]

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato  wrote:

> This is a follow-on task after deprecating the Locale constructors 
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are 
> simple replacements to Locale constructors with `Locale.of()` or Locale 
> constants, such as `Locale.US`.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8130

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

[Iris Clark]

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan  wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice tidy of the code.

Is there anything that can be done to prevent re-introduction of this trivial 
problem?  Perhaps a new Skara bot jcheck option similar to what is already in 
place for trailing whitespace?

-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

Re: RFR: 8281057: Fix doc references to overriding in JLS

[Iris Clark]

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo  wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a 
> number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I 
> believe that the real target should be "8.4.8. Inheritance, Overriding, and 
> Hiding" and its subsections.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7311

Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build

[Iris Clark]

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy  wrote:

> Use presumed syntax that will be introduced by JDK-8280488.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7189

Re: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC

[Iris Clark]

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons  wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  
> The changes update the version number, copyright year, and incorporate the 
> changes from the latest upstream files.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk18/pull/5

Re: RFR: 8272395: Bad HTML in JVMTI man page

[Iris Clark]

On Tue, 7 Dec 2021 00:27:45 GMT, Serguei Spitsyn  wrote:

> This fix adds escaping of invalid characters '[]' for 3 URLs defined in the 
> jvmti.xml.
> This file is a base to generate the jvmti.html.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6730

Re: RFR: JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks

[Iris Clark]

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy  wrote:

> Exploratory builds indicate it is not currently necessary to exclude the 
> doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6713

Re: RFR: 8273187: jtools tests fail with missing markerName check

[Iris Clark]

On Thu, 16 Sep 2021 01:08:45 GMT, Naoto Sato  wrote:

> Fixing failing regression tests caused by the JEP 400: UTF-8 by Default.
> 
> `JcmdOutputEncodingTest` test case uses `file.encoding=UTF-8` in `C` locale. 
> The output from the agent library is in `UTF-8` so it succeeded before the 
> JEP has been implemented, as System.out used `UTF-8` converter. After the 
> JEP, it started failing because System.out is using `US-ASCII` which 
> generates series of '?', ending up with assertion failure in the test.
> 
> The proposed fix is to pass `sun.stdout.encoding=UTF-8` as well as 
> `file.encoding` so that tool process' System.out is in `UTF-8` as well.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5539

Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17

[Iris Clark]

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons  wrote:

> Please review a semi-automatic update of the nroff man pages from the 
> upstream files.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/303

Re: RFR: 8271396: Spelling errors

[Iris Clark]

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg 
 wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2385

Re: RFR: 8271396: Spelling errors [v2]

[Iris Clark]

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg 
 wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains one additional 
> commit since the last revision:
> 
>   8271396: Fix spelling errors
>   
>choosen  -> chosen
>commad   -> command
>hiearchy -> hierarchy
>leagacy  -> legacy
>minium   -> minimum
>subsytem -> subsystem
>unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2385

Re: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]

[Iris Clark]

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn  wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 
>> 1.2 (Java 6) and should be deprecated so they can be removed in a future 
>> release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by 
>> more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during 
>> JSR-163. They pre-date concurrent collectors, the built-in heap dump 
>> support, and JFR. They are a maintenance burden and there is little evidence 
>> that they are used by modern tools (they involve stop-the-world operations 
>> and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>> IterateOverObjectsReachableFromObject
>> IterateOverReachableObjects
>> IterateOverHeap
>> IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to 
>> say that the functions have been superseded. The proposal is to change this 
>> to say that the functions are deprecated and will be degraded in a future 
>> release.
>> A release note is planned. The release note will detail how to use 
>> -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of 
>> these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an 
>> error to indicate that they are no longer implemented/supported. We also 
>> plan to re-examine the newer Heap functions with a view to deprecate them in 
>> the future too (this requires a bit more work to understand if there is any 
>> real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   missed a space in Java SE6

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4406

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

[Iris Clark]

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons  wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Nice clean-up.

-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/814

RE: RFR: JDK-8223319: Add copyright footer to specs and man pages

[Iris Clark]

Hi, Erik.

> New webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.02/

The revised webrev looks good.

Thank you!

Iris

RE: RFR: JDK-8223319: Add copyright footer to specs and man pages

[Iris Clark]

Hi, Erik.

I'm happy to see this change go in.  It looks good.

Just one comment.  When removing the footer in jvmit.html, I suspect that you 
also need to make changes to jvmti.xsl, which was also modified when the 
copyright footer was inserted in this changeset:

http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed

Thanks,
iris

-Original Message-
From: Erik Joelsson 
Sent: Friday, May 3, 2019 9:38 AM
To: build-dev ; OpenJDK Serviceability 

Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages

The (optional) specs and man pages should have the same copyright footer as the 
generated API docs. This patch adds the logic to add such footers. It also 
removes the existing footer in jvmti.html.

Bug: https://bugs.openjdk.java.net/browse/JDK-8223319

Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html

/Erik

RE: RFR (S) 8210775: JVM TI Spec missing copyright

[Iris Clark]

Hi, Mandy, David, and Serguei.

Thank you for taking the time to Review.  I've pushed the changeset.

iris

-Original Message-
From: Serguei Spitsyn 
Sent: Monday, September 17, 2018 12:57 AM
To: David Holmes ; Iris Clark ; 
serviceability-dev 
Subject: Re: RFR (S) 8210775: JVM TI Spec missing copyright

+1

Thanks,
Serguei


On 9/16/18 9:27 PM, David Holmes wrote:
> This looks fine to me Iris.
>
> Thanks,
> David
>
> On 15/09/2018 8:01 AM, Iris Clark wrote:
>> Hi.
>>
>> Please review the following changes to add a copyright line to the 
>> end of the generated jvmti.html file:
>>
>>  8210775:  JVM TI Spec missing copyright
>>  bug:  https://bugs.openjdk.java.net/browse/JDK-8210775
>>  webrev:  http://cr.openjdk.java.net/~iris/8210775/webrev/
>>
>> The year ranges are taken from the copyright line contained within 
>> the first comment block of the source itself.
>>
>> These are the generated files before and after this changeset:
>>
>>  http://cr.openjdk.java.net/~iris/8210775/jvmti-old.html
>>  http://cr.openjdk.java.net/~iris/8210775/jvmti-new.html
>>
>> Note that I did not add an entry to the Change History since it 
>> appears that the recent convention is to document only substantive 
>> changes to the Specification.
>>
>> Thanks,
>> Iris
>>

RFR (S) 8210775: JVM TI Spec missing copyright

[Iris Clark]

Hi.

Please review the following changes to add a copyright line to the end
of the generated jvmti.html file:

8210775:  JVM TI Spec missing copyright
bug:  https://bugs.openjdk.java.net/browse/JDK-8210775
webrev:  http://cr.openjdk.java.net/~iris/8210775/webrev/

The year ranges are taken from the copyright line contained within
the first comment block of the source itself.

These are the generated files before and after this changeset:

http://cr.openjdk.java.net/~iris/8210775/jvmti-old.html
http://cr.openjdk.java.net/~iris/8210775/jvmti-new.html

Note that I did not add an entry to the Change History since it appears
that the recent convention is to document only substantive changes to
the Specification.

Thanks,
Iris

RE: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Iris Clark]

Hi, Stuart.

 

http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.2/

 

The simple update to remove references to the removed methods looks good.

 

Thanks,

iris

 

From: Stuart Marks 
Sent: Wednesday, June 6, 2018 2:58 PM
To: Serguei Spitsyn ; David Holmes 
; Alan Bateman ; Iris Clark 

Cc: serviceability-dev ; core-libs-dev 

Subject: Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

 

Serguei, great! Thanks.

All, I've updated the webrev to with changes to threadPrimitiveDeprecation.html 
to remove the sections that mention the removed methods.

http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.2/

s'marks

 

RE: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Iris Clark]

Hi, Stuart.

I think you need to make changes to this file too:

http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html

Thanks,
iris

-Original Message-
From: Alan Bateman 
Sent: Wednesday, June 6, 2018 3:40 AM
To: Stuart Marks ; serviceability-dev 

Cc: core-libs-dev 
Subject: Re: RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

On 06/06/2018 01:05, Stuart Marks wrote:
> [adding serviceability-dev]
>
> Hi serviceability folks,
>
> I'm in the process of removing Thread.destroy() and
> Thread.stop(Throwable) from the Java SE API. Alan and David have 
> pointed out that there are some cross-references to
> Thread.stop(Throwable) in the JDWP and JVMTI specs, as well as in the 
> JDI ThreadReference API. I've adjusted the relevant files.
>
> See please review this updated webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/
Have you considered removing the "What about Thread.stop(Throwable)" 
section completely from the threadPrimitiveDeprecation doc? A new developer 
reading the javadoc in 2019 shouldn't need to read about a removed method.

Otherwise I think this looks good, including the updates to the JDWP and JVM TI 
specs.

-Alan

RE: RFR (S): 8203500: Fix broken links to Specification in "specs" directory

[Iris Clark]

Hi, Mandy.

 

Thanks for the super-fast review!

 

iris

 

From: mandy chung 
Sent: Monday, May 21, 2018 4:15 PM
To: Iris Clark 
Cc: compiler-...@openjdk.java.net; core-libs-...@openjdk.java.net; 
serviceability-dev@openjdk.java.net
Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" 
directory

 

The fix looks fine.

Mandy

On 5/21/18 3:54 PM, Iris Clark wrote:

Hi.

 

Please review this small change to fix a few broken links to

Specification in the "specs" directory from the JavaDoc API.

The incorrect references either not include "{@docRoot}" or

include the non-existent "{@docRootParent}".  They should all

begin with "HYPERLINK "mailto:%7b@docRoot%7d/../specs/"{@docRoot}/../specs/";.

 

Bug:

 

8203500 Fix broken links to Specification in "spec" directory

https://bugs.openjdk.java.net/browse/JDK-8203500

 

webrev:

 

HYPERLINK 
"http://cr.openjdk.java.net/%7Eiris/8203500/webrev/"http://cr.openjdk.java.net/~iris/8203500/webrev/

 

Thanks,

Iris

 

 

RE: RFR (S): 8203500: Fix broken links to Specification in "specs" directory

[Iris Clark]

Hi, Jon.

 

Thanks for the speedy review!

 

iris

 

From: Jonathan Gibbons 
Sent: Monday, May 21, 2018 4:00 PM
To: compiler-...@openjdk.java.net
Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" 
directory

 

Looks good to me.

-- Jon

 

On 5/21/18 3:54 PM, Iris Clark wrote:

Hi.

 

Please review this small change to fix a few broken links to

Specification in the "specs" directory from the JavaDoc API.

The incorrect references either not include "{@docRoot}" or

include the non-existent "{@docRootParent}".  They should all

begin with "HYPERLINK "mailto:%7b@docRoot%7d/../specs/"{@docRoot}/../specs/";.

 

Bug:

 

8203500 Fix broken links to Specification in "spec" directory

https://bugs.openjdk.java.net/browse/JDK-8203500

 

webrev:

 

HYPERLINK 
"http://cr.openjdk.java.net/%7Eiris/8203500/webrev/"http://cr.openjdk.java.net/~iris/8203500/webrev/

 

Thanks,

Iris

 

 

RE: RFR (S): 8203500: Fix broken links to Specification in "specs" directory

[Iris Clark]

Hi, Lance.

 

Thanks for the speedy review!

 

iris

 

From: Lance Andersen 
Sent: Monday, May 21, 2018 3:58 PM
To: Iris Clark 
Cc: compiler-...@openjdk.java.net; core-libs-...@openjdk.java.net; 
serviceability-dev@openjdk.java.net
Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" 
directory

 

The change looks fine. Iris

 

On May 21, 2018, at 6:54 PM, Iris Clark mailto:iris.cl...@oracle.com"iris.cl...@oracle.com> wrote:

 

Hi.



Please review this small change to fix a few broken links to

Specification in the "specs" directory from the JavaDoc API.

The incorrect references either not include "{@docRoot}" or

include the non-existent "{@docRootParent}".  They should all

begin with "HYPERLINK "mailto:%7b@docRoot%7d/../specs/"{@docRoot}/../specs/";.



Bug:



   8203500 Fix broken links to Specification in "spec" directory

   https://bugs.openjdk.java.net/browse/JDK-8203500



webrev:



   http://cr.openjdk.java.net/~iris/8203500/webrev/



Thanks,

Iris



 

http://oracle.com/us/design/oracle-email-sig-198324.gif

HYPERLINK "http://oracle.com/us/design/oracle-email-sig-198324.gif";
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
HYPERLINK "mailto:lance.ander...@oracle.com"lance.ander...@oracle.com

 





 

RFR (S): 8203500: Fix broken links to Specification in "specs" directory

[Iris Clark]

Hi.

 

Please review this small change to fix a few broken links to

Specification in the "specs" directory from the JavaDoc API.

The incorrect references either not include "{@docRoot}" or

include the non-existent "{@docRootParent}".  They should all

begin with "{@docRoot}/../specs/".

 

Bug:

 

8203500 Fix broken links to Specification in "spec" directory

https://bugs.openjdk.java.net/browse/JDK-8203500

 

webrev:

 

http://cr.openjdk.java.net/~iris/8203500/webrev/

 

Thanks,

Iris

 

RE: RFR [9] 8150168: jconsole AboutDialog should use the JDK specific Version API

[Iris Clark]

Hi, Chris.

I think that change is fine.  

I've added a note to JDK-8144062 (module for jdk.Version), indicating that this 
code may need to be changed depending on how that issue is resolved.

Thanks,
iris

-Original Message-
From: Chris Hegarty 
Sent: Thursday, February 18, 2016 5:42 AM
To: serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net
Subject: RFR [9] 8150168: jconsole AboutDialog should use the JDK specific 
Version API

With the introduction of a JDK specific Version API, the console AboutDialog 
should no longer use sun.misc.Version. It should be be updated to use the new 
JDK specific API. 

diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java 
b/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java
--- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java 
+++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java
@@ -34,8 +34,6 @@
 import javax.swing.border.*;
 import javax.swing.event.*; 
  
-import static sun.misc.Version.jdkMinorVersion;
-
 import static java.awt.BorderLayout.*;  import static 
sun.tools.jconsole.Utilities.*; 
  
@@ -183,7 +181,7 @@ 
 } 
  
 private static String getOnlineDocUrl() {
- String version = Integer.toString(jdkMinorVersion()); 
+ String version = Integer.toString(jdk.Version.current().major());
 return 
Resources.format(Messages.HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL, 
 version); 
 }

-Chris.

https://bugs.openjdk.java.net/browse/JDK-8150168

RE: RFR 7199353: Allow ConstructorProperties annotation from any package

[Iris Clark]

Hi, Alan.

> JEP 223 isn't in JDK 9 yet. I've no doubt there will be a s/1.9/9/g when it 
> goes in, it will probably need to be done a few times to ensure changes in 
> progress at the time of the switch are caught.

Correct.  For reference, here's the bug:

8136494: Update "@since 1.9" to "@since 9" to match 
java.specification.version
https://bugs.openjdk.java.net/browse/JDK-8136494

Thanks,
Iris

RE: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning)

[Iris Clark]

Hi, Jaroslav, Shanliang, and Daniel.

I pushed the changeset this morning to verona/stage.  Expect the changeset to 
get to jdk9/* when we Verona is complete, later this summer.

Thanks again for all your help.

iris

-Original Message-
From: verona-dev [mailto:verona-dev-boun...@openjdk.java.net] On Behalf Of 
iris.cl...@oracle.com
Sent: Tuesday, July 21, 2015 10:29 AM
To: verona-...@openjdk.java.net
Subject: hg: verona/stage/jdk: 8132003: Update javax/management regression test 
for Verona (versioning)

Changeset: 5b2729b93dee
Author:iris
Date:  2015-07-21 10:28 -0700
URL:   http://hg.openjdk.java.net/verona/stage/jdk/rev/5b2729b93dee

8132003: Update javax/management regression test for Verona (versioning)
Reviewed-by: dfuchs, jbachorik, sjiang

! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java

RE: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning)

[Iris Clark]

Hi, Jaroslav, Shanliang, and Daniel.

Thank you all for speedy review.  I'll push the changeset to verona/stage 
shortly.

Regards,
iris

-Original Message-
From: Jaroslav Bachorik 
Sent: Tuesday, July 21, 2015 3:33 AM
To: serviceability-dev@openjdk.java.net
Subject: Re: RFR (xs) 8132003: Update javax/management regression test for 
Verona (versioning)

Looks fine. Not likely this test will ever be run on pre JDK 1.5.

-JB-

On 21.7.2015 07:30, Iris Clark wrote:
> Hi.
>
> Please review changes to resolve the following bug:
>
> 8132003: Update javax/management regression test for Verona 
> (versioning)
> Bug: https://bugs.openjdk.java.net/browse/JDK-8132003
>
> The regression test 
> javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails 
> in Verona [0,1] builds because it assumes that the system property 
> java.verison will always begin with "1.".  Verona drops this part of the 
> version string for JDK 9 and later.
>
> The test attempts to discern whether it is being run against JDK 1.4 or 
> earlier.  Since I believe that this test will never be run against JDK 1.4, I 
> expect that we can entirely remove the conditional.  Here's the required diff:
>
> --- 
> a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java
>  Mon Jul 20 11:01:24 2015 -0700
> +++ b/test/javax/management/remote/mandatory/notif/NotSerializableNoti
> +++ fTest.java
>  Mon Jul 20 19:31:54 2015 -0700 @@ -24,7 +24,7 @@
>   /*
>* @test
>* @summary Tests to send a not serializable notification.
> - * @bug 5022196
> + * @bug 5022196 8132003
>* @author Shanliang JIANG
>* @modules java.management
>* @run clean NotSerializableNotifTest @@ -53,22 +53,13 @@
>   private static final MBeanServer mbeanServer = 
> MBeanServerFactory.createMBeanServer();
>   private static ObjectName emitter;
>
> -private static String[] protocols;
> +private static String[] protocols = new String[] {"rmi", "iiop", 
> + "jmxmp"};
>
>   private static final int sentNotifs = 10;
>
>   public static void main(String[] args) throws Exception {
>   System.out.println(">>> Test to send a not serializable 
> notification");
>
> -// IIOP fails on JDK1.4, see 5034318
> -final String v = System.getProperty("java.version");
> -float f = Float.parseFloat(v.substring(0, 3));
> -if (f<1.5) {
> -protocols = new String[] {"rmi", "jmxmp"};
> -} else {
> -protocols = new String[] {"rmi", "iiop", "jmxmp"};
> -}
> -
>   emitter = new ObjectName("Default:name=NotificationEmitter");
>   mbeanServer.registerMBean(new NotificationEmitter(), 
> emitter);
>
> If you believe that we need to keep the conditional, I can submit an 
> alternate diff.  Let me know what you'd prefer.  Please also let me know if 
> there are any JMX-specific development processes I should be aware of (e.g. 
> required number of Reviewers, testing requirements, etc.).
>
> After review, the changeset will be pushed to verona/stage [2]. The changeset 
> will go to jdk9/* when Verona is complete later this summer.
>
> Thanks,
> iris
>
> [0] http://openjdk.java.net/projects/verona
> [1] http://openjdk.java.net/jeps/223
> [2] http://hg.openjdk.java.net/verona/stage
>

RFR (xs) 8132003: Update javax/management regression test for Verona (versioning)

[Iris Clark]

Hi.

Please review changes to resolve the following bug:

8132003: Update javax/management regression test for Verona (versioning)
Bug: https://bugs.openjdk.java.net/browse/JDK-8132003

The regression test 
javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails in 
Verona [0,1] builds because it assumes that the system property java.verison 
will always begin with "1.".  Verona drops this part of the version string for 
JDK 9 and later.

The test attempts to discern whether it is being run against JDK 1.4 or 
earlier.  Since I believe that this test will never be run against JDK 1.4, I 
expect that we can entirely remove the conditional.  Here's the required diff:

--- a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java
Mon Jul 20 11:01:24 2015 -0700
+++ b/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java
Mon Jul 20 19:31:54 2015 -0700
@@ -24,7 +24,7 @@
 /*
  * @test
  * @summary Tests to send a not serializable notification.
- * @bug 5022196
+ * @bug 5022196 8132003
  * @author Shanliang JIANG
  * @modules java.management
  * @run clean NotSerializableNotifTest
@@ -53,22 +53,13 @@
 private static final MBeanServer mbeanServer = 
MBeanServerFactory.createMBeanServer();
 private static ObjectName emitter;

-private static String[] protocols;
+private static String[] protocols = new String[] {"rmi", "iiop", "jmxmp"};

 private static final int sentNotifs = 10;

 public static void main(String[] args) throws Exception {
 System.out.println(">>> Test to send a not serializable notification");

-// IIOP fails on JDK1.4, see 5034318
-final String v = System.getProperty("java.version");
-float f = Float.parseFloat(v.substring(0, 3));
-if (f<1.5) {
-protocols = new String[] {"rmi", "jmxmp"};
-} else {
-protocols = new String[] {"rmi", "iiop", "jmxmp"};
-}
-
 emitter = new ObjectName("Default:name=NotificationEmitter");
 mbeanServer.registerMBean(new NotificationEmitter(), emitter);

If you believe that we need to keep the conditional, I can submit an alternate 
diff.  Let me know what you'd prefer.  Please also let me know if there are any 
JMX-specific development processes I should be aware of (e.g. required number 
of Reviewers, testing requirements, etc.).

After review, the changeset will be pushed to verona/stage [2]. The changeset 
will go to jdk9/* when Verona is complete later this summer.

Thanks,
iris

[0] http://openjdk.java.net/projects/verona
[1] http://openjdk.java.net/jeps/223
[2] http://hg.openjdk.java.net/verona/stage

RE: RFR: JDK-8075056 Remove Version.java.template from jconsole

[Iris Clark]

Hi, Staffan.

> bug: https://bugs.openjdk.java.net/browse/JDK-8075056
> webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ 
> 

Looks good.  I'm always happy to see changes where complexity is reduced.

Thanks,
iris

RE: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

[Iris Clark]

> So overall it looks good to me and should be pushed to the staging > forest 
> once you hear from others that commented previously.

I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov.  Alan, 
please correct me if I'm wrong.

Thanks,
iris

-Original Message-
From: Alan Bateman 
Sent: Tuesday, November 26, 2013 9:03 AM
To: Volker Simonis
Cc: Vladimir Kozlov; 2d-...@openjdk.java.net; 
serviceability-dev@openjdk.java.net; security-dev; 
ppc-aix-port-...@openjdk.java.net; awt-...@openjdk.java.net; Java Core Libs; 
net-dev
Subject: Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and 
files to build the class library on AIX

On 26/11/2013 16:23, Volker Simonis wrote:
> Hi,
>
> thanks to everybody for the prompt and helpful reviews. Here comes the 
> final webrev which incorporates all the corrections and suggestions 
> from the second review round:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>
> I've successfully build (and run some smoke tests) with these changes 
> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, 
> MacOSX and AIX (5.3, 7.1).
>
I've skimmed over the last webrev with focus on:

NetworkingLibraries.gmk where I see this is now fixed for all platforms.

net_util.* and the platform specific net_util_md.* where I see you've added 
platformInit so it's much cleaner.

UnixNativeDispatcher.c where the error translation is now removed (and looks 
fine).

So overall it looks good to me and should be pushed to the staging forest once 
you hear from others that commented previously.

-Alan

RE: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

[Iris Clark]

Hi.

>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/

> + src/solaris/classes/java/lang/UNIXProcess.java.aix
> 2  * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
> reserved.
> 3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Oracle copyright in acceptable location and uses correct format.

> + src/aix/porting/porting_aix.h
> 2  * Copyright 2012, 2013 SAP AG. All rights reserved.
> 3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

SAP copyright in acceptable location.

> + src/aix/native/sun/tools/attach/AixVirtualMachine.c
> 2  * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights 
> reserved.
> 3  * Copyright 2013 SAP AG. All rights reserved.
> 4  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER

Oracle and SAP copyrights in acceptable locations.  Oracle format is correct.

The licenses (GPL+CP) look fine to me.

Thanks,
iris

-Original Message-
From: Sergey Bylokhov 
Sent: Tuesday, November 26, 2013 10:52 AM
To: Alan Bateman; Volker Simonis
Cc: 2d-...@openjdk.java.net; serviceability-dev@openjdk.java.net; security-dev; 
ppc-aix-port-...@openjdk.java.net; awt-...@openjdk.java.net; Java Core Libs; 
net-dev
Subject: Re:  RFR(L) - 2nd round: 8024854: Basic changes and files to 
build the class library on AIX

On 26.11.2013 21:03, Alan Bateman wrote:
> On 26/11/2013 16:23, Volker Simonis wrote:
>> Hi,
>>
>> thanks to everybody for the prompt and helpful reviews. Here comes 
>> the final webrev which incorporates all the corrections and 
>> suggestions from the second review round:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>>
>> I've successfully build (and run some smoke tests) with these changes 
>> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, 
>> MacOSX and AIX (5.3, 7.1).
>>
> I've skimmed over the last webrev with focus on:
>
> NetworkingLibraries.gmk where I see this is now fixed for all platforms.
>
> net_util.* and the platform specific net_util_md.* where I see you've 
> added platformInit so it's much cleaner.
I have a question about boolean_t in the [1]. Is it correct to skip it in the 
new block?
http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/src/share/native/sun/security/ec/impl/ecc_impl.h.frames.html

Also I have a question about headers in the added files. Looks like different 
templates are used:

+ src/solaris/classes/java/lang/UNIXProcess.java.aix
2  * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
reserved.
3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ src/aix/porting/porting_aix.h
2  * Copyright 2012, 2013 SAP AG. All rights reserved.
3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ src/aix/native/sun/tools/attach/AixVirtualMachine.c
2  * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights 
reserved.
3  * Copyright 2013 SAP AG. All rights reserved.
4  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

etc..

Do we have some rules about that?
>
> UnixNativeDispatcher.c where the error translation is now removed (and 
> looks fine).
>
> So overall it looks good to me and should be pushed to the staging 
> forest once you hear from others that commented previously.
>
> -Alan


--
Best regards, Sergey.

RE: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX

[Iris Clark]

Hi, Volker.

Just wanted to say that in addition to preparing for JavaOne (next week!), 
we're also busy fixing bugs in anticipation of JDK 8 ZBB milestone on 24 Oct 
[1].

Thanks,
iris

[1]: http://openjdk.java.net/projects/jdk8/milestones

-Original Message-
From: Phil Race 
Sent: Wednesday, September 18, 2013 3:23 PM
To: Volker Simonis
Cc: serviceability-dev@openjdk.java.net; 2d-...@openjdk.java.net; 
ppc-aix-port-...@openjdk.java.net; Java Core Libs; awt-...@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build 
the class library on AIX

Volker,

I've skimmed the client related changes - mostly based on the descriptions.
I'll look in more detail as soon as I can after JavaOne. We also have some 
engineers out on vacation who might want to look at these too.

A couple of things that stood out :
"On AIX, fontconfig is not a standard package supported by IBM."
I am surprised AIX does not support fontconfig.
That is something IBM should reconsider as its hard to imagine a modern Unix 
based system working without it ..

Very basic start for AIX -  feel free to complete ..
  169  */
  170 static char *fullAixFontPath[] = { ...

I'd really like to see it completed but these days that's largely a fall back 
for no fontconfig.

/* AIX does not provide the 'dladdr' function. But fortunately, we've
   42  * already implemented it in the HotSpot, because we need it there as
   43  * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).

Whilst this is in "ifdef AIX" this reliance on an exported hotspot function 
sounds hacky. What actual requirement is there that the AIX class libraries be 
so tightly-coupled with that VM?
There is no contract there.

-phil.



On 9/16/2013 12:30 PM, Volker Simonis wrote:
> Resending this to more lists as requested by Alan Bateman with the 
> kind request to anybody to review the parts for which he feels
> responsible:)
>
> For those not up to date, this change is part of the ongoing 
> PowerPC/AIX Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
>
> Please send reviews to all currently included recipients.
>
> Thank you and best regards,
> Volker
>
>
> -- Forwarded message --
> From: *Volker Simonis*
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class 
> library on AIX
> To: "ppc-aix-port-...@openjdk.java.net
> " 
>  >, Java Core Libs 
>  >
>
>
> Hi,
>
> could you please review the following webrev which contains the basic 
> changes and files needed in the 'jdk' repository in order to build the 
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
> 
>
> This change together with "8024265: Enable new build on AIX (jdk part) 
> " allows 
> it to configure and completely build the staging repository on AIX 5.3 
> and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core 
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> Below you can find the changes and additions I've done, sorted by 
> file. Most of them are just additions which are only active during the 
> AIX build anyway or simple changes where AIX has been added to 
> conditions which already check for Linux and/or Solaris. The files 
> with the biggest changes which you're probably want to look on more 
> thoroughly are 'src/solaris/native/java/net/NetworkInterface.c' and 
> 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change 
> anything on the current OpenJDK platforms as well.
>
> Notice that there are still some files and some functionality missing 
> from the current change (notably NIO) but it still yields a running 
> JDK which can execute "HelloWorld" on the command line and as AWT 
> application. I've intentionally tried to keep this initial change as 
> simple as possible (with respect tot shared changes) in order to get 
> it reviewed as fast as possible. The missing parts can then be added 
> later on, grouped by logical topics, to simplify the review process.
>
> Thank you and best regards,
>
> Volker
>
>
> src/share/bin/jli_util.h
>
>   * Define |JLI_Lseek| on AIX.
>
>
> src/share/lib/security/java.security-aix
>
>   * Provide default |java.security-aix| for AIX.
>
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
>   * Add AIX to the list of known platforms.
>
>
> src/share/native/sun/font/layout/KernTable.cpp
>
>   * Rename the macro |DEBUG| to |DEBUG_

RE: 7173494: some jdk tests are not run in test/Makefile

[Iris Clark]

> The webrev with the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/7173494/webrev/

Looks like a good clean-up.

iris

RE: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale

[Iris Clark]

Hi, Dan.

> Just FYI: I haven't seen Éamonn's posting come in. Just replies to his
> posting. This may mean that other comments are stuck in the ether 
> somewhere...
> 
> I suspect that the OpenJDK list server is again having issues...

I just checked the core-libs-dev admin interface to see if anything was waiting 
for moderation, but there wasn't anything.  (Not that I'd expect that to be the 
case for messages from Éamonn.)  

Must be a failure at some other level...  Sorry.

iris