RFR: 8296905: Replace the native LCMS#getProfileID() method with the accessor
The native method used to access the private method in the `ICC_Profile` class is replaced by the accessor. - Commit messages: - 8296905: Replace the native LCMS#getProfileID() method with the accessor Changes: https://git.openjdk.org/jdk/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296905 Stats: 77 lines in 5 files changed: 38 ins; 36 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/6.diff Fetch: git fetch https://git.openjdk.org/jdk pull/6/head:pull/6 PR: https://git.openjdk.org/jdk/pull/6
Re: RFR: 8271846 a11y API lacks setSelectedIndex method [v4]
On Fri, 11 Nov 2022 09:12:21 GMT, Artem Semenov wrote: >> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line >> 574: >> >>> 572: return; >>> 573: } >>> 574: as.addAccessibleSelection(i); >> >> I would like to clarify one initial question. Why we cannot use >> `clearAccessibleSelection `to clean the current selection and then add a new >> one by the `addAccessibleSelection`? > > We tried to do this, it leads to an endless repetition of the selected line > until it freezes. Probably because of the endless notifications loop? implementation of addSelectionInterval looks similar to setSelectionInterval. In some cases the addSelectionInterval just call setSelectionInterval. - PR: https://git.openjdk.org/jdk/pull/8578
Re: RFR: 8296083: javax/swing/JTree/6263446/bug6263446.java fails intermittently on a VM
On Fri, 11 Nov 2022 04:01:17 GMT, Prasanta Sadhukhan wrote: >> Please recheck, setLocationRelativeTo() calculates the location based on the >> size of the current frame, which is wrong before the pack. I just run it and >> the frame is sifted to the right part of the screen. > > WHich platform it is shifted? I guess on any, I have tested on windows, and now on macOS. Add these lines to the end of method, and check how the frame will jump to the center: frame.setLocationRelativeTo(null); frame.pack(); frame.setVisible(true); + robot.delay(3000); + frame.dispose(); + frame.pack(); + frame.setLocationRelativeTo(null); + frame.setVisible(true); - PR: https://git.openjdk.org/jdk/pull/11057
Re: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4]
On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following >> assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys >> such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got >> all pass. > > ravi gupta has updated the pull request incrementally with one additional > commit since the last revision: > > 8296632: Review fixes. test/jdk/java/awt/event/ComponentEvent/TextAreaTextEventTest.java line 2: > 1: /* > 2: * Copyright (c) 2007, 2022, Oracle and/or its affiliates. All rights > reserved. Since this is a new test we dn't need 2007. - PR: https://git.openjdk.org/jdk/pull/11052
Re: RFR: 8296546: Add @spec tags to API
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 in the `@spec` tags.
>
> "Somewhat automated" means that I wrote and used a temporary utility to scan
> doc comments looking for HTML links to selected sites, such as `ietf.org`,
> `unicode.org`, `w3.org`. These links may be in the main description of a doc
> comment, or in `@see` tags. For each link, the URL is examined, and
> "normalized", and inserted into the doc comment with a new `@spec` tag,
> giving the link and tile for the spec.
>
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec
> site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where
> both are available (this mostly applies to IETF specs)
>
> In addition, a "standard" title is determined for all specs, determined
> either from the content of the (main) spec page or from site index pages.
>
> The net effect is (or should be) that **all** the changes are to just **add**
> new `@spec` tags, based on the links found in each doc comment. There should
> be no other changes to the doc comments, or to the implementation of any
> classes and interfaces.
>
> That being said, the utility I wrote does have additional abilities, to
> update the links that it finds (e.g. changing to use `https:` etc,) but those
> features are _not_ being used here, but could be used in followup PRs if
> component teams so desired. I did notice while working on this overall
> feature that many of our links do point to "outdated" pages, some with
> eye-catching notices declaring that the spec has been superseded. Determining
> how, when and where to update such links is beyond the scope of this PR.
>
> Going forward, it is to be hoped that component teams will maintain the
> underlying links, and the URLs in `@spec` tags, such that if references to
> external specifications are updated, this will include updating the `@spec`
> tags.
>
> To see the effect of all these new `@spec` tags, see
> http://cr.openjdk.java.net/~jjg/8296546/api.00/
>
> In particular, see the new [External
> Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html)
> page, which you can also find via the new link near the top of the
> [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html)
> pages.
Hi Jon,
I only looked at the jar specific updates but there is some duplication
leftovers.
It would probably be easier for the reviewers and for you if the PR could be
broken out by areas into separate PRs
src/java.base/share/classes/java/util/jar/Attributes.java line 58:
> 56: * order that keys were inserted into the map, as with {@link
> LinkedHashMap}.
> 57: *
> 58: * @spec jar/jar.html JAR File Specification
Line 52 should be removed
src/java.base/share/classes/java/util/jar/Attributes.java line 450:
> 448: * JAR File
> Specification
> 449: * for more information about valid attribute names and values.
> 450: * @spec jar/jar.html JAR File Specification
Line 448 should be removed
src/java.base/share/classes/java/util/jar/Manifest.java line 47:
> 45: * Manifest format specification.
> 46: *
> 47: * @spec jar/jar.html JAR File Specification
Line 44 should be removed
src/java.base/share/classes/java/util/jar/package-info.java line 47:
> 45: *
> 46: *
> 47: * @spec jar/jar.html JAR File Specification
Line 43 should be removed
src/java.base/share/classes/java/util/zip/package-info.java line 75:
> 73: *
> 74: *
> 75: * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data
> Format Specification version 1.3
The above references should be removed as they duplicate the` @spec` tags
-
Changes requested by lancea (Reviewer).
PR: https://git.openjdk.org/jdk/pull/11073
Re: RFR: 8296546: Add @spec tags to API
On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen wrote: > It would probably be easier for the reviewers and for you if the PR could be > broken out by areas into separate PRs Leaving out the non-public and non-exported classes would also reduce the PR size. - PR: https://git.openjdk.org/jdk/pull/11073
Re: RFR: 8296546: Add @spec tags to API
On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons wrote: > On the same text but linking to different RFCs: that's tantamount to a bug > somewhere. The spec for `@spec` dictates that the URLs and titles should be > in 1-1 correspondence, and this is supposed to be enforced in the docket. In > other words, specs should have unique titles, and any title should only be > used for one spec. It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself? - PR: https://git.openjdk.org/jdk/pull/11073
Re: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4]
On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote: >> This testcase Verify the content changes of a TextArea for the following >> assertions. >> >> a. TextListener get invoked when the content of a TextArea gets changed. >> b. TextListener not get invoked during text selection or when Special keys >> such as Function Keys are pressed. >> >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got >> all pass. > > ravi gupta has updated the pull request incrementally with one additional > commit since the last revision: > > 8296632: Review fixes. Marked as reviewed by mvs (Author). - PR: https://git.openjdk.org/jdk/pull/11052
Re: RFR: 8271846 a11y API lacks setSelectedIndex method [v4]
On Fri, 11 Nov 2022 02:16:15 GMT, Sergey Bylokhov wrote: >> Artem Semenov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> We are not using author tags in tests either - but that's just a nitpick. > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 574: > >> 572: return; >> 573: } >> 574: as.addAccessibleSelection(i); > > I would like to clarify one initial question. Why we cannot use > `clearAccessibleSelection `to clean the current selection and then add a new > one by the `addAccessibleSelection`? We tried to do this, it leads to an endless repetition of the selected line until it freezes. - PR: https://git.openjdk.org/jdk/pull/8578
RFR: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null'
Observation found when JFileChooser is instantiated in WindowsLookAndFeel which invokes getSystemIcon() from WindowsFileChooserUI class. Could not find the exact root cause so predicting it to be an issue with icons not loaded where resolutionVariants map is empty in _public Image getResolutionVariant(double width, double height) _. Hence proposing a null check before accessing getWidth(). Fix is tested in CI system. - Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/11104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293862 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11104.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11104/head:pull/11104 PR: https://git.openjdk.org/jdk/pull/11104
Re: RFR: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError
On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ > which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not > find the exact root cause so predicting it to be an issue with icons not > loaded where _resolutionVariants_ map is empty in _public Image > getResolutionVariant(double width, double height) _. Hence proposing a null > check before accessing _getWidth()_. Fix is tested in CI system. Created separate PR which has the exact observation for a bug - [JDK-8293862] (https://bugs.openjdk.org/browse/JDK-8293862). Closing this PR. - PR: https://git.openjdk.org/jdk/pull/11079
Withdrawn: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError
On Thu, 10 Nov 2022 06:00:27 GMT, Tejesh R wrote: > Observation found when _JFileChooser_ is instantiated in _WindowsLookAndFeel_ > which invokes _getSystemIcon()_ from WindowsFileChooserUI class. Could not > find the exact root cause so predicting it to be an issue with icons not > loaded where _resolutionVariants_ map is empty in _public Image > getResolutionVariant(double width, double height) _. Hence proposing a null > check before accessing _getWidth()_. Fix is tested in CI system. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11079
Re: RFR: 8295779: Xcode 14.0 fails to build jdk on m1 macos
On Wed, 19 Oct 2022 15:33:31 GMT, Archie L. Cobbs wrote: > Building on MacOS 12.6 M1 with Xcode 14.0 fails due to C compiler unused > parameter warnings: > > Creating support/modules_libs/java.desktop/libosx.dylib from 1 file(s) This is a moving target, and the changes depend on the build mode as well as on the Xcode version + subversion. My company forced me on Xcode 14.1 lately. That triggered "deprecated-declarations" warnings in adlc (1x), hotspot (20x), and java.desktop (1x). These are all caused by the use of sprint(). The next Xcode subversion will for sure find other code snippets to complain about. I'm not sure which policy to follow here. Adapt the make file (will hide the warning "forever")? Change the source code (and potentially introduce new issues)? Any advice from the build gurus? - PR: https://git.openjdk.org/jdk/pull/10768
Re: RFR: 8296632: Write a test to verify the content change of TextArea sends TextEvent. [v4]
> This testcase Verify the content changes of a TextArea for the following > assertions. > > a. TextListener get invoked when the content of a TextArea gets changed. > b. TextListener not get invoked during text selection or when Special keys > such as Function Keys are pressed. > > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got > all pass. ravi gupta has updated the pull request incrementally with one additional commit since the last revision: 8296632: Review fixes. - Changes: - all: https://git.openjdk.org/jdk/pull/11052/files - new: https://git.openjdk.org/jdk/pull/11052/files/c5c93e82..3106d5bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11052&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11052/head:pull/11052 PR: https://git.openjdk.org/jdk/pull/11052
