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

8205137: Remove Applet support from SwingSet2 #5401

Closed
wants to merge 5 commits into from

Conversation

alisenchung
Copy link
Contributor

@alisenchung alisenchung commented Sep 7, 2021

removed support for running demo from applet for J2Ddemo and SwingSet2
same PR as 8205137: Remove Applet support from SwingSet2 #5400 (changed branch name)


Progress

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

Issues

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5401

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

Using diff file

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

@alisenchung
Copy link
Contributor Author

@alisenchung alisenchung commented Sep 7, 2021

/covered
/issue add 8205139

@bridgekeeper bridgekeeper bot added the oca label Sep 7, 2021
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 7, 2021

Hi @alisenchung, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user alisenchung" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

@bridgekeeper bridgekeeper bot added the oca-verify label Sep 7, 2021
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 7, 2021

Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

@openjdk
Copy link

@openjdk openjdk bot commented Sep 7, 2021

@alisenchung Unknown command issues - for a list of valid commands use /help.

@openjdk
Copy link

@openjdk openjdk bot commented Sep 7, 2021

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

  • swing

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 swing label Sep 7, 2021
@alisenchung
Copy link
Contributor Author

@alisenchung alisenchung commented Sep 7, 2021

/issue add 8205139

@openjdk
Copy link

@openjdk openjdk bot commented Sep 7, 2021

@alisenchung
Adding additional issue to issue list: 8205139: Remove Applet support from J2Ddemo.

@bridgekeeper bridgekeeper bot removed oca oca-verify labels Sep 8, 2021
@openjdk openjdk bot added the rfr label Sep 8, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 8, 2021

@mrserb
Copy link
Member

@mrserb mrserb commented Sep 8, 2021

Probably the README in the "jdk/src/demo/share/" should be updated as well?
This block looks outdated:

In some cases, the default security settings may block an execution
of demo applets in a browser. To adjust the security settings, please
refer to the following resource:

http://java.com/en/download/help/java_blocked.xml

Some demo applets need to be accessed through the HTTP or HTTPS
protocols to enable access to the required resources.

@prrace
Copy link
Contributor

@prrace prrace commented Sep 8, 2021

The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).

@alisenchung
Copy link
Contributor Author

@alisenchung alisenchung commented Sep 8, 2021

The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).

I just removed the java.applet.* import for all of them. Should I revert the date if there's no other content change?

@victordyakov
Copy link

@victordyakov victordyakov commented Sep 9, 2021

@azuev-java please review

@prrace
Copy link
Contributor

@prrace prrace commented Sep 9, 2021

The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).

I just removed the java.applet.* import for all of them. Should I revert the date if there's no other content change?

Hmm .. I missed the delete.
Well .. what were those imports for ? Nothing used them.
Now, although arguably a separate issue, we have precedent for cleaning up imports at such a time.
There are LOTS of wild card imports.
I'd like you to update this to current practice to explicitly enumerate the classes needed
so rather than
import java.util.*;

import java.util.Map
etc ..
JUST those needed.

Then we may actually have something worthy of updating a (c) ..

@mrserb
Copy link
Member

@mrserb mrserb commented Sep 9, 2021

Hmm .. I missed the delete.
Well .. what were those imports for ? Nothing used them.
Now, although arguably a separate issue, we have precedent for cleaning up imports at such a time.

This helped to prove that the usage of applets is actually removed from these files, I found it quite useful during the review.

@aivanov-jdk
Copy link
Member

@aivanov-jdk aivanov-jdk commented Sep 9, 2021

The files that have JUST a (c) date update should all be reverted. You haven't touched them so there is nothing to (c).

I just removed the java.applet.* import for all of them. Should I revert the date if there's no other content change?

Hmm .. I missed the delete.
Well .. what were those imports for ? Nothing used them.

It looks each file has the same wildcard import statements.

Now, although arguably a separate issue, we have precedent for cleaning up imports at such a time.
There are LOTS of wild card imports.

