Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

On 02.11.2013 15:37, Alan Bateman wrote: On 01/11/2013 11:18, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client, java.lang, security, jmx etc has incorrect copyright. According to the http://openjdk.java.net/faq GPL v2

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

Hello, Updated version: http://cr.openjdk.java.net/~serb/8027696/webrev.01/ Dates and spaces were fixed. On 02.11.2013 15:37, Alan Bateman wrote: On 01/11/2013 11:18, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

On 07.11.2013 15:22, Alan Bateman wrote: Thanks Sergey, I sampled a few and they look correct. The only thing is that I'm not sure about is test/Makefile, it's just not clear whether which header this should have. I can skip it this time. -- Best regards, Sergey.

Re: [8] Review Request: 8027696 Incorrect copyright header in the tests

Hello. I'll push the changes, if there are no new objections. On 07.11.2013 17:46, Sergey Bylokhov wrote: On 07.11.2013 15:22, Alan Bateman wrote: Thanks Sergey, I sampled a few and they look correct. The only thing is that I'm not sure about is test/Makefile, it's just not clear whether

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

has been already answered by Iris (thanks Iris). Thank you and best regards, Volker On Tuesday, November 26, 2013, Sergey Bylokhov wrote: On 26.11.2013 21:03, Alan Bateman wrote: On 26/11/2013 16:23, Volker Simonis wrote: Hi, thanks to everybody

Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9

On 23.01.2014 3:53, Vladimir Kozlov wrote: I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 Looks like the problem is that 8032348 is not pushed to the master workspace of jdk9, but the bootjdk have this fix. to

Re: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes

On 3/7/14 3:31 PM, Alan Bateman wrote: On 06/03/2014 21:10, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ This patch converts the use of sun.security.action.GetPropertyAction tolambda (PrivilegedActionString) () - System.getProperty(key)

Re: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes

Hi, Alan. Why we cannot move these classes to java.security.* package instead? On 3/7/14 6:36 PM, Alan Bateman wrote: On 07/03/2014 13:14, Florian Weimer wrote: I think we had sun.security.action.GetPropertyAction for exactly this purpose. Consequently, the proposed change actually

[9] Review request: new macro for conversion to jboolean

Hello. This review request is for the new macro, which simplify conversion to jboolean. It will be useful for fixing parfait warnings. We have a lot of places, where we cast some type to jboolean: BOOL = retVal; return (jboolean) retVal; WARNING: Expecting value of JNI primitive type

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

Thanks Anthony! Can somebody from the core-libs team take a look? On 3/17/14 10:31 PM, Anthony Petrov wrote: Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me too. Either way, I'm fine with the fix. -- best regards, Anthony On 3/17/2014 7:01 PM, Sergey Bylokhov

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

to jboolean as they probably should. Mike On Mar 19 2014, at 11:36 , Sergey Bylokhov sergey.bylok...@oracle.com wrote: Thanks Anthony! Can somebody from the core-libs team take a look? On 3/17/14 10:31 PM, Anthony Petrov wrote: Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

); if (IS_TRUE(obj)) {} jboolean ret = IS_TRUE(obj); The general purpose usage matches the general C conventions for true and false and match the JNI semantics. Actually that was my initial suggestion(name and usage). Roger On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: Thanks. So

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

)) {} jboolean ret = IS_TRUE(obj); The general purpose usage matches the general C conventions for true and false and match the JNI semantics. Roger On 3/19/2014 7:43 PM, Sergey Bylokhov wrote: Thanks. So if nobody objects, the final version will be: #define IS_NULL(obj) ((obj) == NULL) #define

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

. -- best regards, Anthony On 3/23/2014 10:10 PM, Alan Bateman wrote: On 21/03/2014 15:22, Sergey Bylokhov wrote: On 3/21/14 7:10 PM, roger riggs wrote: The macro would just as useful (if I understand the cases) without the cast. How useful is a simple definition as: #define IS_TRUE(obj

Re: Core Libs Dev[9] Review request for 8039041: tidy warnings cleanup for javax.naming

