Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions
Hi Roger, Its confusing to use a JNU_ prefixed macro on a method not involvng jni, why not rename these to modulo JNU_ ? I am cc'ing Alex as he has a related bug fix in his queue for pack's jni code. Kumar Hi Alan, The macros are generally useful even without being used on a method that involves jni. An overly aggressive find caught the uses in java/util/jar/pack. But yes, it might be better to limit their scope to functions that involve jni. Roger On 1/16/2014 11:41 AM, Alan Bateman wrote: On 16/01/2014 16:26, roger riggs wrote: Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the "JNU_" prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for networking, pack200, and have been updated. A jprt run has passed (except for unrelated failures). webrev: http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? They don't require a JNIEnv so I'm wondering if JNU_* really make sense here. -Alan.
Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions
Roger, one more thing, shouldn't the parameters be unique ? I think Martin had me do this for all macros in the java launcher for example please see this changeset, I recently pushed. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c50c972a101 Kumar On 1/16/2014 9:30 AM, Kumar Srinivasan wrote: Hi Roger, Its confusing to use a JNU_ prefixed macro on a method not involvng jni, why not rename these to modulo JNU_ ? I am cc'ing Alex as he has a related bug fix in his queue for pack's jni code. Kumar Hi Alan, The macros are generally useful even without being used on a method that involves jni. An overly aggressive find caught the uses in java/util/jar/pack. But yes, it might be better to limit their scope to functions that involve jni. Roger On 1/16/2014 11:41 AM, Alan Bateman wrote: On 16/01/2014 16:26, roger riggs wrote: Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the "JNU_" prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for networking, pack200, and have been updated. A jprt run has passed (except for unrelated failures). webrev: http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? They don't require a JNIEnv so I'm wondering if JNU_* really make sense here. -Alan.
RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp
Hello, Please review HTML5 related changes to the above modules, please note there are no changes to the verbiage. Thanks Kumar Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
Re: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp
Hi Daniel, As Jon surmised, this is an ARIA/accessibility requirement, in that one can't have holes in the usage of h* tags, as javadoc tool itself uses h1 and h2, the API docs have to start with h3. With respect to your comment, the h2->h3 is erroneous and have reverted them back, so the only changes wrt. h* are h4 -> h3. New webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.1/ Thanks Kumar Hi Kumar, Looks mostly good. I'm not too sure about the changes from to and to though. Now some of the package.html files in java.naming retain their Package Specification section, and others have it changed to Package Specification. best regards, -- daniel On 10/05/2017 19:57, Kumar Srinivasan wrote: Hello, Please review HTML5 related changes to the above modules, please note there are no changes to the verbiage. Thanks Kumar Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)
Hi Mikael, I may have created solinux when the macosx port was merged and in an effort to reduce the CPP conditionals. solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has Objective-C, MacOSX specific thread initialization etc. I looked over the launcher related code looks ok to me. I did notice the \n endings for the messages that Brent pointed out. Best Kumar Srinivasan On May 6, 2020, at 9:43 PM, Mikael Vidstedt mailto:mikael.vidst...@oracle.com>> wrote: I have always wondered what “solinux” is supposed to mean - though not enough to actually ask anybody :) I’ll file a follow-up enhancement to cover renaming the files. Thank you for the review! Cheers, Mikael On May 4, 2020, at 7:59 AM, Roger Riggs mailto:roger.ri...@oracle.com>> wrote: Hi Michael, Looks good. Maybe just a future cleanup to rename files, since the "...so..." is refering to solaris. src/java.base/unix/native/libjli/java_md_solinux.h src/java.base/unix/native/libjli/java_md_solinux.h Regards, Roger On 5/4/20 4:49 AM, Alan Bateman wrote: On 04/05/2020 06:12, Mikael Vidstedt wrote: Please review this change which implements part of JEP 381: JBS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244224&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=W5VvD1owIGoUcbcRkcwixXGPkFLjHUFof2v6cxMqchk%3D&reserved=0 webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mikael%2Fwebrevs%2F8244224%2Fwebrev.00%2Fcorelibs%2Fopen%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=tQZIjuF5cIPs%2FNqTRtY2WtmwAgwa0iv205wQ9vk0vOQ%3D&reserved=0 JEP: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8241787&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=rDvBE%2BJ2F1IIFC9fbA92rs0KZNgYPg0JZM2ynqp7mcs%3D&reserved=0 Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? ResolverConfigurationImpl.localDomain0 can be removed. The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP". Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. -Alan.
Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v6]
On Thu, 4 Mar 2021 05:16:02 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> added a comment that host has bees set previously > > Thank you. I have no more comment. Shouldn't there be a regression test for this ? If not, IIRC the bug needs to be tagged with noreg-hard or noreg-other ? - PR: https://git.openjdk.java.net/jdk/pull/2583
hg: jdk7/tl/jdk: 6367077: Purge LD_LIBRARY_PATH usage from the launcher; ...
Changeset: de45eac5670e Author:ksrini Date: 2009-11-20 11:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de45eac5670e 6367077: Purge LD_LIBRARY_PATH usage from the launcher 6899834: (launcher) remove the solaris libjvm.so symlink Summary: Fixes other related issues as well. Reviewed-by: darcy, ohair, xlu, martin ! make/java/jli/Makefile ! make/java/main/java/Makefile ! make/java/redist/Makefile ! src/share/bin/java.c ! src/solaris/bin/java_md.c ! test/tools/launcher/Arrrghs.java + test/tools/launcher/ExecutionEnvironment.java - test/tools/launcher/SolarisDataModel.sh - test/tools/launcher/SolarisRunpath.sh ! test/tools/launcher/TestHelper.java - test/tools/launcher/libraryCaller.c - test/tools/launcher/libraryCaller.h - test/tools/launcher/libraryCaller.java
