Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato wrote: >> According to the comments in the makefile >> (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the >> original Markdown file, so if the year is wrong there, it will be wrong in >> the generated nroff file. >> >> I think it would be incorrect to edit the dates locally in these files, >> because they'll just be overwritten when we generate the files again. >> Ideally, the dates should be fixed (if necessary) in the Markdown files, but >> that seems out of scope for this P1. >> >> This is "just" an issue with copyright dates in source files ... and yes, >> while I know copyright dates are important, this problem is arguably part of >> an ongoing more general problem. >> >> I note that the generated files *do* correctly identify themselves with >> `2021` in the visible output generated to the console by the `man` command. > > Thanks for the explanation, Jon. Fine by me. I agree that fixing this date is not necessary at this time. - PR: https://git.openjdk.java.net/jdk17/pull/303
Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
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 mr (Lead). - PR: https://git.openjdk.java.net/jdk17/pull/303
Re: RFR: 8257733: Move module-specific data from make to respective module
2020/12/4 6:08:13 -0800, er...@openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to maintain that document, and >>> I made my best guess at where to place it. >> >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably >> the most suitable home because Java SE specifies JDWP as an optional >> interface. So nothing to do with java.base and the build will need to >> continue to generate the sources for the front-end (jdk.jdi) and >> back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living > documents. In this case, I think it's perfectly valid to update JEP > 201 with additional source code layout. Both for this and for the > other missing dirs. Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of 2014. At this point, and given that we’d already gone beyond JEP 201 prior to this change (with `man` and `lib` subdirectories), what’d make the most sense is a new informational JEP that documents the source-code layout. Informational JEPs can, within reason, be updated over time. - Mark
Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag
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. As the creator of these tags many moons ago, I approve this change. - Marked as reviewed by mr (Lead). PR: https://git.openjdk.java.net/jdk/pull/814
Re: OpenJDK Governing Board CFV: New Serviceability Group Lead: Serguei Spitsyn
2019/3/27 17:21:14 -0700, iris.cl...@oracle.com: >> To: gb-disc...@openjdk.java.net >> Date: Tuesday, March 12, 2019 11:00 PM >> >> Serguei Spitsyn was voted in as the new Lead of the >> Serviceability Group [1]. >> >> Governing Board members: Please vote on whether to ratify this change >> as required by the Bylaws [2]. Votes are due in two weeks, by 23:00 >> UTC on Wednesday, 27 March 2019. Votes must be cast in the open by >> replying to this message. >> >> For Simple Majority voting instructions, see [3]. >> >> Iris >> >> [1] >> https://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021205.html >> [2] https://openjdk.java.net/bylaws#group-lead > > Thank you for your votes. A majority has voted in favor of ratification. > Serguei Spitsyn is now the Lead of the Serviceability Group. So recorded. - Mark
Disallowing the dynamic loading of agents by default
// Moving the general discussion to jigsaw-dev for the record;
// bcc'ing {hotspot-runtime,serviceability}-dev for reference.
Andrew,
Thanks for your feedback on this topic [1][2][3].
First, we apologize for the way in which this topic was raised. Our
intent was to post a proposal for discussion prior to code review, but
unfortunately that review was posted prematurely (as is evident by its
inclusion of Oracle-internal e-mail addresses and URLs).
Second, I agree with your earlier analysis as to the security impact of
this change. If an attack is possible via this vector then closing the
vector would only slow the attack, not prevent it.
The motivation for this change is, however, not merely to improve the
security of the platform but to improve its integrity, which is one of
the principal goals of the entire modularity effort. Integrity has
benefits for security and also for maintainability, of both the JDK
itself and of code that runs upon it, since it makes it clear exactly
which APIs are intended for external use, and which are not.
To improve platform integrity we've strongly encapsulated (most) of the
internal APIs of the JDK. That can be, as we all know, a source of pain
for developers trying to get existing applications to run on JDK 9, so
we've provided workarounds via the encapsulation-busting `--add-opens`
and `--add-exports` command-line options and, recently, the temporary
but more powerful (and verbose) `--permit-illegal-access` option.
There are no API equivalents to these command-line options [4]. That's
intentional: We want developers and deployers using Java out-of-the-box
to be assured that their code is only using APIs actually intended for
external use. They can choose explicitly to expose internal APIs, via
the command line, but then that's a deliberate choice that they make, and
they own the consequences. It's reasonable to allow this via the command
line since we assume that anyone with access to the command line already
has the power to corrupt the JDK in any way they please.
The proposal to disable the loading of dynamic agents by default is one
more part of the overall integrity story. As things stand today, code in
any JAR file can use the `VirtualMachine.loadAgent` API to load an agent
into the JVM in which it's running and, via that agent, break into any
module it likes. Changing the default and providing a new command-line
option, in this case `-XX:+EnableDyanmicAgentLoading`, is consistent with
the other encapsulation-busting options we've introduced. It allows a
developer or deployer to choose to bend, if not violate, the integrity
of the platform, yet also to know that by default the platform is whole.
(Changing this default is also consistent, as Alan has noted, with the
original intent of the `VirtualMachine.loadAgent` API.)
I understand your points about the practical difficulties of having to
educate users about this new option and enhance startup scripts to use
the option only when invoking JDK 9. Isn't it already the case, however,
that migrating existing applications to JDK 9 is often going to require
the use of a few new options anyway, in order to expose internal APIs?
If so then would it really be that much more burdensome for users also
to think explicitly, at the same time, about whether they want to enable
dynamic agent loading?
This change would be disruptive to some but it's the best way we've
found, so far, to preserve platform integrity in the face of dynamic
agent loading. If there's a better way to do that, we'd like to know.
- Mark
[1]
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022948.html
[2]
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022951.html
[3] https://bugs.openjdk.java.net/browse/JDK-8177154
[4] There are limited reflective APIs via which code in a module can
apply some of these operations to just that module, and via which
code that creates a module layer can do so for modules in that
layer, but none of these APIs can break into arbitrary modules.
Re: OpenJDK Governing Board CFV: New Serviceability Group Lead: Staffan Larsen
2016/8/12 17:27:17 -0700, mark.reinh...@oracle.com: > Dan Daugherty recently resigned as the Serviceability Group Lead [1]. > Staffan Larsen was voted in as the new Lead shortly thereafter [2]. > > Governing Board members: Please vote on whether to ratify this change, > as required by the Bylaws [3]. Votes are due in one week, by 01:00 UTC > next Saturday, 20 August 2016. Votes must be cast in the open by > replying to this message. > > For Simple Majority voting instructions, see [4]. Thank you for your votes. A majority has voted in favor of ratification. Staffan Larsen is now the Lead of the Serviceability Group. - Mark
JEP 241: Remove the jhat Tool
New JEP Candidate: http://openjdk.java.net/jeps/241 - Mark
JEP 240: Remove the JVM TI hprof Agent
New JEP Candidate: http://openjdk.java.net/jeps/240 - Mark
JEP 228: Add More Diagnostic Commands
New JEP Candidate: http://openjdk.java.net/jeps/228 - Mark
Re: RFR(XS): 8043264: hsdis library not picked up correctly on expected paths
2014/5/15 6:19 -0700, rednaxel...@gmail.com: > ... > > P.S. I wanted to upload a webrev, but somehow I couldn't get the the > connection to work. Could it be that my publickey is missing on > cr.openjdk.java.net? Your public key was removed when you left Oracle. Now that you work for Azul you're covered by Azul's OCA [1]. Send an updated public key to k...@openjdk.java.net and it will be installed for you. - Mark [1] http://www.oracle.com/technetwork/community/oca-486395.html
Changeset rolled back: jdk8/tl/jdk: 7152892: some jtreg tests fail with permission denied
This changeset was erroneously pushed to jdk8/tl/jdk: Changeset: da4b0962ad11 Author:robm Date: 2014-02-10 14:35 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11 7152892: some jtreg tests fail with permission denied Reviewed-by: coffeys ! test/java/lang/ClassLoader/Assert.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/util/zip/ZipFile/ReadZip.java ! test/sun/net/www/protocol/jar/jarbug/run.sh It has been rolled back on the server and blacklisted in jcheck. If you have a clone of this repository then either strip this changeset or destroy the repository and re-clone it. - Mark
Re: hg: jdk8/tl/jdk: 8027687: The constructors of URLPermission class do not behave as described in javad
2013/11/4 1:49 -0800, michael.x.mcma...@oracle.com: > Changeset: 48449b5390fa > Author:michaelm > Date: 2013-11-04 17:47 + > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa > > 8027687: The constructors of URLPermission class do not behave as described > in javad > Reviewed-by: chegar, mduigou What is "javad"? - Mark
Re: Question of 'contributor' at hg commit
2013/1/24 17:31 -0800, ysr1...@gmail.com: > may be it can't parse two email addresses. Probably expecting a single email > address in contributed by line? It can handle multiple addresses. Try removing the extra space before the first address, i.e., make it: Contributed-by: yunda@taobao.com, yumin...@oracle.com rather than: Contributed-by: yunda@taobao.com, yumin...@oracle.com - Mark
JEP 168: Network Discovery of Manageable Java Processes
Posted: http://openjdk.java.net/jeps/168 - Mark
JEP 167: Event-Based JVM Tracing
Posted: http://openjdk.java.net/jeps/167 - Mark
JEP 159: Enhanced Class Redefinition
Posted: http://openjdk.java.net/jeps/159 - Mark
JEP 158: Unified JVM Logging
Posted: http://openjdk.java.net/jeps/158 - Mark
JEP 137: Diagnostic-Command Framework
Posted: http://openjdk.java.net/jeps/137 - Mark
Re: sun.cpu.isalist
> Date: Wed, 16 Feb 2011 12:33:41 + > From: alan.bate...@oracle.com > ... > > Good sleuthing. It looks like jdk5 was the last release to compile in that > code > on Solaris. This does support the case for removing it. Agreed. - Mark
Re: hg: jdk7/tl/jdk: 6843995: Added RowsetFactory and Deprecate COMMIT_ON_ACCEPT_CHANGES, make constants final that needed to be.
This change was integrated prematurely. I've rolled it back in the jdk7/tl/jdk repository. If you've already pulled it into a local repository then you can remove it using the hg strip command, which is part of the mq extension. Your tip changeset should be: changeset: 1563:5cd12b68d09b user:alanb date:Thu Aug 20 08:48:29 2009 +0100 summary: 6866804: (file) Path calls checkPermission insteadof checkXXX (sol) - Mark
