From github.com+10835776+stsypanov at openjdk.java.net Thu Jul 8 09:37:18 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 8 Jul 2021 09:37:18 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v9] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? 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 ten additional commits since the last revision: - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - 8268113: Inline local vars where reasonable - 8268113: Delegate to Double.hashCode() - 8268113: Re-use Long.hashCode() where possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/4ec7c829..a72a09b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=07-08 Stats: 23569 lines in 424 files changed: 8574 ins; 13030 del; 1965 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From attila at openjdk.java.net Tue Jul 13 13:08:05 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Tue, 13 Jul 2021 13:08:05 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v9] In-Reply-To: <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com> Message-ID: On Wed, 2 Jun 2021 14:11:07 GMT, ?????? ??????? wrote: >> ?????? ??????? 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 ten additional commits since the last revision: >> >> - Merge branch 'master' into 8268113 >> - Merge branch 'master' into 8268113 >> - Merge branch 'master' into 8268113 >> - Merge branch 'master' into 8268113 >> - Merge branch 'master' into 8268113 >> - Merge branch 'master' into 8268113 >> - 8268113: Inline local vars where reasonable >> - 8268113: Delegate to Double.hashCode() >> - 8268113: Re-use Long.hashCode() where possible > > src/java.base/share/classes/java/util/BitSet.java line 1040: > >> 1038: h ^= words[i] * (i + 1); >> 1039: >> 1040: return Long.hashCode(h); > > Here `>>` instead of `>>>` in original code seems to be a typo It is specified as `>>` in JavaDoc just above the implementation. As the algorithm is part of the public API and thus part of the specification, I don't think you can change it just here in the implementation; you'd need to at least submit a CSR for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Wed Jul 14 12:40:14 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 14 Jul 2021 12:40:14 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v9] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com> Message-ID: On Tue, 13 Jul 2021 13:04:36 GMT, Attila Szegedi wrote: >> src/java.base/share/classes/java/util/BitSet.java line 1040: >> >>> 1038: h ^= words[i] * (i + 1); >>> 1039: >>> 1040: return Long.hashCode(h); >> >> Here `>>` instead of `>>>` in original code seems to be a typo > > It is specified as `>>` in JavaDoc just above the implementation. As the algorithm is part of the public API and thus part of the specification, I don't think you can change it just here in the implementation; you'd need to at least submit a CSR for it. Good point! I'll then revert this change ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Wed Jul 14 12:47:43 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 14 Jul 2021 12:47:43 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v10] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? 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 12 additional commits since the last revision: - 8270160 Revert changes in BitSet.hashCode - Merge branch 'master' into 8268113 - 8270160 Revert changes in BitSet.hashCode - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - 8268113: Inline local vars where reasonable - ... and 2 more: https://git.openjdk.java.net/jdk/compare/2f04364f...1d619c73 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/a72a09b6..1d619c73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=08-09 Stats: 6977 lines in 323 files changed: 3755 ins; 2117 del; 1105 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From jlahoda at openjdk.java.net Fri Jul 16 12:34:26 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 16 Jul 2021 12:34:26 GMT Subject: RFR: 8268725: jshell does not support the --enable-native-access option Message-ID: Adding `--enable-native-access` option to JShell. Set as a parameter to the remote agent (`--enable-native-access=ALL-UNNAMED`), but not the compiler, as the compiler does not have this option. ------------- Commit messages: - 8268725: jshell does not support the --enable-native-access option Changes: https://git.openjdk.java.net/jdk/pull/4810/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4810&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268725 Stats: 69 lines in 2 files changed: 69 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4810/head:pull/4810 PR: https://git.openjdk.java.net/jdk/pull/4810 From sundar at openjdk.java.net Fri Jul 16 12:47:52 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 16 Jul 2021 12:47:52 GMT Subject: RFR: 8268725: jshell does not support the --enable-native-access option In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 12:26:01 GMT, Jan Lahoda wrote: > Adding `--enable-native-access` option to JShell. Set as a parameter to the remote agent (`--enable-native-access=ALL-UNNAMED`), but not the compiler, as the compiler does not have this option. LGTM Is this consistent with other module specific options? enable native access can be specified per module basis as well (in addition to ALL-UNNAMED) ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4810 From jlahoda at openjdk.java.net Fri Jul 16 18:06:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 16 Jul 2021 18:06:27 GMT Subject: RFR: 8268725: jshell does not support the --enable-native-access option [v2] In-Reply-To: References: Message-ID: > Adding `--enable-native-access` option to JShell. Set as a parameter to the remote agent (`--enable-native-access=ALL-UNNAMED`), but not the compiler, as the compiler does not have this option. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Including --enable-native-access in help ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4810/files - new: https://git.openjdk.java.net/jdk/pull/4810/files/b9b69ec7..47f66e3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4810&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4810&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4810/head:pull/4810 PR: https://git.openjdk.java.net/jdk/pull/4810 From jlahoda at openjdk.java.net Fri Jul 16 18:12:50 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 16 Jul 2021 18:12:50 GMT Subject: RFR: 8268725: jshell does not support the --enable-native-access option [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 12:45:21 GMT, Athijegannathan Sundararajan wrote: > LGTM > > Is this consistent with other module specific options? enable native access can be specified per module basis as well (in addition to ALL-UNNAMED) That is a good question. I don't think we have a module-specific option quite like this - we have `--add-modules`, but that is significantly different. I suspect most code run in JShell runs in the(/an) unnamed module, and having simple `--enable-native-access` helps with that. If the users want add modules, they need to use `--add-modules`, and they may have to use `-R--enable-native-access=`, but I suspect that will be a small minority of users. ------------- PR: https://git.openjdk.java.net/jdk/pull/4810 From michel.trudeau at oracle.com Thu Jul 22 22:38:19 2021 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Thu, 22 Jul 2021 22:38:19 +0000 Subject: turning off contiuation mode Re: JShellTool and future directions In-Reply-To: <7cd76261-b4f6-8b2f-aab9-a7b662382563@oracle.com> References: <0DAE3274-993E-4C7B-99A4-A5381D7FCA5F@oracle.com> <80372ef6-d816-007f-ee98-117cf25c1cc4@oracle.com> <7cd76261-b4f6-8b2f-aab9-a7b662382563@oracle.com> Message-ID: [cc?ing kulla-dev] From: Korbi Schmid Date: Thursday, July 22, 2021 at 7:49 AM To: Robert Field Cc: Michel Trudeau , Miguel Delgadillo , Francisco Riestra , Melliyal Annamalai , Steve Serra Subject: turning off contiuation mode Re: JShellTool and future directions Hi Robert I'm "hijacking" this older thread because we just ran into another problem with JShellTool and wonder if there's a simple trick here as well. Is there any way to "turn off" continuation prompt? I mean this behavior where the shell waits for more input instead of giving an error: jshell> System.out.println("I forgot to close the brace" ...> ...> ...> When used programmatically, this causes confusion because in our app there is no visual indicator like "...>" suggesting more input is required. For us it would be better if the tool directly prints out the syntax error instead of waiting for more input. Thanks Korbi On 6/5/19 5:51 PM, Robert Field wrote: Hi Martijn, The JShell API was designed as an API, the tool was not. However, I understand the desire to reuse the functionality of the tool. Your 1 and 2 can be achieved with modes, for example -- % cat > /tmp/jsmode /set mode jsmode -quiet /set prompt jsmode "pgx> " "...> " /set mode -retain jsmode % jshell --startup /tmp/jsmode --feedback jsmode pgx> For 3, I don't know how you plan to hook into the jshell tool, but if you are capturing command output, the value is in an easily parsed form -- jshell> 45 $1 ==> 45 Basically look for "$ ==>". Of course, that requires you to be in a -command mode not a -quiet mode ;-) If you are capturing command output you can just filter out the welcome message and avoid the -quiet mode. Alternatively, you could hook in through the SPI, and nab the value of ExecutionControl.invoke(...) by overriding it. There are no plans to make an API for the tool. I don't know what your needs are, hopefully simple tricks like the above will fit your needs. Let me know if you have more problems. Otherwise, you can use the JShell API, cloning as much or all of the tool as needed -- with the ensuing maintenance issues. Hope that helps, Robert On 6/5/19 8:33 AM, Martijn Dwars wrote: Hello Robert, I am part of the PGX team (Oracle Labs) where we develop PGX, a Parallel Graph AnalytiX engine. PGX currently comes with a Groovy shell, but we are in the process of replacing this Groovy-based shell by a JShell-based shell. We were considering using the JShellTool, since it adds a lot of useful functionality to the bare JShell. However, the public API of the JShellTool is very restricted. Some problems that we ran into: 1. It is not possible to change the prompt from "jshell>" into "pgx>". We tried to do this by creating a feedback mode in a startup script, but the startup script is loaded before the pre-defined feedback modes are loaded. 2. It is not possible to suppress the jshell welcome message ("Welcome to JShell -- Version 11.0.2?). 3. It is not possible to access the values of the expressions (in particular, we would like to capture the value of the last expression after evaluating a piece of code). Could you tell me if we are correct in that the above is not possible with the JShellTool? Are there plans to open up the JShellTool API in the future, or are we better off building our own solution on top of JShell (and reimplementing most of the functionality found in JShellTool)? Kind regards, Martijn Dwars From sundar at openjdk.java.net Fri Jul 23 17:13:02 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 23 Jul 2021 17:13:02 GMT Subject: RFR: 8268725: jshell does not support the --enable-native-access option [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 18:06:27 GMT, Jan Lahoda wrote: >> Adding `--enable-native-access` option to JShell. Set as a parameter to the remote agent (`--enable-native-access=ALL-UNNAMED`), but not the compiler, as the compiler does not have this option. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Including --enable-native-access in help Marked as reviewed by sundar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4810 From github.com+10835776+stsypanov at openjdk.java.net Mon Jul 26 08:27:14 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 26 Jul 2021 08:27:14 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v11] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? 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 13 additional commits since the last revision: - Merge branch 'master' into 8268113 - 8270160 Revert changes in BitSet.hashCode - Merge branch 'master' into 8268113 - 8270160 Revert changes in BitSet.hashCode - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/441e382b...bd762b7d ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/1d619c73..bd762b7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=09-10 Stats: 7986 lines in 302 files changed: 5011 ins; 1046 del; 1929 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309