Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible #3425

Closed
wants to merge 1 commit into from

Conversation

avu
Copy link
Contributor

@avu avu commented Apr 9, 2021

Implemented apple.awt.windowTitleVisible property to control window title visibility


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3425/head:pull/3425
$ git checkout pull/3425

Update a local copy of the PR:
$ git checkout pull/3425
$ git pull https://git.openjdk.java.net/jdk pull/3425/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3425

View PR using the GUI difftool:
$ git pr show -t 3425

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3425.diff

…itleVisible

Implemented apple.awt.windowTitleVisible property to control window title visibility
@bridgekeeper
Copy link

bridgekeeper bot commented Apr 9, 2021

👋 Welcome back avu! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label Apr 9, 2021
@openjdk
Copy link

openjdk bot commented Apr 9, 2021

@avu The following label will be automatically applied to this pull request:

  • awt

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the awt client-libs-dev@openjdk.org label Apr 9, 2021
@mlbridge
Copy link

mlbridge bot commented Apr 9, 2021

Webrevs

@mlbridge
Copy link

mlbridge bot commented Apr 10, 2021

Mailing list message from Alan Snyder on awt-dev:

Is this property (and others like it) documented somewhere application developers will look?

@mrserb
Copy link
Member

mrserb commented Apr 10, 2021

@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label Apr 10, 2021
@openjdk
Copy link

openjdk bot commented Apr 10, 2021

@mrserb has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@avu please create a CSR request and add link to it in JDK-8265005. This pull request cannot be integrated until the CSR request is approved.

@avu
Copy link
Contributor Author

avu commented Apr 12, 2021

/issue add JDK-8265085

@openjdk
Copy link

openjdk bot commented Apr 12, 2021

@avu
Adding additional issue to issue list: 8265085: Introduce the new client property for mac: apple.awt.windowTitleVisible.

@avu
Copy link
Contributor Author

avu commented Apr 12, 2021

/issue remove JDK-8265085

@openjdk
Copy link

openjdk bot commented Apr 12, 2021

@avu
Removing additional issue from issue list: 8265085.

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Apr 26, 2021
@avu
Copy link
Contributor Author

avu commented Apr 27, 2021

CSR is approved. Could you look at the fix itself?

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

13 similar comments
@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

18 similar comments
@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@mlbridge
Copy link

mlbridge bot commented Apr 27, 2021

Mailing list message from Alan Snyder on awt-dev:

No, AFAIK, we don't have any javadoc cocerning these properties. I suppose it's OK because they control platform specific window properties and rich client applications heavily depend on them. Without such properties java client applications use some hacks with JNA library to change native peers.

I do not understand this as a justification for a lack of documentation.

What is it about rich client applications that makes it OK for application developers to have to view internal JDK source code to find the property names or even to know which properties are supported?

In the old days (when Apple owned this code), they had a tech report that documented the properties.
Something is needed to replace that (long gone and now incomplete) tech report.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210427/5fef7516/attachment-0001.htm>

@avu
Copy link
Contributor Author

avu commented Apr 28, 2021

/integrate

@openjdk
Copy link

openjdk bot commented Apr 28, 2021

@avu
Your change (at version 814cfbb) is now ready to be sponsored by a Committer.

@avu
Copy link
Contributor Author

avu commented Apr 28, 2021

Could you sponsor this pull request?

@mrserb
Copy link
Member

mrserb commented Apr 28, 2021

ok

@mrserb
Copy link
Member

mrserb commented Apr 29, 2021

/sponsor

@openjdk openjdk bot closed this Apr 29, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed sponsor Pull request is ready to be sponsored ready Pull request is ready to be integrated rfr Pull request is ready for review labels Apr 29, 2021
@openjdk
Copy link

openjdk bot commented Apr 29, 2021

@mrserb @avu Since your change was applied there have been 347 commits pushed to the master branch:

  • 91226fa: 8265940: Enable C2's optimization for Math.pow(x, 0.5) on all platforms
  • 56cde70: 8266265: mark hotspot compiler/vectorization tests which ignore VM flags
  • 4937214: 8266174: -Wmisleading-indentation happens in libmlib_image sources
  • b305eff: 8266238: mark hotspot compiler/inlining tests which ignore VM flags
  • df3b2d0: 8266264: mark hotspot compiler/eliminateAutobox tests which ignore VM flags
  • 6b263e6: 8266256: compiler.vectorization.TestBufferVectorization does testing twice
  • 69155f4: 8266231: mark hotspot compiler/c1 tests which ignore VM flags
  • 0e225ef: 8197821: Test java/awt/font/TextLayout/LigatureCaretTest.java fails on Windows
  • a1c942c: 8266170: -Wnonnull happens in classLoaderData.inline.hpp
  • 4a9f231: 8266173: -Wmaybe-uninitialized happens in jni_util.c
  • ... and 337 more: https://git.openjdk.java.net/jdk/compare/ec31b3a13734a6c4fbe14afcef84b9e1768226db...master

Your commit was automatically rebased without conflicts.

Pushed as commit 155da25.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awt client-libs-dev@openjdk.org integrated Pull request has been integrated
2 participants