Hello, I think doclint should checks this type of issues? On 03.04.2014 13:01, alexander stepanov wrote: Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8039041 Webrev corresponding: http://cr.openjdk.java.net/~yan/8039041/webrev.00/

Re: AWT Dev JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

Hi, Paul. adding 2d-dev@ media: sound/awt/swing part looks fine. Note that this part of the fix should be pushed to client forest. On 5/12/14 2:03 PM, Paul Sandoz wrote: Hi, This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need

Re: Replace concat String to append in StringBuilder parameters

Hi Otávio, The new alignment in DataLine.java/JColorChooser.java looks strange. Wrong change in BasicTableUI.java: -plainStr.deleteCharAt(plainStr.length() - 1).append(\n); +plainStr.deleteCharAt(plainStr.length() - 1).append('\t'); On 13.08.2014 3:01,

Re: jsr 305

for JSR 308 and see what their current status is - the last I heard they were interested in trying to make the cut for JDK 8. Does anyone have more information? Thanks, Ben On Tue, Sep 20, 2011 at 3:13 AM, Sergey Bylokhov sergey.bylok...@oracle.com wrote: Hello, all. Does anybody know what

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

There was related discussions on the past http://mail.openjdk.java.net/pipermail/compiler-dev/2014-February/008491.html And related issues: https://bugs.openjdk.java.net/browse/JDK-4947460 https://bugs.openjdk.java.net/browse/JDK-4059189 https://bugs.openjdk.java.net/browse/JDK-6709423 On

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

On 08.09.2014 21:50, Jonathan Gibbons wrote: Yes, but is this really a big enough performance and footprint pain point to be worth addressing in javac itself? We're now talking about some specific code construction like new StringBuilder().append(a + b + c) Any other case where the string

Status of 4500542: WeakIdentityHashMap?

Hello, Everybody. Does anyone know the status of 4500542? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500542 It was postponed? I counted at least 3 similar but slightly different internal implementations of it in the jdk. Probably additional option could be added to the WeakHashMap to

Re: AWT Dev Swing Dev sun.awt.X11 logs still using String + (waste)

us a new patch? -- best regards, Anthony On 4/1/2013 16:08, Sergey Bylokhov wrote: Hi, Anthony Only two comments: 1 Why we need some special text in the log

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

Hi, Laurent. I am not an expert here but just my 50 cents. This optimization shall take place only if it is really hotspot. But if it is a really hotspot - probably it would be better to remove these array/object allocation at all and use plane bytes? I see that some methods which take it as

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency memory waste

On 4/10/13 11:46 PM, Laurent Bourgès wrote: I see that some methods which take it as argument doesn't use them. And most of the time we pass AATileGenerator and abox[] to the same methods, so it could be merged? For now I did not want to modify the AAShapePipe signatures: abox[] is filled by

Re: AWT Dev Swing Dev sun.awt.X11 logs still using String + (waste)

Hello. New version looks fine to me. On 4/11/13 8:08 PM, Laurent Bourgès wrote: Anthony, Here is the updated webrev: http://jmmc.fr/~bourgesl/share/webrev-8010297.5/ Laurent 2013/4/11 Mandy Chung mandy.ch...@oracle.com On 4/11/13 8:43 AM, Laurent Bourgès wrote: I don't understand if I

Re: JDK 8 code review request for doclint issues in java.lang.instrument

Hello, I have a question about of p/ = p. Should we follow html specification[1] here or we should always replace p/ to p? [1] http://dev.w3.org/html5/markup/p.html#p see@ Tag omission On 01.07.2013 22:47, Alan Bateman wrote: On 01/07/2013 19:24, Joe Darcy wrote: Hello, Yet another found

[8] Review Request: 8027696 Incorrect copyright header in the tests

Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client, java.lang, security, jmx etc has incorrect copyright. According to the http://openjdk.java.net/faq GPL v2 + the Classpath exception for the class libraries and those parts of the virtual

Re: RFR: JDK-8068033: Fix Java Launcher for splash screen.

