On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to
On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev wrote:
> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot
> of x86_32 code. The x86_32 porting is done under
> [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile,
> we can problemlist the
On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> I tried to avoid changing external libraries, there are quite a few such
> typos.
> Let me know if I should revert any files.
Marked
On Thu, 12 May 2022 00:26:41 GMT, Yasumasa Suenaga wrote:
>> I don't understand what the actual warning is getting at .. can anyone
>> explain it ?
>>
>> FWIW the code is still the same in upstream harfbuzz
>> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc
>
> I've pasted a part
On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>>
On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>>
On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Avoid pragma error in before GCC 12
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462:
>
>> 460:
On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote:
>> Method `Class.isAssignableFrom` is often used in form of:
>>
>> if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>>
>> if (clazz.isInstance(obj)) {
>>
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>>
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote:
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand
On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote:
> JDK-6725221 Standardize obtaining boolean properties with defaults
I did wonder why it has security-libs as the sub-category and if the intent was
not what we see here.
-
PR: https://git.openjdk.java.net/jdk/pull/8559
On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote:
> JDK-6725221 Standardize obtaining boolean properties with defaults
The xtoolkit change is fine. I've not looked at anything else
You'll clearly need multiple reviewers for this one.
-
Marked as reviewed by prr (Reviewer).
PR:
On Thu, 28 Apr 2022 01:31:13 GMT, Joe Darcy wrote:
>> To enable more complete doclint checking (courtesy @jonathan-gibbons),
>> please review this PR to add type-level @param tags where they are missing.
>>
>> To the maintainers of java.util.concurrent, those changes could be separated
>> out
On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote:
> Currently we set _WIN32_WINNT at various places in the codebase; this is used
> to target a minimum Windows version we want to support. See also for more
> detailled information :
>
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
>
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote:
> Please review this small patch that fixes a potential memory leak that
> exception return fails to release allocated `cacheDirs`
>
> Test:
>
> - [x] jdk_desktop on Linux x86_64
I've increased the number of reviewers because as well as the
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
Marked as reviewed by prr (Reviewer).
Looks like there's only one client source code file touched
Most of the client changes
On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote:
> Method `Class.isAssignableFrom` is often used in form of:
>
> if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
>
> if (clazz.isInstance(obj)) {
>
>
On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian wrote:
>> Here are the code changes for the "Deprecate finalizers in the standard Java
>> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
>> review.
>>
>> This change makes the indicated deprecations, and updates the API
On Mon, 29 Nov 2021 08:18:47 GMT, Сергей Цыпанов wrote:
>> Instead of something like
>>
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>>
>> we can use `return Long.compare(x, y);`
>>
>> All replacements are done with IDE.
>
> Сергей Цыпанов has updated the pull request
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Thu, 28 Oct 2021 09:29:13 GMT, Masanori Yano wrote:
> Could you please review the 8262297 bug fixes?
>
> In this case, ImageIO.write() should throw java.io.IOException rather than
> java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and
> wrapped in IIOException in
On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race wrote:
> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
>
> The jtreg javax.sound tests are written in such a way that if a needed audio
> device
> or other platform resource is not
This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
The jtreg javax.sound tests are written in such a way that if a needed audio
device
or other platform resource is not available, they just exit with a "pass" for
the test.
It is as if headful tests just swallowed
On Mon, 27 Sep 2021 20:56:28 GMT, Phil Race wrote:
> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
> the name of the application in the system menu bar.
>
> Because this set shortly after the VM is running, it causes a thread safety
> issue des
On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>
stem property which is visible to apps as well but it seems a
> reasonable trade-off since we already (implicitly) support this variable
> anyway in preference to the env. var.
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8274397
On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>
stem property which is visible to apps as well but it seems a
> reasonable trade-off since we already (implicitly) support this variable
> anyway in preference to the env. var.
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8274397
On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>
On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>
stem property which is visible to apps as well but it seems a
> reasonable trade-off since we already (implicitly) support this variable
> anyway in preference to the env. var.
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8274397
On Wed, 29 Sep 2021 01:46:32 GMT, Sergey Bylokhov wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8274397: [macOS] Stop setting env. var JAVA_MAIN_CLASS_ in launcher
>> code
>
>
stem property which is visible to apps as well but it seems a
> reasonable trade-off since we already (implicitly) support this variable
> anyway in preference to the env. var.
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
827
macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set the
name of the application in the system menu bar.
Because this set shortly after the VM is running, it causes a thread safety
issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
Since the AWT already looks
On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote:
> This is a GUI test, and it should be `@headful`.
>
> Additional testing:
> - [x] Test still runs in default, and does not run with `!headful`
Well .. since our test framework doesn't run whatever test group this is in on
headful
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin and webstart are no longer supported and
>
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin and webstart are no longer supported and
>
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin and webstart are no longer supported and
>
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin and webstart are no longer supported and
>
On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>>
On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Component.java line 630:
>>
>>> 628: }
>>> 629:
>>> 630: @SuppressWarnings("removal")
>>
>> I'm confused. I thought the reason this wasn't done in the JEP
>> implementation PR is
On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>>
On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote:
>> Please review the test changes for [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> With JEP 411 and the default value of `-Djava.security.manager` becoming
>> `disallow`, tests calling `System.setSecurityManager()` need
>>
On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote:
>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class
> level is introducing technical debt but if addressing that requires
> refactoring and
On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote:
>> By converting JDK-8267432 to a bug, there is an extra benefit that we can
>> fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged
On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote:
>> I can make it a bug.
>>
>> I don't want to do it here is because it involves indefinite amount of
>> manual work and we will see everyone having their preferences. The more time
>> we spend on this PR the more likely there will be merge
On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote:
>> I don't think it is a separate P4 enhancement (?) that someone will (maybe)
>> do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target
On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote:
>> That's a sad limitation of the annotation stuff then, but I don't think that
>> it is insurmountable.
>> You can define a static private method to contain this and call it from the
>> static initializer block.
>> Much better than applying
On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>>
>>> 215: * @author Sami Shaio
>>> 216: */
>>> 217: @SuppressWarnings("removal")
>>
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Thu, 22 Apr 2021 20:59:22 GMT, Phil Race wrote:
> Delete some duplicates
This pull request has now been integrated.
Changeset: b84f6901
Author: Phil Race
URL: https://git.openjdk.java.net/jdk/commit/b84f6901
Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
8265
Delete some duplicates
-
Commit messages:
- 8265793: Remove duplicate jtreg TEST.groups references for some client tests
Changes: https://git.openjdk.java.net/jdk/pull/3642/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3642=00
Issue:
On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick wrote:
>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
>
On Sun, 14 Mar 2021 19:35:25 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Thu, 4 Feb 2021 02:32:31 GMT, Phil Race wrote:
> remove un-needed disabling now JNF has gone ..
This pull request has now been integrated.
Changeset: 3bb6a3d2
Author: Phil Race
URL: https://git.openjdk.java.net/jdk/commit/3bb6a3d2
Stats: 8 lines in 2 files changed: 0 ins
On Thu, 4 Feb 2021 11:42:48 GMT, Magnus Ihse Bursie wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove condition that should have been fixed as part of 8257858
>
> Marked as review
> remove un-needed disabling now JNF has gone ..
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
Remove condition that should have been fixed as part of 8257858
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Fri, 29 Jan 2021 22:47:52 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>>
On Fri, 29 Jan 2021 21:47:32 GMT, Weijun Wang wrote:
>> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619:
>>
>>> 617: (*env)->ReleaseCharArrayElements(env, passwordObj,
>>> passwordChars,
>>> 618: JNI_ABORT);
>>> 619: }
>>
>> Although you
On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk wrote:
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++
On Fri, 29 Jan 2021 14:57:56 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>>
On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race wrote:
>> that sounds good to me, I am just afraid to break intel mac on older macos
>> versions with this change.
>
> That may actually be a valid concern. Both say macOS 10.12+ ... which might
> conflict with the 10.9 targ
On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik wrote:
>> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
>> 2) So maybe rather than the deprecation suppression you could change both
>> constants to the new ones.
>> Ordinarily I'd say let someone else do that but
On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik wrote:
>> Are you doing something somewhere to change the target version of macOS or
>> SDK ? I had no such problem.
>> I think we currently target a macOS 10.9 and if you are changing that it
>> would need discussion.
>> If you are changing it
On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik wrote:
>> Hello
>> I believe it was a workaround for issues with xcode 12.2 in early beta days.
>> Those issues were fixed later in upstream jdk, so most likely we need to
>> remove these workarounds.
>
> It seems these workarounds are still
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty
wrote:
> ProblemList two java/rmi/Naming tests on Windows in order to reduce the
> noise in the JDK16 CI. This is a trivial fix.
overdue
-
Marked as reviewed by prr (Reviewer).
PR: https://git.openjdk.java.net/jdk16/pull/58
On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov
wrote:
>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged
>> into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need
>> to be careful with the changes here as it will likely causing build
On Wed, 9 Dec 2020 18:58:54 GMT, Andy Herrick wrote:
> Same code change as https://github.com/openjdk/jdk/pull/1676 that got messed
> up with merge
Marked as reviewed by prr (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1720
On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote:
>> Surely these days you can just call [NSProcessInfo operatingSystemVersion]
>> directly ?
>> If I read the doc below it is in the 10.10 SDK and later.
>>
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote:
> Please review a small change that replaces use of objc_msgSend_stret in macOS
> platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64
> support, where objc_msgSend_stret is not available.
Surely these days you can
On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter
wrote:
> In result of Javadoc to do not use java.io.File.toURL()
> Change use java.io.File.toURL().toURI() instead.
You reference a desktop bug that discusses many, many deprecations
and skara has identified
On Sat, 31 Oct 2020 16:10:23 GMT, Kevin Rushforth wrote:
>> This will cause a regression in behavior. It will break existing JavaFX
>> applications that do not have a main program. It could also break
>> applications that create or use certain JavaFX objects in the class
>> initializer of
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
>
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote:
>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote:
> This issue relates to JDK-8250639 '☂ Address reliance on default constructors
> in the java.desktop module'. The
> following classes have had an explicit no-arg constructor added, with a
> protected access modifier and accompanying API
>
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).
1) This is un-necessary churn.
2) I
Only back to 11 and client support ended before that.
-Phil.
> On Aug 13, 2020, at 7:58 PM, Alexey Semenyuk
> wrote:
>
> Phil,
>
> jpackage can be used to bundle apps with older JREs. Do you think it doesn't
> make sense for this check given this?
>
> - Alexey
>
>> On 8/13/2020 6:03 PM,
I am not sure what the right mailing list(s) are for this change.
It definitely isn't a core-libs change. I think build-dev may be better.
I am also unclear when this failure handler is invoked and how all this
machinery works.
It is only useful for headful tests and so I'd only want it
testForPresenseOnly It should be spelt testForPresenceOnly -phil.
On 12/13/19 6:16 AM, Andy Herrick wrote:
I approve these changes.
My first thought was that, if reading output only after Process is
complete is valid and safe, then why not do it that way all the time
? But comment in
ok. all good.
-phil
On 12/11/19 12:14 PM, Alexey Semenyuk wrote:
Yes, I did a test build.
- Alexey
On 12/11/2019 1:48 PM, Phil Race wrote:
Looks OK. I presume you did a test build in our build system ?
-phil
On 12/11/19 10:46 AM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage
+1
-phil
On 12/11/19 11:43 AM, Andy Herrick wrote:
sorry - fix is at:
[3] http://cr.openjdk.java.net/~herrick/8235788/webrev.01/
/Andy
On 12/11/2019 2:42 PM, Andy Herrick wrote:
Please review fix [1] for issue [2]
This is backing out the fix to JDK-8235252 so I can re-push it with
the
Looks OK. I presume you did a test build in our build system ?
-phil
On 12/11/19 10:46 AM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
- adds $(X_CFLAGS) to compiler command line.
Patch contributed by Arthur Eubanks (aeuba...@google.com).
- Alexey
[1]
+1
-Phil.
> On Dec 9, 2019, at 2:36 PM, Alexander Matveev
> wrote:
>
> Looks good.
>
> Thanks,
> Alexander
>
>> On 12/9/2019 1:42 PM, Andy Herrick wrote:
>> Please review simple fix [2] for jpackage bug [1]
>>
>> fixing error message for mutually exclusive options.
>>
>> /Andy
>>
>> [1]
> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
This does not bring up the expected webrev
-phil.
On 12/9/19 3:17 PM, Andy Herrick wrote:
Please review simple jpackage fir for issue [1] at [2]
/Andy
[1] https://bugs.openjdk.java.net/browse/JDK-8235601
[2]
doesn’t have module A,
hence it should be sufficient. If it’s not, we have a bug in jtreg.
— Igor
On Dec 7, 2019, at 1:43 PM, Phil Race wrote:
All these tests specify this already so it doesn’t seem sufficient.
-Phil.
On Dec 7, 2019, at 12:07 PM, Igor Ignatyev wrote:
can we just add '@modules
for now. So +1
>>
>> -phil.
>>
>>> On 12/7/19, 5:48 AM, Andy Herrick wrote:
>>> Phil - are you approving this change ? - I think you are the only
>>> registered Reviewer.
>>>
>>> /Andy
>>>
>>>> On 12/6/2019 8:
Well we could deprecate and remove the solaris port :-)
But until that is done this is the only way I know of.
we could require all jpackage tests to include some helper code which decides
if it is applicable but that will be more work upfront and many jpackage tests
are already platform
On 12/6/19 12:51 PM, Alexey Semenyuk wrote:
On 12/5/2019 8:44 PM, Alexander Matveev wrote:
Hi Alexey,
1) Remove this file:
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.rej
Done. webrev updated in place.
2) Agree with Phil, they probably should be pushed as two
1 - 100 of 209 matches
Mail list logo