Many of the imports are unused. For example, TreeDemo.java doesn't use any of these: javax.swing.event.*, javax.accessibility.*, java.util.*.

It makes sense to clean it up along with removing java.applet.* imports.

@aivanov-jdk
Copy link
Member

@aivanov-jdk aivanov-jdk commented Sep 9, 2021

Probably the README in the "jdk/src/demo/share/" should be updated as well?

SwingSet2/README should also be updated.

@openjdk openjdk bot added the client label Sep 10, 2021
Reviewed-by: alichung
prrace
prrace approved these changes Sep 10, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 10, 2021

@alisenchung This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8205137: Remove Applet support from SwingSet2
8205139: Remove Applet support from J2Ddemo

Reviewed-by: aivanov, kizune

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 232 new commits pushed to the master branch:

  • 57fe11c: 8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles
  • 81d4164: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout
  • da38ced: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
  • d39aad9: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()
  • c9de806: 8274039: codestrings gtest fails when hsdis is present
  • 33df388: 8274003: ProcessHandleImpl.Info toString has an if check which is always true
  • 0a36163: 8272600: (test) Use native "sleep" in Basic.java
  • c6df3c9: 8274071: Clean up java.lang.ref comments and documentation
  • 71788c6: 8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"
  • ba7d550: 8270139: jshell InternalError crash for import of @repeatable followed by unresolved ref
  • ... and 222 more: https://git.openjdk.java.net/jdk/compare/14a3ac09fe504ea97d269b78872bef6021c976fd...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@prrace, @aivanov-jdk, @azuev-java) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Sep 10, 2021
Copy link
Member

@aivanov-jdk aivanov-jdk left a comment

In all the files except for ButtonDemo.java, you modify the imports only; in case of ButtonDemo.java, you also reformat the code. Is it intentional?

The imports in the files were in this order: javax.* followed by java.*. This order is preserved. However, in the JDK source files, imports from java.* usually come before javax.*.

What is the preferred order of imports?

@alisenchung
Copy link
Contributor Author

@alisenchung alisenchung commented Sep 10, 2021

In all the files except for ButtonDemo.java, you modify the imports only; in case of ButtonDemo.java, you also reformat the code. Is it intentional?

Oh the reformat was unintentional, let me revert that...

prrace
prrace approved these changes Sep 10, 2021
@mrserb
Copy link
Member

@mrserb mrserb commented Sep 11, 2021

What is the preferred order of imports?

Usually it is
java.*
empty line
javax.*
empty line
others.*
empty line
static java.*
empty line
static javax.*
empty line
others.*

Copy link
Contributor

@prrace prrace left a comment

https://www.oracle.com/technetwork/java/codeconventions-150003.pdf didn't say anything relevant.

The still-in-draft update to this http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-import-statements
which is focused on OpenJDK developers says

Import statements should be sorted…
…primarily by non-static / static with non-static imports first.
…secondarily by package origin according to the following order
java packages
javax packages
external packages (e.g. org.xml)
internal packages (e.g. com.sun)
…tertiary by package and class identifier in lexicographical order

So that isn't yet "blessed" and could be written a bit more clearly but I could also imagine quibbles these days
like "group imports by module, starting with java.base" as the primary one.

And imports from named modules go first ..

And I can imagine folks wanting to place exception imports after other imports ..

So I don't think there is any agreed upon set of rules to follow although most folks
when you get down to the specific package do place them in lexical order

Here I note that the pre-existing wild card imports were of javax.swing followed by java.awt*
and the change is preserving that so I don't have a strong opinion on that nor do I think I
would insist on lexical ordering but I also would be quite fine if the fixer is OK to make that change.

src/demo/share/jfc/SwingSet2/DemoModule.java Outdated Show resolved Hide resolved
src/demo/share/jfc/SwingSet2/TabbedPaneDemo.java Outdated Show resolved Hide resolved
@alisenchung
Copy link
Contributor Author

@alisenchung alisenchung commented Sep 13, 2021

