From jwaters at openjdk.org Tue Nov 1 00:10:27 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 1 Nov 2022 00:10:27 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v12] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Include extra directories required by HotSpot in HotSpot only workspaces - SINGLE_DOLLAR is not required - Nuke accidental comment not meant to be added - Initial support for Language Settings Providers - Prevent Eclipse from automatically attaching binary parsers to workspaces including native code - Merge - Squash issue with commas - File operations should use MakeIO.gmk - ... and 6 more: https://git.openjdk.org/jdk/compare/807a1ba8...db0e248e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/90a7d061..db0e248e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=10-11 Stats: 2403 lines in 87 files changed: 1666 ins; 300 del; 437 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Wed Nov 2 11:56:47 2022 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 2 Nov 2022 11:56:47 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v13] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Include extra directories required by HotSpot in HotSpot only workspaces - SINGLE_DOLLAR is not required - Nuke accidental comment not meant to be added - Initial support for Language Settings Providers - Prevent Eclipse from automatically attaching binary parsers to workspaces including native code - Merge - Squash issue with commas - ... and 7 more: https://git.openjdk.org/jdk/compare/3e3e9c16...065cbea5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/db0e248e..065cbea5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=11-12 Stats: 11094 lines in 228 files changed: 8335 ins; 1792 del; 967 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Thu Nov 3 06:15:46 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 06:15:46 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v14] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision: - Rename RAnDOM to WORKSPACE_ID - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Include extra directories required by HotSpot in HotSpot only workspaces - SINGLE_DOLLAR is not required - Nuke accidental comment not meant to be added - Initial support for Language Settings Providers - Prevent Eclipse from automatically attaching binary parsers to workspaces including native code - ... and 9 more: https://git.openjdk.org/jdk/compare/5907c2db...125601f8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/065cbea5..125601f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=12-13 Stats: 31318 lines in 98 files changed: 1831 ins; 29095 del; 392 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Thu Nov 3 06:19:20 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 06:19:20 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v2] In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 10:15:10 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - Formatting >> - Whitespace >> - Carriage Returns >> - Documentation >> - Implement Eclipse support > > Will this work with jtreg test sources too? At least on Intellij those require a brittle intellij plugin. @tstuefe I'm not entirely sure what you mean by "jtreg test sources", are you referring to IntelliJ's ability to call the different `make test` targets with the help of the jtreg plugin? ------------- PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Mon Nov 7 06:14:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Nov 2022 06:14:18 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v15] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request incrementally with one additional commit since the last revision: More Changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/125601f8..14934d9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=13-14 Stats: 38 lines in 1 file changed: 23 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Sat Nov 12 16:18:04 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 12 Nov 2022 16:18:04 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v16] In-Reply-To: References: Message-ID: <1iiGymPVIbiGtytzR_H-CysyK1QOk0e1m-AyOMb010s=.2a41cfbc-6f3c-4da4-849f-e5a02b9af6a6@github.com> > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into eclipse - More Changes - Rename RAnDOM to WORKSPACE_ID - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Include extra directories required by HotSpot in HotSpot only workspaces - SINGLE_DOLLAR is not required - Nuke accidental comment not meant to be added - ... and 11 more: https://git.openjdk.org/jdk/compare/c88faff1...6734b840 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/14934d9e..6734b840 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=14-15 Stats: 18065 lines in 703 files changed: 8929 ins; 6463 del; 2673 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Sun Nov 13 14:49:39 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 13 Nov 2022 14:49:39 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v17] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Include miscellaneous directories in any Workspace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/6734b840..564ceced Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=15-16 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Sun Nov 13 14:52:49 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 13 Nov 2022 14:52:49 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v18] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Oversight ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/564ceced..4c030fe6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=16-17 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From ihse at openjdk.org Wed Nov 16 13:31:09 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 16 Nov 2022 13:31:09 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac Message-ID: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. ------------- Commit messages: - Update copyright year for javac server files - One more sjavac reference in test - Remove last references to sjavac - Move compilation of javac server to interim langtools - Update package in compilation as well - Remove or rename remaining references to sjavac - Change package name to javacserver - Clean up Options - Move javac server to buildtools - Cut last ties to javac internals... - ... and 4 more: https://git.openjdk.org/jdk/compare/d0fae43e...2124c86b Changes: https://git.openjdk.org/jdk/pull/11185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297041 Stats: 12695 lines in 118 files changed: 1058 ins; 11574 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/11185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11185/head:pull/11185 PR: https://git.openjdk.org/jdk/pull/11185 From ihse at openjdk.org Wed Nov 16 13:35:04 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 16 Nov 2022 13:35:04 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. Some more detailed explanations of the changes I've made in this patch. * I have stripped down the original sjavac code to retain only the "javac server" part, and associated machinery. In some cases it can probably be possible to cut out even more baggage, but I had to draw the line somewhere. * The remaining sjavac code has moved to `make/langtools/tools`, together with the other langtools buildtools. * All sjavac jtreg tests in langtools has been removed. * A few non-sjavac-related tests (for AppCDS) references sjavac. My interpretation is that these classes were just picked arbitrarily as a good representation, so I have modified these tests to pick other, arbitrary classes. (I'd like to have some input from AppCDS folks that I did this correctly) * I have verified that it is still possible to build with, and without, the javac server, and that there has been no build performance regressions. * The original implementation used a class internal to the `jdk.compiler` module to actually kick off the javac compilation. This was no longer an option when moving out of the module, but fortunately there is actually an exported class that does the same, `com.sun.tools.javac.Main`. This is however deprecated, and I realize it is not ideal to introduce a dependency to a deprecated class (but see below). On a longer term, the current javac server tool is under scrutiny, and it will probably be rewritten into a more general "portal" to run other langtools binaries such as javadoc. It will also be transformed into using the ToolProvider API, which will solve the problem of calling the deprecated method. @sormuras is working on this. ------------- PR: https://git.openjdk.org/jdk/pull/11185 From cstein at openjdk.org Wed Nov 16 13:52:59 2022 From: cstein at openjdk.org (Christian Stein) Date: Wed, 16 Nov 2022 13:52:59 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: <8lxHo8-YXCouOHXWzh4_dzhNRsXXCztN1QETwKe7hlQ=.83d75077-4b11-4d0e-acdc-f2784fd2d634@github.com> On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. LGTM ------------- Marked as reviewed by cstein (Committer). PR: https://git.openjdk.org/jdk/pull/11185 From erikj at openjdk.org Wed Nov 16 14:10:04 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 14:10:04 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. Would it be worth keeping the relevant tests around in a separate test root for buildtools, given that this buildtool is rather big and complex? Or is the replacement so imminent that it's not worth the effort? ------------- PR: https://git.openjdk.org/jdk/pull/11185 From cstein at openjdk.org Wed Nov 16 14:14:59 2022 From: cstein at openjdk.org (Christian Stein) Date: Wed, 16 Nov 2022 14:14:59 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson wrote: > Or is the replacement so imminent that it's not worth the effort? This. I aim to replace `javacserver` with a well-tested `javatoolportal` buildtool in the coming months. An almost working POC is already available - but forcing it to go live with the JDK 20 train would not be good and replacing a minimal `javacserver` buildtool is an easier/lighter task. ------------- PR: https://git.openjdk.org/jdk/pull/11185 From erikj at openjdk.org Wed Nov 16 14:31:19 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 14:31:19 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11185 From ihse at openjdk.org Wed Nov 16 16:44:16 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 16 Nov 2022 16:44:16 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson wrote: >> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. >> >> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. >> >> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. > > Would it be worth keeping the relevant tests around in a separate test root for buildtools, given that this buildtool is rather big and complex? Or is the replacement so imminent that it's not worth the effort? @erikj79 I'd also like to add that, at this point, the buildtool is not very complex. Right now it just listens to a port, and kicks off a javac compilation for each incoming call. It looks more complex since we've come here the long way around from a more complicated tool, and I did not spend too much time simplifying the code. ------------- PR: https://git.openjdk.org/jdk/pull/11185 From jjg at openjdk.org Wed Nov 16 17:56:13 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 16 Nov 2022 17:56:13 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. make/langtools/tools/javacserver/comp/SjavacImpl.java line 36: > 34: import java.io.PrintWriter; > 35: import java.io.StringWriter; > 36: import java.util.stream.Stream; This is a build tool, so you get to set the guidelines, but generally, this is an unusual order for imports make/langtools/tools/javacserver/comp/SjavacImpl.java line 47: > 45: * deletion without notice. > 46: */ > 47: public class SjavacImpl implements Sjavac { ... so it looks like there are still some vestiges of `Sjavac` ... ------------- PR: https://git.openjdk.org/jdk/pull/11185 From jjg at openjdk.org Wed Nov 16 18:02:18 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 16 Nov 2022 18:02:18 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. Nice cleanup. test/langtools/ProblemList.txt line 69: > 67: tools/sjavac/IgnoreSymbolFile.java 8158002 generic-all Requires investigation > 68: tools/sjavac/ClasspathDependencies.java 8158002 generic-all Requires investigation > 69: I presume these issues, 8152055, 8158002, are still open? They should either be closed or assigned to the build team. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.org/jdk/pull/11185 From ihse at openjdk.org Wed Nov 16 18:47:05 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 16 Nov 2022 18:47:05 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com> On Wed, 16 Nov 2022 17:51:20 GMT, Jonathan Gibbons wrote: >> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. >> >> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. >> >> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. > > make/langtools/tools/javacserver/comp/SjavacImpl.java line 36: > >> 34: import java.io.PrintWriter; >> 35: import java.io.StringWriter; >> 36: import java.util.stream.Stream; > > This is a build tool, so you get to set the guidelines, but generally, this is an unusual order for imports Haha! Calling this "unusual" is the most diplomatic expression I've heard today. :-) This is just bonkers. I used a combination of "organize imports" on IntelliJ (without setting up specific rules for the project) and a brute search-and-replace. I'll fix. > make/langtools/tools/javacserver/comp/SjavacImpl.java line 47: > >> 45: * deletion without notice. >> 46: */ >> 47: public class SjavacImpl implements Sjavac { > > ... so it looks like there are still some vestiges of `Sjavac` ... Yes, I did not bother renaming the files and classes in the actual javacserver implementation. I'm hoping Christian will clean this up later on anyway. I just tried to prune out the lion's share of what's not needed anymore. > test/langtools/ProblemList.txt line 69: > >> 67: tools/sjavac/IgnoreSymbolFile.java 8158002 generic-all Requires investigation >> 68: tools/sjavac/ClasspathDependencies.java 8158002 generic-all Requires investigation >> 69: > > I presume these issues, 8152055, 8158002, are still open? They should either be closed or assigned to the build team. No, I've closed them already, with a reference to this issue. ------------- PR: https://git.openjdk.org/jdk/pull/11185 From ihse at openjdk.org Wed Nov 16 18:47:06 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 16 Nov 2022 18:47:06 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac In-Reply-To: <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com> Message-ID: <481wI-t55703G09LJRP45YUrPga7pe8M_diFquKb_c4=.31d3ceda-d828-42ee-a8d2-1bd3f160dc65@github.com> On Wed, 16 Nov 2022 18:42:23 GMT, Magnus Ihse Bursie wrote: >> test/langtools/ProblemList.txt line 69: >> >>> 67: tools/sjavac/IgnoreSymbolFile.java 8158002 generic-all Requires investigation >>> 68: tools/sjavac/ClasspathDependencies.java 8158002 generic-all Requires investigation >>> 69: >> >> I presume these issues, 8152055, 8158002, are still open? They should either be closed or assigned to the build team. > > No, I've closed them already, with a reference to this issue. To be clear: they referred to the test code that is removed as part of this PR, so closing them is the only reasonable thing to do. ------------- PR: https://git.openjdk.org/jdk/pull/11185 From ihse at openjdk.org Thu Nov 17 09:21:53 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 17 Nov 2022 09:21:53 GMT Subject: RFR: 8297041: Remove the last remnants of sjavac [v2] In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Fix weird imports - Update comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11185/files - new: https://git.openjdk.org/jdk/pull/11185/files/2124c86b..8ff38b78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11185&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11185&range=00-01 Stats: 77 lines in 15 files changed: 45 ins; 30 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11185/head:pull/11185 PR: https://git.openjdk.org/jdk/pull/11185 From ihse at openjdk.org Thu Nov 17 09:23:35 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 17 Nov 2022 09:23:35 GMT Subject: Integrated: 8297041: Remove the last remnants of sjavac In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com> Message-ID: On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote: > The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc. > > Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code. > > This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place. This pull request has now been integrated. Changeset: 4527dc67 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/4527dc67be6d238dcecd98c2aa05cbf0b8077e59 Stats: 12695 lines in 118 files changed: 1060 ins; 11561 del; 74 mod 8297041: Remove the last remnants of sjavac Reviewed-by: cstein, erikj, jjg ------------- PR: https://git.openjdk.org/jdk/pull/11185 From jwaters at openjdk.org Wed Nov 23 13:41:01 2022 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 23 Nov 2022 13:41:01 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v19] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Resolve Conflict - Oversight - Include miscellaneous directories in any Workspace - Merge remote-tracking branch 'upstream/master' into eclipse - More Changes - Rename RAnDOM to WORKSPACE_ID - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - ... and 14 more: https://git.openjdk.org/jdk/compare/5b3d86f2...71a89d2c ------------- Changes: https://git.openjdk.org/jdk/pull/10853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=18 Stats: 555 lines in 4 files changed: 555 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Wed Nov 23 13:50:32 2022 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 23 Nov 2022 13:50:32 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v20] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Merge remote-tracking branch 'upstream/master' into eclipse ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10853/files - new: https://git.openjdk.org/jdk/pull/10853/files/71a89d2c..bd5f620b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=18-19 Stats: 79 lines in 1 file changed: 51 ins; 26 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Thu Nov 24 07:05:02 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 24 Nov 2022 07:05:02 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v21] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Oversight - Include miscellaneous directories in any Workspace - Merge remote-tracking branch 'upstream/master' into eclipse - More Changes - Rename RAnDOM to WORKSPACE_ID - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - ... and 15 more: https://git.openjdk.org/jdk/compare/abeddab9...b5ecdabc ------------- Changes: https://git.openjdk.org/jdk/pull/10853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=20 Stats: 580 lines in 4 files changed: 580 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Sun Nov 27 07:29:53 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 27 Nov 2022 07:29:53 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v22] In-Reply-To: References: Message-ID: > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Merge remote-tracking branch 'upstream/master' into eclipse - Format - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Oversight - Include miscellaneous directories in any Workspace - Merge remote-tracking branch 'upstream/master' into eclipse - More Changes - Rename RAnDOM to WORKSPACE_ID - Merge remote-tracking branch 'upstream/master' into eclipse - ... and 17 more: https://git.openjdk.org/jdk/compare/50f9043c...d4c2ebf4 ------------- Changes: https://git.openjdk.org/jdk/pull/10853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=21 Stats: 580 lines in 4 files changed: 580 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853 From jwaters at openjdk.org Tue Nov 29 13:26:48 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 29 Nov 2022 13:26:48 GMT Subject: RFR: 8295884: Implement IDE support for Eclipse [v23] In-Reply-To: References: Message-ID: <-iY5_QGbQ-lFmpTBZH-77kfcFsJGmxsE4blXDGKUoyk=.f00668c3-dffb-4fbb-b306-7fa794e9f245@github.com> > Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK. > > This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory. > > Indexing capabilities utilizing the enhancement: > java > escape Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge remote-tracking branch 'upstream/master' into eclipse - Changes - Merge remote-tracking branch 'upstream/master' into eclipse - Format - Merge remote-tracking branch 'upstream/master' into eclipse - Merge remote-tracking branch 'upstream/master' into eclipse - Oversight - Include miscellaneous directories in any Workspace - Merge remote-tracking branch 'upstream/master' into eclipse - More Changes - ... and 19 more: https://git.openjdk.org/jdk/compare/2deb318c...f09d21cb ------------- Changes: https://git.openjdk.org/jdk/pull/10853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=22 Stats: 592 lines in 4 files changed: 592 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853 PR: https://git.openjdk.org/jdk/pull/10853