Hello, The looks good. On 03.02.2015 3:38, Kumar Srinivasan wrote: Hi, Appreciate a review of this fix for JNI correctness when dealing with Splash Screen on MacOSX. http://cr.openjdk.java.net/~ksrini/8068033/webrev.0/ Sergey, I think you took over from Anthony Petrov for SplashScreen, if

Re: RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33

Just curious, what is the difference between this fix and an old version of the code: http://cr.openjdk.java.net/~shade/8058643/webrev.01/src/java.base/share/classes/java/lang/String.java.sdiff.html I meant: if (h == 0 value.length 0) {} vs if (h != 0) {hash = h;} On 13.05.15 14:51, Claes

Re: AWT Dev [9] Review Request: 8076264 [macosx] Launching app on MacOSX requires enclosing class

); } } } ---CUT On 4/9/2015 3:06 PM, Sergey Bylokhov wrote: Hello, Can somebody from the core team take a look? Thanks. On 08.04.15 16:29, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 9. After the fix we clear all errors

[9] Review Request: 8076264 [macosx] Launching app on MacOSX requires enclosing class

Hello. Please review the fix for jdk 9. After the fix we clear all errors caused by getCanonicalName() on the mainclass and leave JAVA_MAIN_CLASS_ empty. This empty case will be handled in the NSApplicationAWT.m. Plus small cleanup suggested in the bug report(jstring-jclass). Bug:

Re: jsr 305

in the JCP: https://www.jcp.org/en/jsr/detail?id=305 At this point, the addition of annotations in that vein should probably occur under the banner of a different effort. Cheers, -Joe On 08/19/2014 11:16 AM, Sergey Bylokhov wrote: Hi, Joe. There are no news about this jsr in jdk9? I guess

LittleEndian in DataInputStream

Hello, Does anybody know, do we plan to add LittleEndian support to the DataInputStream or probably to some other InputStream? -- Best regards, Sergey.

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

On 05.12.15 21:23, Peter Levart wrote: Digging up the src.jar of JDK 1.2.2, here's what the constructor of PhantomReference looked like: /** * Creates a new phantom reference that refers to the given object and * is registered with the given queue. * * @throws

Re: JDK 9 RFR to problem list a failing test

Hi, Joe. I think it is quite easy to fix the test itself. Just use some other existed class from sun.misc. On 17/12/15 00:58, joe darcy wrote: Hello, The test java/beans/Introspector/Test6277246.java fails to compile after the change for JDK-8144479 , reporting an error

Re: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

Hi, Chris. What is the reason to use assertion? If the problem is not theoretical, then probably OOM(or something like that) will be better? On 11/12/15 20:22, Chris Hegarty wrote: More technical debt in sun.misc… Java SE has had support for Queues in Collections for many major releases,

Re: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479

Looks fine. On 17/12/15 18:28, Roger Riggs wrote: +1 On 12/17/2015 10:15 AM, Chris Hegarty wrote: For ease of review, I moved the complete changes into a webrev. http://cr.openjdk.java.net/~chegar/8145589/webrev/ -Chris. On 17 Dec 2015, at 15:08, Chris Hegarty

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Should the new methods describe how they will work in case of null params? On 16/12/15 16:04, Yasumasa Suenaga wrote: I adapted this enhancement after JDK-8145260: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ Could you review it? Thanks, Yasumasa On 2015/12/12 21:23,

Re: JDK 9 RFR of problem listing of java_sql_Timestamp.java

I think that we can fix the bug itself since the fix is trivial and already proposed by Mandy, no? On 01.06.16 1:17, Joseph D. Darcy wrote: Hello, After the push for , the test java/beans/XMLEncoder/java_sql_Timestamp.java is failing across platforms. I'd like to problem list the test

