On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main c
On Fri, 6 Sep 2024 13:16:34 GMT, Kevin Rushforth wrote:
>> Looks good. I'll review the CSR when its ready.
>
>> Looks good. I'll review the CSR when its ready.
>
> Thanks.
>
>> The changes to make jdk.jsobject an upgradeable module looks right.
>
> Thanks for checking. My testing primarily foc
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote:
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will include the module
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in clang, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wal
On Fri, 23 Aug 2024 10:04:42 GMT, Magnus Ihse Bursie wrote:
> But, if you look at the actual functions that are affected, you can see that
> it is just a handful of calls that are all done at startup time.
That is true for now but there 30-50 other places that will need attention once
this ef
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
P
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end use
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore
wrote:
> I don't fully agree that this option is not module related (which is why I
> gave it that name). The very definition of illegal native access is related
> to native access occurring from a module that is outside a specific set. So
On Wed, 15 May 2024 00:54:43 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/arguments.cpp line 2271:
>>
>>> 2269: } else if (match_option(option, "--illegal-native-access=",
>>> &tail)) {
>>> 2270: if (!create_module_property("jdk.module.illegal.native.access",
>>> tail, Inter
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Sun, 18 Feb 2024 14:56:03 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to ProblemList a couple of tests:
> [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList
> serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
> in Xcomp mode
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a
On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote:
> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
> cleanup has been proposed before (and was done in the change). But there are
> a number of other places in the codebase where the import is done and still
> th
On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race wrote:
> Many printing tests do not have the @printer keyword. This adds them to those
> that need it.
> I also found one test that has nothing to do with printing in the print
> folder and moved it out.
test/jdk/TEST.ROOT line 15:
> 13: #
> 14: # N
On Tue, 12 Sep 2023 08:26:59 GMT, Matthias Baesken wrote:
> So could we remove the existing PrivilegedAction in getCompilerName ?
Wouldn't that break ManagementFactory.getCompilationMXBean?
-
PR Comment: https://git.openjdk.org/jdk/pull/15629#issuecomment-1715570499
On Fri, 8 Sep 2023 10:58:23 GMT, Matthias Baesken wrote:
> So probably we could avoid changing VMManagementImpl.java because it is not
> needed any more at least in jdk-head .
It's a JDK internal class so should never have been used directly. I can't
imagine what might be using a JDK internal
On Fri, 8 Sep 2023 08:26:16 GMT, Matthias Baesken wrote:
> There are some remaining places in 'general' JDK code (= code not related to
> e.g. a specific tool) getting properties like :
>
> osName = System.getProperty(os.name)
>
> https://github.com/openjdk/jdk/blob/master/src/java.management/
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should re
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test th
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote:
> I wouldn't be opposed to a change that:
>
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes `cr
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
> check
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> Th
On Wed, 2 Aug 2023 23:55:24 GMT, Sergey Bylokhov wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8248e351](https://github.com/openjdk/jdk/commit/8248e351d0bed263fb68d8468004a4286e6391af)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit b
On Wed, 19 Jul 2023 07:05:45 GMT, Jaikiran Pai wrote:
> I had initially considered that but had noticed that there's a small
> difference between the generic warning message "Warning: %s option is
> deprecated and may be removed in a future release." printed by the launcher
> and the one print
On Wed, 19 Jul 2023 07:05:51 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal the `-Xdebug` option and `-debug` option of the `java` command?
>> This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>>
>> As noted in the JBS
On Wed, 19 Jul 2023 07:07:40 GMT, Jaikiran Pai wrote:
> I would like inputs on the
> test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java test. That test
> launches java passing it the -Xdebug option and was introduced as part of
> https://bugs.openjdk.org/browse/JDK-6294277. -Xdebug h
On Tue, 18 Jul 2023 12:41:32 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal the `-Xdebug` option and `-debug` option of the `java` command?
>> This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>>
>> As noted in the JBS
On Tue, 18 Jul 2023 07:58:58 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal the `-Xdebug` option and `-debug` option of the `java` command?
>> This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>>
>> As noted in the JBS
On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal the `-Xdebug` option of the `java` command? This addresses
> https://bugs.openjdk.org/browse/JDK-8312151?
>
> As noted in the JBS issue this option is cur
On Fri, 30 Jun 2023 09:57:04 GMT, Matthias Baesken wrote:
> Hi Alan, I adjusted the comment in DriverManager.java .
Thanks, the update looks okay.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1257728322
On Wed, 28 Jun 2023 12:54:10 GMT, Matthias Baesken wrote:
> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is
> declared in module java.base, which does not export it to module java.sql' Is
> there any concern to export it as well to module java.sql ? And btw did you
> m
On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken wrote:
> There are a few references to rt.jar in comments and in the codebase itself.
> Some of them might be removed or adjusted.
src/java.sql/share/classes/java/sql/DriverManager.java line 658:
> 656: * (which is invoking this class
On Mon, 19 Jun 2023 07:06:00 GMT, Axel Boldt-Christmas
wrote:
> > Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so
> > you might want to fix the PR description.
>
> What part are you worried about? When would `vm.gc.ZSingelgen` be invalid?
>
> Also what part of the PR
On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
On Thu, 8 Jun 2023 11:27:37 GMT, Pavel Rappo wrote:
> If we were to (re-)structure doc comments in the way you propose, I'd suggest
> we do it in a separate, non-jdk.javadoc PR. I was simply trying to keep JDK
> API documentation unchanged.
Understood, it was just a passing comment that TreeMa
On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Mon, 15 May 2023 17:41:18 GMT, Jiangli Zhou wrote:
> Remove DEF_STATIC_JNI_OnLoad from
> src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c.
> src/java.desktop/share/native/libjsound/Platform.c defines
> DEF_STATIC_JNI_OnLoad for libjsound.
Probably should wait
On Thu, 4 May 2023 19:32:45 GMT, Jiangli Zhou wrote:
>>> [...] I'll see if I can test this on a mandrel build tomorrow...
>>
>> @jianglizhou So I've tested this with a mandrel build and it doesn't break
>> terribly, but a graalvm build after this patch has *two* `libjvm.a` which a)
>> doesn't
On Sun, 30 Apr 2023 18:53:40 GMT, Jorn Vernee wrote:
> It seems that letting jlink do the linking is also a requirement for user
> provided modules (.jmods) that contain native libraries (as is the case for
> instance with jextract). We don't know about those libraries when building
> the JDK.
On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson wrote:
> The build is already capable of producing .a files and this patch is building
> on top of that build feature. The current .a file creation is used by the
> downstream graal build which needs it for nativeimage.
Also builds on recent chan
On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou wrote:
> Initial implementation for supporting building a fully statically linked
> (with a desired set of JDK native libraries and libjvm) Java launcher
> executable, which is named as 'javastatic'.
>
> In this PR, the support is only added for t
On Thu, 27 Apr 2023 00:12:58 GMT, Jiangli Zhou wrote:
> Resolve misc symbol issues observed when statically linking JDK/VM natives
> with the standard Java launcher executable. Use the same approaches adopted
> by earlier fixes for static linking related symbol problems (e.g.
> JDK-8306033):
>
On Fri, 7 Apr 2023 06:33:08 GMT, Thomas Stuefe wrote:
> What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We
> also have PPC big-endian, it is used by AIX (and you can also run Linux with
> PPC big-endian). Why omit that?
>
> os.arch for AIX is "ppc64".
So I think you ar
On Fri, 7 Apr 2023 06:26:18 GMT, Eirik Bjorsnos wrote:
> Thanks, but it seems Alan did not actually approve anything, he simply left
> an infomational note.
>
> We still only have the approval from Sergey, and it is still not clear what
> he approved.
Right, I just added a note as I remember
On Thu, 6 Apr 2023 19:01:39 GMT, Roger Riggs wrote:
> Removed.
Good, that makes it simpler and it means the qualified export can be removed
too.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160162760
On Thu, 6 Apr 2023 17:17:35 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Mon, 20 Mar 2023 11:24:12 GMT, Eirik Bjorsnos wrote:
>> Please review this PR which suggests we remove the orhphaned `SwingApplet`
>> netbeans project directory.
>>
>> The `SwingApplet` demo was removed in
>> [JDK-8205119](https://bugs.openjdk.org/browse/JDK-8205119), but the netbeans
>> p
On Thu, 2 Feb 2023 19:29:05 GMT, Per Minborg wrote:
>> This PR suggests improving performance by using the newly introduced class
>> `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>>
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for
>> littl
On Tue, 17 Jan 2023 20:51:36 GMT, Phil Race wrote:
> Maybe core libs could add such a test.
It is tested by conformance tests but a test could be added to the OpenJDK
jtreg tests if needed.
-
PR: https://git.openjdk.org/jdk/pull/11559
On Tue, 17 Jan 2023 13:33:06 GMT, Kevin Rushforth wrote:
>> Hi all,
>>
>> Please review the fix for the build failure with clang-15.
>>
>> 1. -Wbitwise-instead-of-logical
>>
>>1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the
>> warning
>>2) src/hotspot/share/runtim
On Mon, 16 Jan 2023 08:56:13 GMT, Jie Fu wrote:
> Mainly caused by files under `src/java.base/share/native/libzip/zlib/`. I'm
> not sure if there is already a bug report to the upstream.
Maybe this one:
https://github.com/madler/zlib/issues/633
-
PR: https://git.openjdk.org/jdk/pu
On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote:
> It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
Is there a list of the issues building libjli? I don't see the in the PR or the
JBS issue. For the libzip issues, are these in the native methods or when
compiling the zlib code, ju
On Fri, 6 Jan 2023 23:08:27 GMT, Archie L. Cobbs wrote:
> I've moved the `@SuppressWarnings` annotations onto a new branch
> `ThisEscapeAnnotations`. This is just for future reference in case somebody
> wants to add them back someday and doesn't want to start from scratch.
>
> > I suspect some
On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs wrote:
> Sounds reasonable... so I take it you would also be in favor of patching
> `make/modules` instead of adding `@SuppressWarnings` annotations
> everywhere... is that correct?
>
> If this is generally agreed as a better route then let me k
On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote:
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated f
On Thu, 22 Dec 2022 10:57:15 GMT, Alexander Scherbatiy
wrote:
>> **Environment**:
>> GraalVM 22.3.0 with jdk 19, Windows OS.
>>
>> **Description**:
>> Create a native image of Swing application using GraalVM and run it with `
>> -Dsun.awt.fontconfig=fontconfig.properties.src` java property.
On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen wrote:
>> Damon Nguyen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert old translation. Fix lang codes
>
> @dfuch Could I get a review from you as well? I believe this translation
>
On Mon, 5 Dec 2022 10:47:36 GMT, Jayathirth D V wrote:
> Noticed SCCS jtreg id's in 2 open awt tests. After jtreg 7.1 update, jtreg
> doesn't parse SCCS id's and it causes the tests with SCCS id's to fail.
>
> As of now these 2 tests are ignored, but it is good to remove these SCCS id's.
> If w
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote:
>> Please review a "somewhat automated" change to insert `@spec` tags into doc
>> comments, as appropriate, to leverage the recent new javadoc feature to
>> generate a new page listing the references to all external specifications
>> li
On Sun, 20 Nov 2022 14:59:12 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/11252
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote:
> When referencing an RFC, it might be good to keep the RFC number in the text
> link. For instance I see that java.net.URL now has this:
I agree and also to add that some RFCs have commas in their titles, the same
separator used when there
On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism define
On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs wrote:
>> To be discussed: I actually wanted the deprecation link ( the link from
>> `@deprecated` ) to lead here because I find that the whole section is
>> relevant for developers who might want to decide whether to actually move
>> away from usi
On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote:
> You have jumped through some refactoring hoops to be able to apply the
> deprecation suppression to as little code as possible .. having made such
> changes, then why didn't you just make the recommended change instead ?
>
> Should I presume
On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism defin
On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote:
> This is a continuation of the effort to update all our URLs to the new
> top-level domain.
>
> This patch updates (most) URLs in testing code. There still exists references
> to openjdk.java.net, but that are not strictly used as no
On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote:
>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains six commits:
>
> - Reinstate t
On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo wrote:
>> This adds exception documentation to JDK methods that would otherwise lose
>> that documentation once JDK-8287796 is integrated. While adding this
>> exception documentation now does not change [^1] the JDK API Documentation,
>> it will a
On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote:
> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
src/java.base/share/native/libzip/zlib/zlib.h line 756:
> 754:If this is done, the old level and strategy will be applied to the
> data
> 755:compressed
On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote:
> Now that Thread.stop has been degraded to throw
> `UnsupportedOperationException` (JDK-8299610) the only direct source of async
> exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread`
> code, remove the `stillborn` fie
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecate
On Thu, 22 Sep 2022 04:36:08 GMT, Joe Darcy wrote:
> Consider using an implSpec tag here.
implSpec is usually for default methods or overrideable methods. In this case,
Thread.stop is final so code that extends Thread can't override and change the
behavior. So it's not clear to me that implSpe
On Wed, 21 Sep 2022 06:43:50 GMT, David Holmes wrote:
> Okay I will defer to your views here. Thanks.
Thank you, I'll get the CSR moving again and we'll try to get this done.
-
PR: https://git.openjdk.org/jdk/pull/10230
On Tue, 20 Sep 2022 04:21:39 GMT, David Holmes wrote:
>> Alan Bateman 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 12 addi
might be done when
> simulating code throwing an exception at some point in the code.
Alan Bateman 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
might be done when
> simulating code throwing an exception at some point in the code.
Alan Bateman 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
On Wed, 14 Sep 2022 14:21:09 GMT, Jaikiran Pai wrote:
> The changes to the `core-libs` look fine to me. There are some test security
> policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy`
> which use the `stopThread` `RuntimePermission` which no longer exists. Should
> th
On Tue, 13 Sep 2022 14:03:52 GMT, Roger Riggs wrote:
> fold with previous line.
Done.
-
PR: https://git.openjdk.org/jdk/pull/10230
On Tue, 13 Sep 2022 23:51:03 GMT, Mandy Chung wrote:
> The change looks good. There are other tests that reference `ThreadDeath` for
> example `test/lib/jdk/test/lib/process/ProcessTools.java`,
> `test/jdk/java/util/Timer/KillThread.java` ,
> `test/jdk/java/net/httpclient/reactivestreams-tck/o
might be done when
> simulating code throwing an exception at some point in the code.
Alan Bateman 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
On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan wrote:
> What about also removing and undocumenting `RuntimePermission("stopThread")`
> as part of this change?
Ah yes, the table RuntimePermission can be updated as part of this (and the
corresponding constant in sun/security/util/SecurityConstant
On Tue, 13 Sep 2022 19:06:14 GMT, Erik Österlund wrote:
> There is a bunch of VM code for this too. Should we clean that up separately?
Yes chatted with @dholmes-ora about this recently and he suggested separating
out so there is a follow-on JBS issue created for that. Aside from
JVM_StopThrea
Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
removal, and remove the remaining special handling of ThreadDeath from the JDK.
Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998)
with a link to a supplementary page that explains the rational
On Mon, 15 Aug 2022 07:14:36 GMT, Iris Clark wrote:
>> Since it is internal API I think that unnecessarily generous.
>> It shouldn't be called anyway.
>
> Sounds reasonable.
Maybe in time it can be removed, which removes the temptation to use it
completely.
-
PR: https://git.openj
On Fri, 12 Aug 2022 20:14:27 GMT, Phil Race wrote:
> Thread.stop() and ThreadGroup.destroy() are called by
> sun.awt.AppContext.dispose()
>
> These should no longer be called. Both are deprecated for removal.
> ThreadGroup.destroy() does nothing. Thread.stop() throws
> UnsupportedOperationExce
On Wed, 3 Aug 2022 05:59:34 GMT, Alan Bateman wrote:
>>> One other comment on this is that the proposed change should mean that the
>>> tests no longer need to run with --enable-preview.
>>
>> You've lost me all over again.
>> Why did these two tests n
On Fri, 5 Aug 2022 02:25:11 GMT, Ao Qi wrote:
>> The issue comes from
>> https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357.
>>
>> If Loom is not supported, two XMLDecoder tests would fail. The issue could
>> be reproduced by zero, for example:
>>
>>
>> ---
1 - 100 of 107 matches
Mail list logo
