* jdk/make/lib/Lib-jdk.jline.gmk
has copyright year 2011, 2015 despite being a new file. Any
specific reason?
* jdk.jline depends on java.desktop. Is that needed by the code by jline
code? I am asking because Nashorn requires only "compact 1" profile so
far and so can be used on compact
On 18.6.2015 16:40, A. Sundararajan wrote:
* jdk/make/lib/Lib-jdk.jline.gmk
has copyright year 2011, 2015 despite being a new file. Any
specific reason?
I copied one of the existing files in the directory to just adjusted it
for jdk.jline. So I kept the copyright years there - what is t
My understanding is that the new file won't have old copyright year
(2011 in this case).
-Sundar
On Thursday 18 June 2015 09:20 PM, Jan Lahoda wrote:
On 18.6.2015 16:40, A. Sundararajan wrote:
* jdk/make/lib/Lib-jdk.jline.gmk
has copyright year 2011, 2015 despite being a new file. Any
> My understanding is that the new file won't have old copyright year
> (2011 in this case).
Agreed.
Thanks,
iris
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" wrote:
> Hello,
>
> I am proposing to add JLine 2.12.1 into the jdk repository for use by the
> Java and Nashorn REPLs. Full p
Hello Jan,
Build changes look mostly ok. Some notes:
* "$(CFLAGS_WARNINGS_ARE_ERRORS)", which should not be used anymore.
Warnings are already treated as errors globally.
* There should not be a need to add "-I$(INCLUDEDIR)
-I$(JDK_OUTPUTDIR)/include/$(OPENJDK_TARGET_OS)" to cflags. INCLUDED
Hi Erik,
Thanks for the comments. Yes, I copied an existing file, and -DUSE_MMAP
seems unnecessary. I'll implement your suggestions.
Thanks,
Jan
On 22.6.2015 10:25, Erik Joelsson wrote:
Hello Jan,
Build changes look mostly ok. Some notes:
* "$(CFLAGS_WARNINGS_ARE_ERRORS)", which should
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/
Notable changes:
-avoided the dependency on java.desktop and java.datatransfer
-adjusted the native library build script as per Erik's r
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/
Notable changes:
-avoided the dependency on java.desktop and java.datatransfer
-adjusted the n
Hello Jan,
Build changes look good.
/Erik
On 2015-06-25 18: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/
Notable changes:
-avoided the dependency on java.de
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/
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 also be more
I will work on this.
Related to this is
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/8080679/webrev.02/delta/
Any feedback on this would be appreciated!
Thanks for the
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/8080679/webrev.02/delta/
Any feedback on th
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/8080
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/
How does this look? Feedback is appreciate
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/
H
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/
H
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 is only loaded when needed.
This see
On 29/06/2015 14:16, Jan Lahoda wrote:
I did not realize that - updated webrev:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.04/full/
Delta against previous iteration:
http://cr.openjdk.java.net/~jlahoda/8080679/webrev.04/delta/
Feedback is appreciated.
This delta change addresses my c
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
Hi Jay,
instead of
Callable sup = FLAVORS.get(flavor);
if (sup != null) {
return sup.call();
}
throw new InternalError();
you can write it as a one liner with getOrDefault:
FLAVORS.getOrDefault(flavor, () -> { throw new InternalEror(); }).call();
cheers,
Rémi
On 06/30/2015 03:54 PM, Jan L
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://cr.openjdk.java.net/~jlahoda/8080679/webrev.05/delta
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://cr.openjdk.ja
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). Is there a way to override them (just)
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). Is
Hi Ben,
(Sorry for a late answer.)
Yes, this builds with JDK 9 compiler as part of the JDK build. JLine's
own build is uses -source/-target 1.5, which is no longer supported in
JDK 9 javac, so this may be one of the issues there.
Thanks,
Jan
On 18.6.2015 22:01, Ben Evans wrote:
Hi,
Ha
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 these ad
hi, sorry, im a bit late to this discussion, i wasnt aware of any
interest for adding jline2 to the jdk until late this week.
im working on a project called æsh/aesh: https://github.com/aeshell/aesh
its another java console project derived from jline/jline2. it started
as an extension/fork of jlin
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
30 matches
Mail list logo