So I don't think there is any agreed upon set of rules to follow although most folks
when you get down to the specific package do place them in lexical order

Here I note that the pre-existing wild card imports were of javax.swing followed by java.awt*
and the change is preserving that so I don't have a strong opinion on that nor do I think I
would insist on lexical ordering but I also would be quite fine if the fixer is OK to make that change.

I can do this and fix the other two files that I missed.

@aivanov-jdk
Copy link
Member

@aivanov-jdk aivanov-jdk commented Sep 13, 2021

I asked about imports because I usually see java.* followed by javax.* followed by internal imports in the JDK code. I wanted to confirm my understanding.

If I remember correctly, IDEA has a different order by default: other imports, then java.* and javax.*. I can see the motivation here: for projects using Java, you care about your own classes more than java(x) packages. For JDK, java(x) are the important ones.

In this case, the previous order of the imports was preserved where javax.* imports were before java.*. In addition to that, SwingSet2 is a demo of Swing components, so having javax.swing.* above java.awt.* makes sense to me too.

Here I note that the pre-existing wild card imports were of javax.swing followed by java.awt*
and the change is preserving that so I don't have a strong opinion on that nor do I think I
would insist on lexical ordering but I also would be quite fine if the fixer is OK to make that change.

I'm also fine with either order of the imports.

@mrserb
Copy link
Member

@mrserb mrserb commented Sep 13, 2021

I suggest using the same order no need to think about which order is correct in which file, but simple as this: #5401 (comment)

@prrace
Copy link
Contributor

@prrace prrace commented Sep 13, 2021

I suggest using the same order no need to think about which order is correct in which file, but simple as this: #5401 (comment)

My point is that you can't point to any doc that says "this is the order to be used" because we've never codified it.
So as long as it is reasonable .. ie not jumping from package to package, it's all good.

FWIW the old style guideline doesn't even have anything to say about not using wildcards. I guess they were thought to be cool but as things got bigger it became vulnerable to clashes, so there is "general" acceptance that there's a good reason for explicit imports beyond aesthetics or style.

@mrserb
Copy link
Member

@mrserb mrserb commented Sep 15, 2021

I suggest using the same order no need to think about which order is correct in which file, but simple as this: #5401 (comment)

My point is that you can't point to any doc that says "this is the order to be used" because we've never codified it.

We did that, we discussed it someday long ago and I followed it for most of my code cleanups in java desktop module. It also was summarised here http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-import-statements
But yes we did not strictly follow it, not a big issue.

@alisenchung
Copy link
Contributor Author

@alisenchung alisenchung commented Sep 22, 2021

/integrate

@openjdk openjdk bot added the sponsor label Sep 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 22, 2021

@alisenchung
Your change (at version e03d6d5) is now ready to be sponsored by a Committer.

@aivanov-jdk
Copy link
Member

@aivanov-jdk aivanov-jdk commented Sep 22, 2021

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented Sep 22, 2021

Going to push as commit 8821b00.
Since your change was applied there have been 232 commits pushed to the master branch:

  • 57fe11c: 8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles
  • 81d4164: 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout
  • da38ced: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
  • d39aad9: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()
  • c9de806: 8274039: codestrings gtest fails when hsdis is present
  • 33df388: 8274003: ProcessHandleImpl.Info toString has an if check which is always true
  • 0a36163: 8272600: (test) Use native "sleep" in Basic.java
  • c6df3c9: 8274071: Clean up java.lang.ref comments and documentation
  • 71788c6: 8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"
  • ba7d550: 8270139: jshell InternalError crash for import of @repeatable followed by unresolved ref
  • ... and 222 more: https://git.openjdk.java.net/jdk/compare/14a3ac09fe504ea97d269b78872bef6021c976fd...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Sep 22, 2021
@openjdk openjdk bot added integrated and removed ready rfr sponsor labels Sep 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 22, 2021

@aivanov-jdk @alisenchung Pushed as commit 8821b00.

💡 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
client integrated swing
6 participants