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
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
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
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 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
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 was changed to capture the state of the terminal echo at
creation time, and to restore it on shutdown.
That is probl
()
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 was changed
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,
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()
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.
in the className, but for now
this seems acceptable to me.
Feedback is welcome.
Thanks!
Jan
On 7.2.2017 19:11, Jan Lahoda wrote:
Hi,
Thanks.
I did two small updates to the patches:
-for langtools repository, I added unwrapping to
ClientCodeWrapper.WrappedJavaFileManager.getLocationForModule
.01/
-jdk repository:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.02/
Thanks,
Jan
On 6.2.2017 21:42, Alan Bateman wrote:
On 06/02/2017 18:41, Jan Lahoda wrote:
I've updated the jdk repository webrev to wrap long lines:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/
Jan
This looks
I've updated the jdk repository webrev to wrap long lines:
http://cr.openjdk.java.net/~jlahoda/8173777/jdk.01/
Jan
On 6.2.2017 16:53, Jan Lahoda wrote:
Hi,
I'd like to ask for a review of a patch that merges the -Xmodule:
functionality into --patch-module. After this patch, the input source
Hi,
I'd like to ask for a review of a patch that merges the -Xmodule:
functionality into --patch-module. After this patch, the input source
files are matched against modules patched with --patch-module, and are
compiled as-if they were part of the module they are patching. (In the
Please review a change to how .inputrc is read. Currently, it uses
BufferedReader.readLine(), which interprets '\r' as a line separator,
and so the '\r' character cannot be used in the macros. The proposed
change is to use System.getProperty("line.separator") and "\n" as line
separators.
Hi Alan,
On 14.6.2016 12:57, Alan Bateman wrote:
On 13/06/2016 17:12, Jan Lahoda wrote:
Hello,
There is:
https://bugs.openjdk.java.net/browse/JDK-8153362
which is about a new warning that should be produced by javac when
exported API refers to types not exported/accessible to the API
hose files and submit
bugs against swing & accessibility and the area owner
can then make the decision as to the appropriate treatment.
You can keep the JDK buildable in the meanwhile by suppressing the
lint warnings on the desktop module.
-phil.
On 06/13/2016 09:12 AM, Jan Lahoda wrote
Hello,
There is:
https://bugs.openjdk.java.net/browse/JDK-8153362
which is about a new warning that should be produced by javac when
exported API refers to types not exported/accessible to the API clients.
I've put my current javac change here:
Hi Alan,
On 12.6.2016 20:51, Alan Bateman wrote:
On 10/06/2016 17:05, Jan Lahoda wrote:
The other Preferences implementations used this pattern, so I used it
as well. I don't have a problem with using double-checked locking.
Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8139507/webrev
Hi Alan,
Thanks for the comment, an answer is inlined.
On 10.6.2016 12:20, Alan Bateman wrote:
On 08/06/2016 18:39, Jan Lahoda wrote:
Hello,
When starting JShell on Windows, one may see a message like this:
?vn 08, 2016 6:46:35 ODP. java.util.prefs.WindowsPreferences
WARNING: Could
Hi,
Bug:
https://bugs.openjdk.java.net/browse/JDK-8157502
make docs appears to be currently broken, fails with:
---
# Running javadoc for support/javadoc/api/index.html
.../jdk/src/java.base/share/classes/java/lang/StrictMath.java:855:
error: reference not found
* @see
Hello,
In jshell, there's a special history mode that is intended to aid with
editing/re-entering multi-line snippets (EditingHistory). It works like
this: when the user goes back through the history to the first line of a
multi-line snippet, and enters/confirms that line, the history view is
Thanks - I've included both links and pushed.
Jan
On 4.5.2016 16:12, Florent Guillaume wrote:
On Wed, May 4, 2016 at 3:29 PM, Jan Lahoda <jan.lah...@oracle.com> wrote:
On 3.5.2016 14:58, Florent Guillaume wrote:
http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical
ref
n updated webrev.
Thanks,
s'marks
On 5/1/16 11:55 PM, Jan Lahoda wrote:
Hi Stuart,
Thanks for the comments and the link!
A webrev which includes the link is here:
http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/
Delta webrev to the last iteration is here:
http://cr.openjdk.java.net/
rminal.app
emits, at least for unshifted F1-F12. (The Terminal app was probably
copied from xterm.)
Thanks,
s'marks
[1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
On 1/22/16 3:41 AM, Jan Lahoda wrote:
Hello,
I'd like to enhance the WindowsTerminal in jdk.internal.le with
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 proposed pat
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:
Hi,
I
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
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.
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/
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
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 generalize
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 jjs as
well
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 the library
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:
http
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 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
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/webrev.01/full
for the 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
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 available here:
http
-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 patch is available here:
http
!
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/~jlahoda/8080679/webrev
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:
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
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 to use expected
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 jdk repositories. All
the uses I was able to find are in tests
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 identifier is used
Changeset: a746587a1ff1
Author:jlahoda
Date: 2013-12-03 18:50 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a746587a1ff1
8028699: Compiler crash during speculative attribution of annotated type
Summary: Moving the checkForDeclarationAnnotations check into
Changeset: 8acb838c9b79
Author:jlahoda
Date: 2013-11-26 15:27 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8acb838c9b79
8026374: javac accepts void as a method parameter
Summary: Changing Check.validate to reject void types.
Reviewed-by: jjg, vromero
!
Changeset: 7c89d200781b
Author:jlahoda
Date: 2013-11-20 13:44 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7c89d200781b
6557966: Multiple upper bounds of the TypeVariable
Summary: Adjusting javax.lang.model javadoc regarding IntersectionType,
IntersectionType.accept
Changeset: 6e0f31d61e56
Author:jlahoda
Date: 2013-11-09 15:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e0f31d61e56
8027142: Invokedynamic instructions don't get line number table entries
Summary: When emitting invokedynamic instruction, write pendingStatPos, if
Changeset: 75c8cde12ab6
Author:jlahoda
Date: 2013-11-06 17:48 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/75c8cde12ab6
8027281: Incorrect invokespecial generated for JCK lang
EXPR/expr636/expr63602m* tests
Summary: When invoking interface default method via a
Changeset: 8b4e1421a9b7
Author:jlahoda
Date: 2013-11-01 21:43 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b4e1421a9b7
8027310: Annotation Processor crashes with NPE
Summary: JCAnnotation.attribute is null when annotation type is unavailable
Reviewed-by: jjg,
Changeset: b05db8c815e8
Author:jlahoda
Date: 2013-10-23 07:50 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b05db8c815e8
8026508: Invokedynamic instructions don't get line number table entries
Summary: Setting or correcting positions for many trees produced by
Changeset: abc3eaccba73
Author:jlahoda
Date: 2013-10-23 23:02 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/abc3eaccba73
8027191: Fix for JDK-8026861 refers to an incorrect bug number
Summary: Reverting changeset b05db8c815e8, so that it can be applied again with
a
Changeset: 79649bf21a92
Author:jlahoda
Date: 2013-10-15 16:23 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79649bf21a92
8026180: com.sun.source.tree.NewArrayTree refers to
com.sun.tools.javac.util.List
Summary: Correcting import in NewArrayTree, adding test
Changeset: 19e8eebfbe52
Author:jlahoda
Date: 2013-10-15 22:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/19e8eebfbe52
8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing
Summary: A mostly automated rename Annotate.Annotator-Annotate.Worker
Changeset: 87b5bfef7edb
Author:jlahoda
Date: 2013-10-14 22:11 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87b5bfef7edb
8014016: javac is too late detecting invalid annotation usage
Summary: Adding new queue to Annotate for validation tasks, performing
annotation
Changeset: 872c4a898b38
Author:jlahoda
Date: 2013-10-11 15:49 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/872c4a898b38
6278240: Exception from AnnotationValue.getValue() should list the found type
not the required type
Reviewed-by: darcy, jfranck, jjg
!
Changeset: 0be3f1820e8b
Author:jlahoda
Date: 2013-10-09 13:06 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0be3f1820e8b
8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...)
Summary: Should not generate non-public $assertionsDisabled field into
Hi,
Please review the fix for bug JDK-7183985, bug:
https://bugs.openjdk.java.net/browse/JDK-7183985
webrev:
http://cr.openjdk.java.net/~jlahoda/7183985/webrev.00/
The problem, as I understand it, is as follows. Consider this code:
-
@WithArray({E.class})
class O {
}
Changeset: c13305cf8528
Author:jlahoda
Date: 2013-10-04 08:29 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c13305cf8528
8025118: Annotation processing api returns default modifier for interface
without default methods
Summary: TypeElement.getModifiers() should not
Changeset: b7d8b71e1658
Author:jlahoda
Date: 2013-09-27 17:28 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7d8b71e1658
8022765: Compiler crashes with exception on wrong usage of an annotation.
Summary: Error recovery for incorrect annotation attribute values -
Changeset: 9235ae08a449
Author:jlahoda
Date: 2013-09-26 20:07 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9235ae08a449
8025491: Javac regression test
tools/javac/T8003967/DetectMutableStaticFields.java failing
Summary: Making HtmlTree.NONENCODING_CHARS final
Changeset: 8d1c48de706d
Author:jlahoda
Date: 2013-09-19 17:05 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8d1c48de706d
8022567: Javac Should Generate Warnings For Raw Array Type
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Check.java
!
Changeset: 41599b57d262
Author:jlahoda
Date: 2013-09-20 16:33 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/41599b57d262
8023835: TreeMaker.QualIdent() too leafy
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+
201 - 267 of 267 matches
Mail list logo
