Hello,
I'd like to enhance the WindowsTerminal in jdk.internal.le with function
keys handling. The intent is so that jshell can bind actions for
shortcuts including function keys.
The patch for adding the function keys support is here:
http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/
A
Hi,
I'd like to ask for a review of a patch for JDK-8131913. The fix is to
use the "UnsupportedTerminal", which will not try to switch the OS
terminal into the raw mode.
The proposed patch is here:
http://cr.openjdk.java.net/~jlahoda/8131913/webrev.00/index.html
Any comments are welcome.
Th
Hi,
I think I'd prefer to try to fix that. I think there's a good chance
this fix:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039165.html
will fix also the Mac OSX problem. Sadly, I didn't hear any feedback on
that yet.
Thanks,
Jan
On 11.3.2016 08:15, Felix Yang wro
If there's no better way, then OK.
Jan
On 11.3.2016 09:59, Felix Yang wrote:
Hi Jan,
we have seen test runs hanging 15+ hours on several environments,
which blocks other testing. So is it OK to exclude it before the fix ready?
Thanks,
Felix
On 2016/3/11 16:12, Jan Lahoda wrote:
H
Hello,
Any feedback/comments on this?
Thanks,
Jan
On 1.3.2016 11:54, Jan Lahoda wrote:
Hi,
I'd like to ask for a review of a patch for JDK-8131913. The fix is to
use the "UnsupportedTerminal", which will not try to switch the OS
terminal into the raw mode.
The propose
Hi,
I'd like to upgrade the JLine used by JShell and jjs from 2.12.1 to 2.14.6.
The complete webrev is here:
http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/complete/
To simplify reviewing, there is:
-an antipatch that removes the JDK-specific changes and restores the
vanilla 2.12.1 cont
Hi,
On 29.5.2018 14:51, Alan Bateman wrote:
On 25/05/2018 21:20, Jan Lahoda wrote:
Hi,
I'd like to upgrade the JLine used by JShell and jjs from 2.12.1 to
2.14.6.
The complete webrev is here:
http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/complete/
To simplify reviewing, the
um 22:20 schrieb Jan Lahoda :
Hi,
I'd like to upgrade the JLine used by JShell and jjs from 2.12.1 to 2.14.6.
The complete webrev is here:
http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/complete/
To simplify reviewing, there is:
-an antipatch that removes the JDK-specific changes an
problem with automatically adding space after completion is resolved
-a few tweaks to tests
Does this look good?
Thanks,
Jan
On 29.5.2018 16:04, Jan Lahoda wrote:
Hi,
On 29.5.2018 14:51, Alan Bateman wrote:
On 25/05/2018 21:20, Jan Lahoda wrote:
Hi,
I'd like to upgrade the JLine us
Hi,
I'd like to upgrade the JOpt Simple library we are using to version 5.0.4.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203891
Complete webrev:
http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/complete/
Delta webrev only showing (all) JDK changes in JOpt Simple and related
changes
On 4.6.2018 17:00, Alan Bateman wrote:
On 31/05/2018 10:11, Jan Lahoda wrote:
Hi,
I'd like to upgrade the JOpt Simple library we are using to version
5.0.4.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203891
Complete webrev:
http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/com
On 4.6.2018 19:40, mandy chung wrote:
Hi Jan,
On 5/31/18 2:11 AM, Jan Lahoda wrote:
Hi,
I'd like to upgrade the JOpt Simple library we are using to version
5.0.4.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203891
Complete webrev:
http://cr.openjdk.java.net/~jlahoda/8203891/webr
I guess Jon's comment was that (per JLS) the outcome of unicode
unescapes can then participate in the escape sequences in String
literals. So, this:
"\u005ct"
is (as far as I know) a single character-literal (a tab), while it seems
that
`\u005ct`.unescape()
is two characters:
\t
Not sure if
Done. I've changed the Compatibility Kind to "source" (as I guess it
better reflects the change, and the original CSR appears to have it as
well) and added "Language Construct" to Interface Kind.
Jan
On 2.1.2019 19:02, Jim Laskey wrote:
Looking for reviewers to make sure this CSR passes muste
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_' as
a one-character identifier in the jaxp and jdk repositories. All the
uses I was able to find are in tests, and the identifier is used as a
name of a catch parameter. The proposed new name is "ignore", but if a
differe
webrev.01/jdk/
Does this make sense?
Thanks!
Jan
On 1.12.2014 14:01, Andreas Lundblad wrote:
On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_'
as a one-character identifier in the jaxp and jd
On 1.12.2014 14:20, Alan Bateman wrote:
On 01/12/2014 12:10, Jan Lahoda wrote:
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_'
as a one-character identifier in the jaxp and jdk repositories. All
the uses I was able to find are in tests, and the identifi
Thanks to all for the comments!
Jan
On 2.12.2014 11:15, Alan Bateman wrote:
On 01/12/2014 13:37, Jan Lahoda wrote:
:
In TypeCheckMicroBenchmark then "ignore" is might be a misleading too
given that the ArrayStoreException causes a CCE to be thrown.
I've updated the patch t
On 3.4.2015 01:52, Jonathan Gibbons wrote:
Sorry for the relatively wide distribution.
JDK-8076583 is a conceptually simple cleanup, to move the source file
for the jdk.Exported class from the langtools repo (where it is a
singleton outlier) to the jdk repo (alongside most of the rest of the
cla
On 9.6.2015 01:31, Daniel D. Daugherty wrote:
>
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
old L171: case "1.9":
new L171: case "9":
Hello,
I am proposing to add JLine 2.12.1 into the jdk repository for use by
the Java and Nashorn REPLs. Full patch is available here:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/
To aid the review, I've split this patch into to smaller patches:
-a patch that only adds unmodifie
ks for the comments!
Jan
+1 from nashorn point of view.
Thanks,
-Sundar
On Thursday 18 June 2015 07:55 PM, Jan Lahoda wrote:
Hello,
I am proposing to add JLine 2.12.1 into the jdk repository for use by
the Java and Nashorn REPLs. Full patch is available here:
http://cr.openjdk.java.net/~jlaho
m guessing that you copied Lib-jdk.jdi.gmk as a template. Is the
-DUSE_MMAP just an artifact of that copy or do you know that it is needed?
/Erik
On 2015-06-18 16:25, Jan Lahoda wrote:
Hello,
I am proposing to add JLine 2.12.1 into the jdk repository for use by
the Java and Nashorn REPLs. Full
per Erik's recommendations
-the module name is now changed to jdk.internal.le
Any comments are welcome!
Thanks,
Jan
On 18.6.2015 16:25, Jan Lahoda wrote:
Hello,
I am proposing to add JLine 2.12.1 into the jdk repository for use by
the Java and Nashorn REPLs. Full patch is avail
Hi Alan,
Thanks for the comments! A question inline.
On 25.6.2015 18:38, Alan Bateman wrote:
On 25/06/2015 17:25, Jan Lahoda wrote:
Hello,
Based on the feedback I've received so far, I've uploaded an updated
version of the patch:
http://cr.openjdk.java.net/~jlahoda/8080679/webr
comments!
Jan
On 26.6.2015 10:45, Alan Bateman wrote:
On 26/06/2015 08:58, Jan Lahoda wrote:
:
The native method readKeyEvent seems to do a FindClass per key event.
Maybe this is from the upstream project but I would think it would be
more efficient to cache this in a global ref. It would
On 26.6.2015 16:00, Alan Bateman wrote:
On 26/06/2015 14:38, Jan Lahoda wrote:
Uploaded a new iteration of the patch, reflecting the comments so far,
here:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.02/full/
A delta patch from previous iteration:
http://cr.openjdk.java.net/~jlahoda
On 29.6.2015 12:09, Alan Bateman wrote:
On 29/06/2015 10:10, Jan Lahoda wrote:
Thanks for the comment - done that. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/full/
Delta against the previous iteration:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/delta
On 29.6.2015 12:09, Alan Bateman wrote:
On 29/06/2015 10:10, Jan Lahoda wrote:
Thanks for the comment - done that. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/full/
Delta against the previous iteration:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.03/delta
On 30.6.2015 14:10, Alan Bateman wrote:
On 29/06/2015 12:25, Jan Lahoda wrote:
The library is Windows-only, but the WindowsTerminal (or its
subclasses) are registered on all platforms using
"WindowsTerminal.class". While this does not cause initialization, it
seemed safer to ensure t
On 30.6.2015 16:27, Alan Bateman wrote:
On 30/06/2015 14:54, Jan Lahoda wrote:
I've changed the registration to use a Callable to produce the
Terminal instances instead of registering the Terminal classes:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.05/full/
delta:
On 1.7.2015 16:43, Alan Bateman wrote:
On 30/06/2015 16:05, Jan Lahoda wrote:
We need to override these "settings" for jshell (we use subclasses of
WindowsTerminal/UnixTerminal to get e.g. Ctrl-C detection - not sure
if we will want to generalize these additional features for j
:
Hi,
Has this been tested with a JDK 9 compiler?
The last time I checked JLine wouldn't build with an OpenJDK 9 javac.
Thanks,
Ben
On 18 Jun 2015 3:26 pm, "Jan Lahoda" mailto:jan.lah...@oracle.com>> wrote:
Hello,
I am proposing to add JLine 2.12.1 into the jdk rep
On 1.7.2015 17:58, Jan Lahoda wrote:
On 1.7.2015 16:43, Alan Bateman wrote:
On 30/06/2015 16:05, Jan Lahoda wrote:
We need to override these "settings" for jshell (we use subclasses of
WindowsTerminal/UnixTerminal to get e.g. Ctrl-C detection - not sure
if we will want to genera
Hi Ståle,
When we were looking for editing libraries, JLine 2 looked best.
Unfortunately, we did not find Aesh.
At this stage, I think we should proceed with JLine (so the dependent
work can continue). Note that it is intended to be JDK internal-only, so
there's a possibility to change to a
Hi Mandy,
Regarding the javac changes - should those be switched on/off depending
the Target? Or, if one compiles with e.g. --release 14, will the newly
generated output still work on JDK 14?
Jan
On 27. 03. 20 0:57, Mandy Chung wrote:
Please review the implementation of JEP 371: Hidden Class
Hi Vicente,
javac changes look overall OK to me.
A few comments:
-the handling of non-sealed in JavacParser is fairly good, even though I
wonder if handling it in the tokenizer would not be better. If I read
the specification correctly, "non-sealed" is specified as a keyword, so
the tokenizer
On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote:
> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
> jdk.internal.lambda.disableEagerInitialization system property to be able to
> disable eager initialization of lambda
> classes. This was necessary to prevent
On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Wallnöfer wrote:
> This pull request is identical with the RFR previously sent for the Mercurial
> repository:
>
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
>
> I'm copy-pasting the comments from the original RFR below.
root
> modules, and would search the internals
> of other modules only if nothing would be found in the first round. The
> draft of the corresponding CSR is here:
> https://bugs.openjdk.java.net/browse/JDK-8253168.
Jan Lahoda has updated the pull request with a new target base due to a me
On Wed, 23 Sep 2020 02:32:46 GMT, Joe Darcy wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review comments - improving javadoc, avoid repeated search of
>> modules t
This is an update to javac and javadoc, to introduce support for Preview APIs,
and generally improve javac and javadoc
behavior to more closely adhere to JEP 12.
The notable changes are:
* adding support for Preview APIs (javac until now supported primarily only
preview language features, and
On Mon, 19 Oct 2020 14:22:17 GMT, Hannes Wallnöfer wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
>> line 2238:
>>
>>> 2236: if (previewTree != null) {
>>> 2237: previewDiv.add(new
>>> HtmlTree(TagName.A).put(
On Tue, 20 Oct 2020 03:02:03 GMT, Vicente Romero wrote:
>> This is the current proposed patch for the upcoming JEP 394, for pattern
>> matching for instanceof.
>>
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current s
On Tue, 20 Oct 2020 03:09:27 GMT, Vicente Romero wrote:
>> This is the current proposed patch for the upcoming JEP 394, for pattern
>> matching for instanceof.
>>
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current s
t;
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5]
> http://cr.openjdk.java.net/~jlahoda/8250768/
On Fri, 16 Oct 2020 16:47:25 GMT, Erik Joelsson wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains 35 commits:
>> - Merge branch 'JDK-8250768-dev' of https://github.co
d
> and encloses the VariableTree. The reason is better consistency in the API,
> with nodes like CatchTree, EnhancedForLoop
> Tree, etc.
>
> This change will not be integrated until JEP 394 is targetted.
Jan Lahoda has updated the pull request with a new target base due to a merg
On Wed, 21 Oct 2020 03:26:57 GMT, Vicente Romero wrote:
>> I believe plain jtreg invocations may not be always setting "-g". So
>> probably better to be explicitly clear we need -g, as the test itself
>> requires the debugging info/LocalVariableTable?
>
> sure I understand that the `-g` option
On Wed, 21 Oct 2020 03:11:28 GMT, Vicente Romero wrote:
>> Jan Lahoda 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 15 addi
d and encloses the VariableTree.
> The reason is better consistency in the API, with nodes like CatchTree,
> EnhancedForLoop Tree, etc.
>
> This change will not be integrated until JEP 394 is targetted.
Jan Lahoda has updated the pull request incrementally with one additional
On Wed, 21 Oct 2020 03:12:08 GMT, Vicente Romero wrote:
>> Jan Lahoda 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 15 addi
On Wed, 21 Oct 2020 03:13:34 GMT, Vicente Romero wrote:
>> Jan Lahoda 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 15 addi
d and encloses the VariableTree.
> The reason is better consistency in the API, with nodes like CatchTree,
> EnhancedForLoop Tree, etc.
>
> This change will not be integrated until JEP 394 is targetted.
Jan Lahoda has updated the pull request with a new target base due to a merge
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk.
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk
On Wed, 21 Oct 2020 15:25:59 GMT, Hannes Wallnöfer wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 35 commits:
>>
>> - Merge branch 'JDK-8250768-dev' of https://github.co
On Fri, 23 Oct 2020 17:22:33 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc
On Fri, 23 Oct 2020 18:28:12 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/t
On Fri, 23 Oct 2020 17:58:42 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc
On Fri, 23 Oct 2020 18:19:13 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/d
On Tue, 27 Oct 2020 16:11:18 GMT, Jan Lahoda wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
>> line 2980:
>>
>>> 2978: }
>>> 2979:
>>> 2980: public enum DeclarationPreviewLanguageFeatures {
&
d and encloses the VariableTree.
> The reason is better consistency in the API, with nodes like CatchTree,
> EnhancedForLoop Tree, etc.
>
> This change will not be integrated until JEP 394 is targetted.
Jan Lahoda has updated the pull request with a new target base due to a me
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk.ja
root modules, and would search the internals of
> other modules only if nothing would be found in the first round.
>
> The draft of the corresponding CSR is here:
> https://bugs.openjdk.java.net/browse/JDK-8253168.
Jan Lahoda has updated the pull request with a new target base due to a merge
On Wed, 16 Sep 2020 07:57:30 GMT, Jan Lahoda wrote:
> Unqualified Elements.getTypeElement(CharSequence) and
> Elements.getPackageElement(CharSequence) search for elements across all
> modules in the module graph, and only return a value when they find exactly
> one elem
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk.ja
On Mon, 2 Nov 2020 18:39:59 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK
On Mon, 2 Nov 2020 19:37:39 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK
On Mon, 2 Nov 2020 19:41:08 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK
On Mon, 2 Nov 2020 19:59:10 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK
d and encloses the VariableTree.
> The reason is better consistency in the API, with nodes like CatchTree,
> EnhancedForLoop Tree, etc.
>
> This change will not be integrated until JEP 394 is targetted.
Jan Lahoda has updated the pull request with a new target base due to a me
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk.ja
On Mon, 2 Nov 2020 20:21:44 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK
On Thu, 8 Oct 2020 11:49:17 GMT, Jan Lahoda wrote:
> This is the current proposed patch for the upcoming JEP 394, for pattern
> matching for instanceof.
>
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-fin
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk.ja
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openjdk.ja
On Wed, 4 Nov 2020 19:40:33 GMT, Jan Lahoda wrote:
>> I have read all the files.
>>
>> I have added a n umber of various minor non-blocking comments (no need for
>> re-review( to fix these. But I have a couple of comments/questions before
>> finally giving app
o go to the Preview
> page, the word DEPRECATED is highlighted in the top navbar instead of
> PREVIEW.
>
> -- Jon
>
>
> On 11/5/20 10:13 AM, mlbridge[bot] wrote:
>>
>> /Mailing list message from Alex Buckley
>> <mailto:alex.buck...@oracle.com> on
ahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
> [4]
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
> [6] https://bugs.openj
Hi,
This is a continuation of Joe's patch from here:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013498.html
APIs associated with preview features are split into two groups:
essential and non-essential. These are marked with an JDK-internal
annotation, PreviewFeature, and a
:
Hi Jan,
For future work, consider having a "Preview Methods" tag alongside
static, instance, deprecated, etc.
Cheers,
-Joe
On 10/3/2019 2:57 AM, Jan Lahoda wrote:
Hi,
This is a continuation of Joe's patch from here:
https://mail.openjdk.java.net/pipermail/compiler-dev/2
,
\
))
TARGETS += $(COPY_PREVIEW_FEATURES)
Then you automatically get all the corner case handling we have
implemented over the years for logging, making directories and copying
files. Your version is still correct for this case though.
/Erik
On 2019-10-03 02:57, Jan Lahoda wrote:
Hi,
This is a
robably be correct :)
but I’d appreciate an explanation on how this dependency is guaranteed.
Or maybe I’m misunderstanding what this is supposed to do?
/Magnus
8 okt. 2019 kl. 17:27 skrev Jan Lahoda :
Thanks for the new code Erik!
A new webrev/patch that includes this better way of copyi
afraid there is still a distinction between them - when --enable-preview
is not specified, use of essential APIs will lead to a compile time warning,
while use of non essential API (reflection, typically) only produces warnings.
Jan
>
>Maurizio
>
>On 16/10/2019 13:50, Jan Lahoda wro
/webrev.00/test/langtools/tools/jdeps/listdeps/ListModuleDeps.java.udiff.html
Which you explained to me offline (we need to change this code every
time the compiler stops using the @Preview annotation - ugh). Nothing
specific to this webrev, so I approve.
Maurizio
On 21/10/2019 14:49, Jan Lahoda
Looks good to me.
Jan
On 12. 11. 19 7:13, Joe Darcy wrote:
Hello,
To remove the need to modify tests when the JDK version is updated, the
tests of the preview API in String should use "${jdk.version}" as an
argument to -source rather than a fixed version string:
JDK-8233940: Preview A
Hi Vcente,
Overall, looks fine I think. A few comments on the javac implementation:
-in TypeEnter, I believe this:
memberEnter.memberEnter(tree.defs.diff(List.convert(JCTree.class,
defsBeforeAddingNewMembers)), env);
is unnecessary (and fairly slow). defsBeforeAddingNewMembers is
initialized to
Hi,
javac used to have an option, -Xmodule:, that allowed to compile given
sources as if they were part of the specified module.
This functionality has been merged into the --patch-module option, but
the -Xmodule: option couldn't be fully removed at that time, as some
tests and tools (e.g. j
The javac part looks OK to me.
A nit comment, in:
launcher/Main.java/MemoryFileManager#createInMemoryClassFile, there is:
return new FilterOutputStream(new ByteArrayOutputStream()) { ...
It could I think be written as:
return new ByteArrayOutputStream() {
@Override
public void close() th
Hi,
Under:
https://bugs.openjdk.java.net/browse/JDK-8194750
j.i.Console was changed to capture the state of the terminal echo at
creation time, and to restore it on shutdown.
That is problematic at least in jshell, where the terminal is already in
the raw mode when j.i.Console is created, an
em.console()
before going into raw mode? No, I'm not saying the proposed one is not a
good one,
just wanted to make sure I understand the situation correctly.
Thanks,
Sherman
On 4/25/18, 4:50 AM, Jan Lahoda wrote:
Hi,
Under:
https://bugs.openjdk.java.net/browse/JDK-8194750
j.i.Console
terminal to raw and then call
System.console()?
for example an alternative for this issue is to ask jshell's impl to call
System.console()
before going into raw mode? No, I'm not saying the proposed one is not a
good one,
just wanted to make sure I understand the situation correctly.
Tha
On 25.4.2018 22:59, Xueming Shen wrote:
On 04/25/2018 01:39 PM, Jan Lahoda wrote:
So, if I understand correctly, it would be:
boolean flipEcho;
and the readPassword would do something like:
if (echo0() != false) {
if (echo0()) { ...
flipEcho = true;
echo(false);
}
if (flipEcho
On 26.4.2018 20:09, Xueming Shen wrote:
On 4/26/18, 3:23 AM, Jan Lahoda wrote:
On 25.4.2018 22:59, Xueming Shen wrote:
On 04/25/2018 01:39 PM, Jan Lahoda wrote:
So, if I understand correctly, it would be:
boolean flipEcho;
and the readPassword would do something like:
if (echo0() != false
On 11.5.2018 12:31, Maurizio Cimadamore wrote:
Thumbs up - thanks for taking the comments into account.
Great job!
+1
Jan
Maurizio
On 04/05/18 22:59, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch
Single-File Source-Code Programs.
It includ
On Tue, 24 Nov 2020 23:00:05 GMT, Mandy Chung wrote:
>> I agree. This @apiNote needs more clarification to help the readers to
>> understand the context here.One thing we could do in the Package class
>> description to add a "Package Sealing" section that can also explain that it
>> has n
Adding support for record classes in the historical data for ct.sym. This
includes a few changes not strictly needed for the change:
-updating and moving tests into test/langtools, so that it is easier to run
them.
-fixing Record attribute reading in javac's ClassReader (used for tests, but
seem
This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>From the original PR:
> Please review the code for the second iteration of sealed classes. In this
> iteration we are:
>
> * Enhancing narrowing reference conversion to allow for stricter checking
> of cast conversions w
1 - 100 of 272 matches
Mail list logo