Re: [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper message displaying

Looks fine. On 22.06.16 1:58, David DeHaven wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8022291 Webrev: http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Looks fine. On 12.03.16 6:28, joe darcy wrote: Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

The fix looks fine to me. can you please clarify what "enabling better reporting" from the bug description means? Where this information will be reported? On 31.03.16 2:48, Joseph D. Darcy wrote: Hi Mandy, Hopefully the third time will be the charm for this changeset after your correction to

[9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

Hello. Please review the fix for jdk9. This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug

Re: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword

Looks fine. - matthias.baes...@sap.com wrote: > > > Hello all, could I have a review for this small change ? Thanks, Matthias > From: Langer, Christoph > Sent: Freitag, 30. Juni 2017 23:50 > To: Baesken, Matthias ; awt-...@openjdk.java.net > Cc:

Re: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in java.base & java.datatransfer module

Looks fine to me. Thank you for clarification. - huaming...@oracle.com wrote: > Ping. > > Thank you > > -Hamlin > > > On 2017/5/31 8:13, Hamlin Li wrote: > > Hi Alan, Sergey, > > > > Sorry for delayed reply, I have been on vacation for last few days. > > > > I do have a tool (still under

Re: [10] Review Request: 8187442 Xcheck:jni produces various "WARNING in native method" in launcher

ot;Hello world\");\n");     tsrc.append("}\n");     createJar(testJar, new File("Foo"), tsrc.toString()); but what you currently have is also fine, thanks for making these changes. Kumar On 13/09/2017 9:42 AM, Sergey Bylokhov wrote: On 9/12/17 16:03, David Holmes wrote

Re: [10] Review Request: 8187442 Xcheck:jni produces various "WARNING in native method" in launcher

e the result of the method which produced an exception. David This value will be propagated to JavaMain() and I as far as understand will stop the execution. On 9/12/17 13:56, David Holmes wrote: Hi Sergey, On 13/09/2017 5:18 AM, Sergey Bylokhov wrote: Hello, Please review the fix fo

[10] Review Request: 8187442 Xcheck:jni produces various "WARNING in native method" in launcher

Hello, Please review the fix for jdk10/jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8187442 Webrev can be found at: http://cr.openjdk.java.net/~serb/8187442/webrev.00 The simple application with empty main method produce some "warnings" when Xcheck:jni is used. Because of that it is

Re: [10] Review Request: 8187442 Xcheck:jni produces various "WARNING in native method" in launcher

ut in case of CallStaticObjectMethod() we cannot check for NULL which can be a valid result, so I added a check for exception and return 0. This value will be propagated to JavaMain() and I as far as understand will stop the execution. On 9/12/17 13:56, David Holmes wrote: Hi Sergey, On 13/09

Re: [10] Review Request: 8187442 Xcheck:jni produces various "WARNING in native method" in launcher

, On 13/09/2017 5:18 AM, Sergey Bylokhov wrote: Hello, Please review the fix for jdk10/jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8187442 Webrev can be found at: http://cr.openjdk.java.net/~serb/8187442/webrev.00 This doesn't look right to me:    str = (*env

Re: RFR 8191736: replace javah w/ javac in jdk tests

Looks fine. On 21/11/2017 16:09, Jonathan Gibbons wrote: Shura, Looks OK to me, although I'm not normally a Reviewer for AWT tests. -- Jon On 11/21/17 3:58 PM, Alexandre (Shura) Iline wrote: Hi. Please take look on this quick fix of removing remains of javah usages from test/jdk. Bug:

Re: RFR 4358774: Add null InputStream and OutputStream

On 07/12/2017 14:55, Brian Burkhalter wrote: Hi Roger, I agree. It does not seem that whatever performance improvement might accrue from not using the Objects methods is offset by the increased code readability in addition to mitigating the risks mentioned in [1]. I have reinstated this

Re: RFR 4358774: Add null InputStream and OutputStream

Hi, Brian. On 08/12/2017 15:12, Brian Burkhalter wrote: All previous suggested changes have been made in http://cr.openjdk.java.net/~bpb/4358774/webrev.03/ One more issue that according to the spec the new method read(byte[], int, int) should throw an exception if the stream was closed, but

Re: RFR 4358774: Add null InputStream and OutputStream

On 08/12/2017 16:49, Brian Burkhalter wrote: I agree it looks strange but it is intentional as it matches the existing InputStream.read(byte[],int,in) [1]. (I will remove line 167 as part of this patch.) Note that the IOE for the stream being closed would not be thrown in the current code

[11] Review Request: 8205537 Drop of sun.applet package

Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related to implementation of applets and appletviewer. Some of its classes were

Re: [11] Review Request: 8205537 Drop of sun.applet package

I can argue that this is not p2 as related JDK-8201446, but it is definitely not p4. On 02/07/2018 09:30, Phil Race wrote: It is not necessary and I reject that it is a P3. Let's leave it for 12. -phil. On 07/02/2018 09:24 AM, Sergey Bylokhov wrote: I think it is a good thing to drop

Re: [11] Review Request: 8205537 Drop of sun.applet package

it for 11, but will consider it for 12. -phil. On 7/2/2018 6:36 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some

Re: RFR(S): 8194869: [TESTBUG][aix, s390] Adapt tests to platforms.

The client part looks fine. On 17/01/2018 04:43, Lindenmaier, Goetz wrote: Posting this to awt-dev, too. This change adapts some tests to run on properly on aix or s390: http://cr.openjdk.java.net/~goetz/wr18/8194869-jtregAix/webrev.03/ Best regards, Goetz. -Original Message-

[12] Review Request: 8205537 Drop of sun.applet package

Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related to implementation of applets and appletviewer. Some of its classes were dropped

Re: [12] Review Request: 8205537 Drop of sun.applet package

On 31/07/2018 16:39, Sergey Bylokhov wrote: Hello. Please review the fix for jdk11. typo, I meant jdk12. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related

Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

Hi, Joe. On 06/08/2018 14:30, joe darcy wrote: Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Can you please clarify this: what does it mean "ineffectual" in this context? why we need to

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

Looks fine. On 28/08/2018 09:50, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html 698 lines changed: 114 ins; 240 del; 344 mod Hi all, could you please review this clean up of jdk testlibrary? the patch updates the tests to use jdk.test.lib.Platform

Re: RFR: 8200129 : Remove D3D Performance Counter.

Looks fine. On 22/03/2018 13:33, Phil Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8200129 webrev: http://cr.openjdk.java.net/~prr/8200129/ It was noted in another thread [1] that we had a couple of qualified exports from java.base to java.desktop that are platform-specific but

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi, Brian. It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n); "This method may skip more bytes than what are remaining in the * backing file. This produces no

Re: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception

+1 On 30/10/2018 07:05, Thomas Stüfe wrote: Seems fine and trivial. Regards, Thomas On Tue, Oct 30, 2018 at 2:56 PM Volker Simonis wrote: Hi, can I please have a review for the following tiny change which fixes the license header on a few AIX-specific files:

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

On 09/11/2018 14:04, Brian Burkhalter wrote: Attached is a patch on top of your webrev with my attempt at separating normative text and reducing the complexity in the @implSpec. I like the verbiage the way you modified it. An updated patch is at

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi, All. it may be better to burn "skip()" in the fire of deprecation? and implement the "newSkip()" which by default will call the "read()", and then subclasses will provide its own fast/optimized implementation? Or we still tries to take care about all corner cases for "skip()"? On 08/11/2018

Re: ByteArrayOutputStream should not have a new writeBytes method in Java

I can review the changes in java.desktop, please use these email alias awt-dev/2d-dev/swing-dev. On 28/09/2018 04:13, Alan Bateman wrote: As regards doing the entire source base then I think that would be good. Due to the complexity of testing, changes to the java.desktop module are pushed to

Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

Hi, Sean. One question related to SecurityManager and performance, is it possible to provide a special version of AccessController.doPrivileged which will be noop if SecurityManager is not present? On 03/10/2018 13:12, Sean Mullan wrote: For those of you that are not also subscribed to

Re: RFR(M) : 8210894 : remove jdk/testlibrary/Asserts

Looks fine. On 19/09/2018 10:18, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html 1188 lines changed: 252 ins; 591 del; 345 mod; Hi all, could you please review the next clean up of jdk testlibrary? now we are replacing all usages of

Re: RFR; 8211031: Remove un-needed qualified export to java.desktop from java.base on macos

Hi, Phil. On 21/09/2018 22:24, Philip Race wrote: [*] at this exact moment, cr.openjdk.java.net isn't working but hopefully that will be fixed by the time anyone reads this :-) The classExists() method still there in version .1 -- Best regards, Sergey.

Re: RFR; 8211031: Remove un-needed qualified export to java.desktop from java.base on macos

Looks fine. On 26/09/2018 14:07, Phil Race wrote: Not 100% sure what happened there. I've re-uploaded it. Shift-reload to avoid browser caching and look again. -phil. On 09/26/2018 01:51 PM, Sergey Bylokhov wrote: Hi, Phil. On 21/09/2018 22:24, Philip Race wrote: [*] at this exact moment

Re: [OpenJDK 2D-Dev] RFR: 8130264 : change the mechanism by which JDK loads the platform-specific PrinterJob implementation

Looks fine. On 15/11/2018 13:41, Phil Race wrote: bug: http://cr.openjdk.java.net/~prr/8130264/ webrev: http://cr.openjdk.java.net/~prr/8130264/ Currently java launcher code embeds the name of the java.desktop module's PrinterJob implementation class for each platform in a system property

[12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped

Hello. Please review fix for jdk12. Bug: https://bugs.openjdk.java.net/browse/JDK-8210692 Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8210693 The client code has a "com.sun.awt.SecurityWarning" class which at some point in the past,

Re: Duplicate words typos in comments/javadoc/strings

Hi, Andrey. On 27/01/2019 14:35, Andrey Turbanov wrote: I checked only java.base module and fixed problems there. Does it makes sense to create patches to other modules too? You are welcome to make the similar changes in java.desktop module, please use these email alias

Re: RFR: 8223271: SplashScreen is still shown if defaulting to headless on MacOS

Looks fine. On 29/05/2019 11:38, Phil Race wrote: Any takers ? -phil. On 5/24/19 9:35 AM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8223271 Webrev : http://cr.openjdk.java.net/~prr/8223271/ Whilst working on removing some inappropriate coupling of the java launcher and

Re: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit

Hi, Phil. Looks fine, but probably it will be worth to rename PlatformGraphicsInfo to PlatformInfo? On 06/05/2019 15:11, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8212700 CSR: https://bugs.openjdk.java.net/browse/JDK-8223417 Webrev:

Re: RFR: 8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit

OK, looks fine then. On 5/7/19, 7:47 PM, Sergey Bylokhov wrote: Hi, Phil. Looks fine, but probably it will be worth to rename PlatformGraphicsInfo to PlatformInfo? I don't want (or intend) to do that. I already knew I was going to re-use this class for this purpose when I created

[13] Review Request: 8220134 Cleanup the code in java.base which take care about multiple AppContext

Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8220134 Fix: http://cr.openjdk.java.net/~serb/8220134/webrev.00 The AppContext class was used as a kind of "sandbox" in case of applets/webstart. Both applets and webstart were removed from the jdk11, since

Re: [13] Review Request: 8220134 Cleanup the code in java.base which take care about multiple AppContext

I have found one of the removed test in the ProblemList, webrev is updated in place. On 18/04/2019 15:41, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8220134 Fix: http://cr.openjdk.java.net/~serb/8220134/webrev.00

Re: RFR: 8222819: Remove setting of headless property on MacOS from launcher code.

+1 On 03/05/2019 11:21, Roger Riggs wrote: Hi Phil, Looks good, thanks for the cleanup. Roger On 05/03/2019 02:08 PM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8222819 Webrev: http://cr.openjdk.java.net/~prr/8222819/ After fixing

Re: RFR: 8212701: remove sun.desktop property from launcher code

Looks fine. On 22/04/2019 13:57, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8212701 CSR: https://bugs.openjdk.java.net/browse/JDK-8222814 Webrev: http://cr.openjdk.java.net/~prr/8212701/index.html Please review the above CSR and webrev which eliminates the sun.desktop

Re: [OpenJDK 2D-Dev] RFR: 8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class

Looks fine. On 25/04/2019 13:31, Philip Race wrote: Sorry, meant to include core-libs on this ! -phil. On 4/25/19, 1:12 PM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8130266 CSR: https://bugs.openjdk.java.net/browse/JDK- Webrev: http://cr.openjdk.java.net/~prr/8130266/

Re: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

Hi, Joe. Can we as part of this effort improve validation of javadocs tags: @serial, @serialField, etc. I am sure that we use these tags here and there incorrectly. BTW probably we should consider all serialized fields/methods/etc, as kind of public API, and validates it by doclint

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Looks fine. On 11/13/19 10:50 am, gerard ziemski wrote: Hi all, Please review this cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself: I'm including core-libs and awt in this review because the proposed fix

[14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 This change adds the "screen capture on the test failure" feature on macOS and Linux. - On Linux, it is implemented by the "gnome-screenshot"

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

are preinstalled in all cases and some of them does not work properly if transparent/visual effects are enabled(kde/gnome/etc). -- Igor On Dec 11, 2019, at 1:00 AM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 Fix

[15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18

Hello. Please review the fix for JDK 15. Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 I have updated the source code copyrights by the

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

I there are no objections I'll push the fix to JDK/client. On 12/11/19 7:29 pm, Igor Ignatyev wrote: Hi Sergey, overall looks good to me. a question about linux, is there an alternative to gnome-screenshot for DEs other than GNOME? -- Igor On Dec 11, 2019, at 1:00 AM, Sergey Bylokhov

Re: RFR: 8236075: Minor bootstrap improvements

Hi Claes, How did you measure this performance improvement? On 1/20/20 7:54 am, Claes Redestad wrote: Hi, some minor cleanups and enhancements in and around java.lang.ClassLoader which add up to a small startup improvement: - Remove use of Vector/Hashtable from ClassLoader, along with a few

Re: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18

I guess it is too late to fix it, will need to update the files at the end of 2020. On 1/2/20 10:57 am, Erik Joelsson wrote: Build files look good. /Erik On 2019-12-24 19:22, Sergey Bylokhov wrote: Hello. Here is an updated version:   Bug: https://bugs.openjdk.java.net/browse/JDK-8235975

Re: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18

the patch. - "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" On 12/22/19 11:24 pm, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 15. Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

S And it does not spend much resources compared to current handlers. Also why exclude Windows ? No easy way to get the screenshot ? There is no command-line program that can take a screenshot on windows by default -phil. On 12/11/19 1:00 AM, Sergey Bylokhov wrote: Hello. Please review th

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

via "make test", and it could easily be enabled in mach5 for personal jobs(I do this time to time) -phil. On 12/30/19, 11:33 AM, Sergey Bylokhov wrote: On 12/23/19 9:15 pm, Phil Race wrote: I am not sure what the right mailing list(s) are for this change. It definitely isn't a core-l

Re: RFR: 8252999: replace all String.equals("") usages with String.isEmpty()

On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could > be found > > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).

RFR: 8255043: Incorrectly styled copyright text

In some files, the copyright text is styled as a JavaDoc comment. Most of the affected files are tests, only one product file is affected: src/java.sql/share/classes/javax/sql/package-info.java The chenge is trivial: - /** + /* * Copyright (c) - Commit messages: - Initial fix

RFR: 8253606: Need to add missed constructor to the SwingEventMonitor

The javadoc for this class was added, but the constructor itsef is missed.. - Commit messages: - Update SwingEventMonitor.java Changes: https://git.openjdk.java.net/jdk/pull/340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=340=00 Issue:

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects

On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов wrote: > As discussed in https://github.com/openjdk/jdk/pull/510 there is never a > reason to explicitly instantiate any instance of `Atomic*` class with its > default value, i.e. `new AtomicInteger(0)` could be replaced with `new >

Re: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic* objects [v2]

On Wed, 28 Oct 2020 08:40:02 GMT, Сергей Цыпанов wrote: >> client changes are fine > > Rebased onto master to have the fix introduced in > https://github.com/openjdk/jdk/pull/778 FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.

Re: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo

On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race wrote: >>> One or two of the sources changes should probably uses Files.copy, e.g. >>> ZipPath, sjavac/CopyFile.java. >> >> Good idea! Replaced in few places. But not in ZipPath: it's actually >> implementation of underlying call from Files.copy:

  1   2   >