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, P
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 can't
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
> d
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 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
> AtomicInteg
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 thei
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 https://bugs.openjdk.java.net/browse
Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just
delete the unused code and comment.
Dilemma - since at 1036 we are throwing an Exception and the comment at 970-ish
suggests
the author was intending to do what s/he did at 1036 but never got around to it.
I think I'd
oh well ... in which I suppose this is the best you can do here.
-phil.
On 7/12/19 1:10 PM, Brian Burkhalter wrote:
(2) I don't know why at 1034 you changed from PrinterIOException to
PrinterException.
There is no PrinterIOException constructor which accepts a String as
its only parameter
Please remove “investigate” from the synopsis. Everywhere.
-Phil.
> On Oct 2, 2019, at 7:48 PM, Alexey Semenyuk
> wrote:
>
> Looks good.
>
> - Alexey
>
>> On 10/2/2019 9:54 PM, Alexander Matveev wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-820
Submit a bug for tools/jpackage.
Assuming this is just a missed copy it should be easy to fix.
-phil.
On 11/15/19 5:30 AM, Michael Paus wrote:
Hi,
I am trying to customize a DMG built with jpackage.
I have therefore placed two images into the configured resource folder.
myApp-background.png
my
Andy,
I am puzzled by what I see here
> The webrev at [3] shows the changes since EA-06 (Build
13-jpackage+1-49 ) up to the current point.
> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/
This includes the JNLPConverter which isn't what I expected to see and
(correctly) isn't i
ce EA-5.
/Andy
On 11/26/2019 4:53 PM, Phil Race wrote:
Andy,
I am puzzled by what I see here
> The webrev at [3] shows the changes since EA-06 (Build
13-jpackage+1-49 ) up to the current point.
> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/
This includes the JNL
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 separat
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 specifi
ith me at least 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
>>>
>>>>
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 '@mo
> [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] http://cr.openjdk.java
+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] h
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 ([email protected]).
- Alexey
[1] https://bugs.ope
+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 rig
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
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 Pro
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 enable
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 j
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.
>> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsys
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 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 breakag
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 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 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 the
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 the
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 need
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 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 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 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
>> libosxkrb5/SCDynamicStoreConfig.m](https://
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++ cod
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 h
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
>> libosxkrb5/SCDynamicStoreConfig.m](https://
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 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 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 the
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 readi
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
> bro
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&pr=3642&range=00
Issue: https://bugs.openjdk.java.
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
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
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 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 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 i
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 c
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 acknowledege
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 re-t
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
>> `-Djav
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
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
>> with
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 be
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
>> with
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
> remo
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
> remo
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
> remo
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
> remo
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 syst
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 f
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:
827439
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:
8274397
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
>
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
>
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 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
>
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
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 Headl
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 availab
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 Ima
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 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 inc
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 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)) {
>
> Repl
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 a
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 c
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 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 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 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 :
> https://docs.microsoft.com/en-us/windows/win32/winpro
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 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: h
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 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 o
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 :
>> https://docs.microsoft.com/en-us/windows/win32/win
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, 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:HAR
1 - 100 of 217 matches
Mail list logo
