From bitterfoxc at gmail.com  Mon Jun  1 12:57:35 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 1 Jun 2015 21:57:35 +0900
Subject: RFR 8081276: JShell tool: Completion contains nested class
	reference on instance variable
In-Reply-To: <CAHjBcHNrXyvgFiBXGbDz_tu=EPaYGhUPg2oB7_Snmi04pmhzTg@mail.gmail.com>
References: <CAHjBcHNrXyvgFiBXGbDz_tu=EPaYGhUPg2oB7_Snmi04pmhzTg@mail.gmail.com>
Message-ID: <CAHjBcHO1OM280EbBR91-x=sSqBBbUtqjiLLfUo-gENnph=JV1g@mail.gmail.com>

ping...

Could you review?
2015/05/28 11:32 "ShinyaYoshida" <bitterfoxc at gmail.com>:

> Hi Jan,
> Could you review this patch?
>
> bugs:
> https://bugs.openjdk.java.net/browse/JDK-8081276
>
> webrev:
> http://cr.openjdk.java.net/~shinyafox/kulla/8081276/webrev.00/
>
> Regards,
> shinyafox(Shinya Yoshida)
>

From jan.lahoda at oracle.com  Mon Jun  1 13:20:06 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 01 Jun 2015 15:20:06 +0200
Subject: RFR 8081276: JShell tool: Completion contains nested class
	reference on instance variable
In-Reply-To: <CAHjBcHO1OM280EbBR91-x=sSqBBbUtqjiLLfUo-gENnph=JV1g@mail.gmail.com>
References: <CAHjBcHNrXyvgFiBXGbDz_tu=EPaYGhUPg2oB7_Snmi04pmhzTg@mail.gmail.com>
	<CAHjBcHO1OM280EbBR91-x=sSqBBbUtqjiLLfUo-gENnph=JV1g@mail.gmail.com>
Message-ID: <556C5C06.1080304@oracle.com>

Shinya,

Seems fine, please push. Thanks!

Jan

On 1.6.2015 14:57, ShinyaYoshida wrote:
> ping...
>
> Could you review?
>
> 2015/05/28 11:32 "ShinyaYoshida" <bitterfoxc at gmail.com
> <mailto:bitterfoxc at gmail.com>>:
>
>     Hi Jan,
>     Could you review this patch?
>
>     bugs:
>     https://bugs.openjdk.java.net/browse/JDK-8081276
>
>     webrev:
>     http://cr.openjdk.java.net/~shinyafox/kulla/8081276/webrev.00/
>
>     Regards,
>     shinyafox(Shinya Yoshida)
>

From bitterfoxc at gmail.com  Mon Jun  1 13:35:55 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 1 Jun 2015 22:35:55 +0900
Subject: RFR 8081276: JShell tool: Completion contains nested class
	reference on instance variable
In-Reply-To: <556C5C06.1080304@oracle.com>
References: <CAHjBcHNrXyvgFiBXGbDz_tu=EPaYGhUPg2oB7_Snmi04pmhzTg@mail.gmail.com>
	<CAHjBcHO1OM280EbBR91-x=sSqBBbUtqjiLLfUo-gENnph=JV1g@mail.gmail.com>
	<556C5C06.1080304@oracle.com>
Message-ID: <CAHjBcHOSZMrwqpD0k-2ZV603n1vqd0dGoL2E+q84cjd_21_orw@mail.gmail.com>

Thank you for your review.

I'll push.

Regards,
shinyafox(Shinya Yoshida)

2015-06-01 22:20 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Shinya,
>
> Seems fine, please push. Thanks!
>
> Jan
>
> On 1.6.2015 14:57, ShinyaYoshida wrote:
>
>> ping...
>>
>> Could you review?
>>
>> 2015/05/28 11:32 "ShinyaYoshida" <bitterfoxc at gmail.com
>> <mailto:bitterfoxc at gmail.com>>:
>>
>>     Hi Jan,
>>     Could you review this patch?
>>
>>     bugs:
>>     https://bugs.openjdk.java.net/browse/JDK-8081276
>>
>>     webrev:
>>     http://cr.openjdk.java.net/~shinyafox/kulla/8081276/webrev.00/
>>
>>     Regards,
>>     shinyafox(Shinya Yoshida)
>>
>>

From bitterfoxc at gmail.com  Mon Jun  1 13:39:50 2015
From: bitterfoxc at gmail.com (bitterfoxc at gmail.com)
Date: Mon, 01 Jun 2015 13:39:50 +0000
Subject: hg: kulla/dev/langtools: 8081276: JShell tool: Completion contains
	nested class reference on instance variable
Message-ID: <201506011339.t51DdopR003703@aojmv0008.oracle.com>

Changeset: 060b43145aa8
Author:    shinyafox
Date:      2015-06-01 22:37 +0900
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/060b43145aa8

8081276: JShell tool: Completion contains nested class reference on instance variable
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! test/jdk/jshell/CompletionSuggestionTest.java


From brian.goetz at oracle.com  Mon Jun  1 15:57:56 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 01 Jun 2015 11:57:56 -0400
Subject: Kulla API changes: shifting to events
In-Reply-To: <55679678.60303@oracle.com>
References: <55677A59.8010909@oracle.com> <55677AC0.1060202@oracle.com>
	<55679678.60303@oracle.com>
Message-ID: <556C8104.6040800@oracle.com>

> It will have event registration and at least initially and probably
> permanently a List of events would be returned by eval() -- presumably
> with value/exception -- and by drop().

There are a few degrees of freedom in event/listener management.

  - Are events unicast or multicast?  (i.e., what does it mean if you 
call onEvent(Consumer<Event>) twice?  does the second call replace the 
first, or do both listeners get the event?)
  - If events are multicast (the most common interpretation), how do you 
unsubscribe?
  - How fine-grained are event subscriptions?

You've talked about leaving room for a "plugin" mechanism in the future. 
  Presumably the plugin would be provided access to the REPL state.  And 
then it might want to attach its own listeners.

The historical view of listener support (from the Beans days) relies on 
the identity of the listener; if you pass a listener to unsubscribe(), 
it is removed from the list.  But, this is not a very lambda-friendly 
mechanism, as you can't count on the identity of a lambda.  So a more 
lambda-friendly API might be:

     SubscriptionToken subscribe(listener)
     void unsubscribe(subscriptionToken)


From robert.field at oracle.com  Mon Jun  1 16:10:21 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 01 Jun 2015 09:10:21 -0700
Subject: Kulla API changes: shifting to events
In-Reply-To: <556C8104.6040800@oracle.com>
References: <55677A59.8010909@oracle.com> <55677AC0.1060202@oracle.com>
	<55679678.60303@oracle.com> <556C8104.6040800@oracle.com>
Message-ID: <556C83ED.9020804@oracle.com>

I keep trying to steer away from complexity.  For our needs unicast is 
enough, actually better since it is simpler.
Would it be a reasonably approach to provide unicast and for those that 
need it they can add their own multiplexing on top?

Another perspective is that, for our current tool/testing needs, there 
is no need to unsubscribe, so never dealing with tokens, letting them 
fall on the ground, is fine.

-Robert



On 06/01/15 08:57, Brian Goetz wrote:
>> It will have event registration and at least initially and probably
>> permanently a List of events would be returned by eval() -- presumably
>> with value/exception -- and by drop().
>
> There are a few degrees of freedom in event/listener management.
>
>  - Are events unicast or multicast?  (i.e., what does it mean if you 
> call onEvent(Consumer<Event>) twice?  does the second call replace the 
> first, or do both listeners get the event?)
>  - If events are multicast (the most common interpretation), how do 
> you unsubscribe?
>  - How fine-grained are event subscriptions?
>
> You've talked about leaving room for a "plugin" mechanism in the 
> future.  Presumably the plugin would be provided access to the REPL 
> state.  And then it might want to attach its own listeners.
>
> The historical view of listener support (from the Beans days) relies 
> on the identity of the listener; if you pass a listener to 
> unsubscribe(), it is removed from the list.  But, this is not a very 
> lambda-friendly mechanism, as you can't count on the identity of a 
> lambda.  So a more lambda-friendly API might be:
>
>     SubscriptionToken subscribe(listener)
>     void unsubscribe(subscriptionToken)
>


From brian.goetz at oracle.com  Mon Jun  1 16:47:15 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 01 Jun 2015 12:47:15 -0400
Subject: Kulla API changes: shifting to events
In-Reply-To: <556C83ED.9020804@oracle.com>
References: <55677A59.8010909@oracle.com> <55677AC0.1060202@oracle.com>
	<55679678.60303@oracle.com> <556C8104.6040800@oracle.com>
	<556C83ED.9020804@oracle.com>
Message-ID: <556C8C93.9080409@oracle.com>

I'm generally in favor of starting simple and working up as well -- as 
long as it can be scaled up. On the other hand, I worry about setting 
out roadblocks that will, for example, make a plugin approach impractical.

I think the token approach is a good compromise on that ground; as you 
say, simple clients can let them fall on the floor.

Multicast is not really that complex to implement; instead of:

   Consumer listener;
   ...
   if (listener != null)
       listener.accept(event)

we would have

   List<Consumer> listeners;
   listeners.forEach(l -> l.accept(event));

(actually both cases probably want a try .. catch around the accept 
invocation, to protect against listeners that throw NPEs and such.)


A more interesting question is how to divide up the event space.  IIRC, 
there are currently two kinds of events:
  - entity state transition events
  - remote process termination events

There are lots of kinds of entities and transitions; is one bucket for 
these enough (probably).  But its worth brainstorming over what other 
events might be added in the future, just to ensure we have a scalable 
API idiom.







On 6/1/2015 12:10 PM, Robert Field wrote:
> I keep trying to steer away from complexity.  For our needs unicast is
> enough, actually better since it is simpler.
> Would it be a reasonably approach to provide unicast and for those that
> need it they can add their own multiplexing on top?
>
> Another perspective is that, for our current tool/testing needs, there
> is no need to unsubscribe, so never dealing with tokens, letting them
> fall on the ground, is fine.
>
> -Robert
>
>
>
> On 06/01/15 08:57, Brian Goetz wrote:
>>> It will have event registration and at least initially and probably
>>> permanently a List of events would be returned by eval() -- presumably
>>> with value/exception -- and by drop().
>>
>> There are a few degrees of freedom in event/listener management.
>>
>>  - Are events unicast or multicast?  (i.e., what does it mean if you
>> call onEvent(Consumer<Event>) twice?  does the second call replace the
>> first, or do both listeners get the event?)
>>  - If events are multicast (the most common interpretation), how do
>> you unsubscribe?
>>  - How fine-grained are event subscriptions?
>>
>> You've talked about leaving room for a "plugin" mechanism in the
>> future.  Presumably the plugin would be provided access to the REPL
>> state.  And then it might want to attach its own listeners.
>>
>> The historical view of listener support (from the Beans days) relies
>> on the identity of the listener; if you pass a listener to
>> unsubscribe(), it is removed from the list.  But, this is not a very
>> lambda-friendly mechanism, as you can't count on the identity of a
>> lambda.  So a more lambda-friendly API might be:
>>
>>     SubscriptionToken subscribe(listener)
>>     void unsubscribe(subscriptionToken)
>>
>

From bitterfoxc at gmail.com  Tue Jun  2 04:12:32 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 2 Jun 2015 13:12:32 +0900
Subject: RFR 8081638: JShell tool: Improve completion for static import
Message-ID: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>

Hi Jan,
Please review this patch:

webrev:
http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.00/

bugs:
https://bugs.openjdk.java.net/browse/JDK-8081638

Regards,
shinyafox(Shinya Yoshida)

From jan.lahoda at oracle.com  Tue Jun  2 05:00:14 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Tue, 02 Jun 2015 05:00:14 +0000
Subject: hg: kulla/dev/langtools: Removing references to JLINE2LIB variable
	from developer scripts;
	adding build-jar script to build a standalone repl.jar
Message-ID: <201506020500.t5250EIG004574@aojmv0008.oracle.com>

Changeset: 1ac7284ef3bd
Author:    jlahoda
Date:      2015-06-02 07:00 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/1ac7284ef3bd

Removing references to JLINE2LIB variable from developer scripts; adding build-jar script to build a standalone repl.jar

+ repl/scripts/build-jar.sh
! repl/scripts/compile.sh
! repl/scripts/run.sh
! repl/scripts/stress.sh
! repl/scripts/test.sh


From robert.field at oracle.com  Tue Jun  2 06:02:19 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 02 Jun 2015 06:02:19 +0000
Subject: hg: kulla/dev/langtools: Fix wall of warnings on build
Message-ID: <201506020602.t5262JCl015001@aojmv0008.oracle.com>

Changeset: 53f5c7fc26fc
Author:    rfield
Date:      2015-06-01 22:58 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/53f5c7fc26fc

Fix wall of warnings on build

! test/jdk/jshell/CompletionSuggestionTest.java


From jan.lahoda at oracle.com  Tue Jun  2 07:19:02 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Tue, 02 Jun 2015 07:19:02 +0000
Subject: hg: kulla/dev/jdk: Resolving warnings in jline.
Message-ID: <201506020719.t527J2pj026297@aojmv0008.oracle.com>

Changeset: d5665fffc137
Author:    jlahoda
Date:      2015-06-02 09:16 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/jdk/rev/d5665fffc137

Resolving warnings in jline.

! src/jdk.jline/share/classes/jdk/internal/jline/console/ConsoleReader.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/UserInterruptException.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/completer/EnumCompleter.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/internal/ConsoleReaderInputStream.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/internal/ConsoleRunner.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/TerminalLineSettings.java


From jan.lahoda at oracle.com  Tue Jun  2 07:20:19 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Tue, 02 Jun 2015 07:20:19 +0000
Subject: hg: kulla/dev: 2 new changesets
Message-ID: <201506020720.t527KJ1t026557@aojmv0008.oracle.com>

Changeset: 2bf730bf4c6e
Author:    jlahoda
Date:      2015-05-31 11:47 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/rev/2bf730bf4c6e

Removing unused class

! make/CompileJavaModules.gmk

Changeset: bd5e490ebc9e
Author:    jlahoda
Date:      2015-06-02 09:17 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/rev/bd5e490ebc9e

jline should be without warnings

! make/CompileJavaModules.gmk


From andrei.eremeev at oracle.com  Tue Jun  2 09:01:59 2015
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Tue, 02 Jun 2015 12:01:59 +0300
Subject: hg: kulla/dev: 2 new changesets
In-Reply-To: <201506020720.t527KJ1t026557@aojmv0008.oracle.com>
References: <201506020720.t527KJ1t026557@aojmv0008.oracle.com>
Message-ID: <556D7107.5030206@oracle.com>

Hi Jan,

I have the following errors when I try to execute scripts/test.sh on 
Ubuntu 14.04.

../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:12: 
error: package org.fusesource.jansi does not exist
import org.fusesource.jansi.AnsiConsole;
                            ^
../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:13: 
error: package org.fusesource.jansi does not exist
import org.fusesource.jansi.AnsiOutputStream;
                            ^
../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:14: 
error: package org.fusesource.jansi does not exist
import org.fusesource.jansi.WindowsAnsiOutputStream;
                            ^
../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:45: 
error: cannot find symbol
                 return new WindowsAnsiOutputStream(stream);
                            ^
   symbol:   class WindowsAnsiOutputStream
   location: class AnsiWindowsTerminal
../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:51: 
error: cannot find symbol
             return new AnsiOutputStream(stream);
                        ^
   symbol:   class AnsiOutputStream
   location: class AnsiWindowsTerminal
../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:57: 
error: cannot find symbol
         OutputStream out = AnsiConsole.wrapOutputStream(new 
ByteArrayOutputStream());
                            ^
   symbol:   variable AnsiConsole
   location: class AnsiWindowsTerminal
../../jdk/src/jdk.jline/share/classes/jdk/internal/jline/AnsiWindowsTerminal.java:64: 
error: cannot find symbol
         return out instanceof WindowsAnsiOutputStream;
                               ^
   symbol:   class WindowsAnsiOutputStream
   location: class AnsiWindowsTerminal

Andrei Eremeev

On 06/02/2015 10:20 AM, jan.lahoda at oracle.com wrote:
> Changeset: 2bf730bf4c6e
> Author:    jlahoda
> Date:      2015-05-31 11:47 +0200
> URL:       http://hg.openjdk.java.net/kulla/dev/rev/2bf730bf4c6e
>
> Removing unused class
>
> ! make/CompileJavaModules.gmk
>
> Changeset: bd5e490ebc9e
> Author:    jlahoda
> Date:      2015-06-02 09:17 +0200
> URL:       http://hg.openjdk.java.net/kulla/dev/rev/bd5e490ebc9e
>
> jline should be without warnings
>
> ! make/CompileJavaModules.gmk
>


From andrei.eremeev at oracle.com  Tue Jun  2 13:14:33 2015
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Tue, 02 Jun 2015 16:14:33 +0300
Subject: Clarification for StatusTransitionEvent
Message-ID: <556DAC39.5070708@oracle.com>

Hi Robert,

Could you say what the correct behavior of StatusTransitionEvent's 
isSignatureChanged is? When must it be true?
Please, look at the ReplaceTest#testLocalClassEvolve . I think the 
signature of the method /j /must not be changed unless it is not firstly 
defined or the signature is changed, but it does.

Andrei Eremeev

From andrei.eremeev at oracle.com  Tue Jun  2 13:19:18 2015
From: andrei.eremeev at oracle.com (andrei.eremeev at oracle.com)
Date: Tue, 02 Jun 2015 13:19:18 +0000
Subject: hg: kulla/dev/langtools: 8081617: JShell tests: adjust methods
	assertKeyMatch and etc.; ...
Message-ID: <201506021319.t52DJIXR029711@aojmv0008.oracle.com>

Changeset: e7d6b70176ad
Author:    aeremeev
Date:      2015-06-02 16:18 +0300
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/e7d6b70176ad

8081617: JShell tests: adjust methods assertKeyMatch and etc.
8081551: JShell API: remove Outcome and Result.updates

! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/ErrorTranslationTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ModifiersTest.java
! test/jdk/jshell/RejectedFailedTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/ShutdownTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/TypeNameTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Tue Jun  2 14:26:06 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 02 Jun 2015 07:26:06 -0700
Subject: Clarification for StatusTransitionEvent
In-Reply-To: <556DAC39.5070708@oracle.com>
References: <556DAC39.5070708@oracle.com>
Message-ID: <14db4aa3c48.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

The name might be ambiguous.  This is analogous to what Replaced was 
before.  For a variable, that would be type changed. For a method, full 
signature including return type -- which is different than parameter types 
which is what Key uses.

-Robert




On June 2, 2015 6:15:23 AM "andrei.eremeev" <andrei.eremeev at oracle.com> wrote:

> Hi Robert,
>
> Could you say what the correct behavior of StatusTransitionEvent's
> isSignatureChanged is? When must it be true?
> Please, look at the ReplaceTest#testLocalClassEvolve . I think the
> signature of the method /j /must not be changed unless it is not firstly
> defined or the signature is changed, but it does.
>
> Andrei Eremeev



From jan.lahoda at oracle.com  Wed Jun  3 08:51:06 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 03 Jun 2015 10:51:06 +0200
Subject: RFR 8081638: JShell tool: Improve completion for static import
In-Reply-To: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>
References: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>
Message-ID: <556EBFFA.8000005@oracle.com>

Hi Shinya,

Overall looks good, thanks! Two comments:
-it seems that it might make sense to create a single method that would 
for a TreePath look up the enclosing ImportTree, if any, and that would 
be used in the other methods. Something like:
     public ImportTree findImport(TreePath tp) {
         switch (tp.getParentPath().getLeaf().getKind()) {
         case MEMBER_SELECT:
             return findImport(tp.getParentPath());
         case IMPORT:
             return (ImporTree) tp.getLeaf();
         default:
             return null;
         }
     }

And this would then be used to detect if TreePath is inside the import 
(isImport) and to detect static imports. Note there is another usecase 
for such detection in computeSuggestions in the IDENTIFIER identifier 
section.

-membersOf has parameter isStaticContext, which in fact mean 
"shouldGenerateDotClassItem" - would it make sense to rename the parameter?

Thanks,
    Jan

On 2.6.2015 06:12, ShinyaYoshida wrote:
> Hi Jan,
> Please review this patch:
>
> webrev:
> http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.00/
>
> bugs:
> https://bugs.openjdk.java.net/browse/JDK-8081638
>
> Regards,
> shinyafox(Shinya Yoshida)
>

From bitterfoxc at gmail.com  Wed Jun  3 09:21:27 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 3 Jun 2015 18:21:27 +0900
Subject: RFR 8081638: JShell tool: Improve completion for static import
In-Reply-To: <556EBFFA.8000005@oracle.com>
References: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>
	<556EBFFA.8000005@oracle.com>
Message-ID: <CAHjBcHPkO-ur5i6-3fQ5n7nn7F0PExWRLRNOS_PcUNEaYkujNA@mail.gmail.com>

Hi Jan,
Thank you for your review.

2015-06-03 17:51 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Hi Shinya,
>
> Overall looks good, thanks! Two comments:
> -it seems that it might make sense to create a single method that would
> for a TreePath look up the enclosing ImportTree, if any, and that would be
> used in the other methods. Something like:
>     public ImportTree findImport(TreePath tp) {
>         switch (tp.getParentPath().getLeaf().getKind()) {
>         case MEMBER_SELECT:
>             return findImport(tp.getParentPath());
>         case IMPORT:
>             return (ImporTree) tp.getLeaf();
>         default:
>             return null;
>         }
>     }
>
> And this would then be used to detect if TreePath is inside the import
> (isImport) and to detect static imports. Note there is another usecase for
> such detection in computeSuggestions in the IDENTIFIER identifier section.
>
Ok, I'll fix!


> -membersOf has parameter isStaticContext, which in fact mean
> "shouldGenerateDotClassItem" - would it make sense to rename the parameter?
>
Certainly, I'll rename.

Regards,
shinyafox(Shinya Yoshida)


>
> Thanks,
>    Jan
>
>
> On 2.6.2015 06:12, ShinyaYoshida wrote:
>
>> Hi Jan,
>> Please review this patch:
>>
>> webrev:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.00/
>>
>> bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8081638
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>

From bitterfoxc at gmail.com  Wed Jun  3 09:40:15 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 3 Jun 2015 18:40:15 +0900
Subject: Bug: Infinite loop in redeclare by cross reference
Message-ID: <CAHjBcHNO=qw9m_8dKxiSmaJnXocYCm4S9tz3exs74q7C2J8L7Q@mail.gmail.com>

Hi Robert,
I found the infinite loop situation:
-> class C {}
-> class D {C c;}

-> class C {D d;}
^- Infinite loop by cross reference - StackOverflowException

I filed this issue:
https://bugs.openjdk.java.net/browse/JDK-8081796

Test case will be such as:
assertEval1("class C {}");
assertEval1("class D {C c;}");
assertEval1("class C {D d;}");
assertEval1("new D().c = new C()");
assertEval1("new C().d = new D()");

Regards,
shinyafox(Shinya Yoshida)

From bitterfoxc at gmail.com  Wed Jun  3 09:47:23 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 3 Jun 2015 18:47:23 +0900
Subject: RFR 8081638: JShell tool: Improve completion for static import
In-Reply-To: <CAHjBcHPkO-ur5i6-3fQ5n7nn7F0PExWRLRNOS_PcUNEaYkujNA@mail.gmail.com>
References: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>
	<556EBFFA.8000005@oracle.com>
	<CAHjBcHPkO-ur5i6-3fQ5n7nn7F0PExWRLRNOS_PcUNEaYkujNA@mail.gmail.com>
Message-ID: <CAHjBcHP8bqFX9gD15O+v9FU4L=xRSkCVMzjzTKFa08wGkYN3JA@mail.gmail.com>

I've updated my patch:
http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.01/

Please do again!

Regards,
shinyafox(Shinya Yoshida)

2015-06-03 18:21 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com>:

> Hi Jan,
> Thank you for your review.
>
> 2015-06-03 17:51 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
>
>> Hi Shinya,
>>
>> Overall looks good, thanks! Two comments:
>> -it seems that it might make sense to create a single method that would
>> for a TreePath look up the enclosing ImportTree, if any, and that would be
>> used in the other methods. Something like:
>>     public ImportTree findImport(TreePath tp) {
>>         switch (tp.getParentPath().getLeaf().getKind()) {
>>         case MEMBER_SELECT:
>>             return findImport(tp.getParentPath());
>>         case IMPORT:
>>             return (ImporTree) tp.getLeaf();
>>         default:
>>             return null;
>>         }
>>     }
>>
>> And this would then be used to detect if TreePath is inside the import
>> (isImport) and to detect static imports. Note there is another usecase for
>> such detection in computeSuggestions in the IDENTIFIER identifier section.
>>
> Ok, I'll fix!
>
>
>> -membersOf has parameter isStaticContext, which in fact mean
>> "shouldGenerateDotClassItem" - would it make sense to rename the parameter?
>>
> Certainly, I'll rename.
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
>>
>> Thanks,
>>    Jan
>>
>>
>> On 2.6.2015 06:12, ShinyaYoshida wrote:
>>
>>> Hi Jan,
>>> Please review this patch:
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.00/
>>>
>>> bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8081638
>>>
>>> Regards,
>>> shinyafox(Shinya Yoshida)
>>>
>>>
>

From jan.lahoda at oracle.com  Wed Jun  3 11:27:00 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 03 Jun 2015 13:27:00 +0200
Subject: RFR 8081638: JShell tool: Improve completion for static import
In-Reply-To: <CAHjBcHP8bqFX9gD15O+v9FU4L=xRSkCVMzjzTKFa08wGkYN3JA@mail.gmail.com>
References: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>	<556EBFFA.8000005@oracle.com>	<CAHjBcHPkO-ur5i6-3fQ5n7nn7F0PExWRLRNOS_PcUNEaYkujNA@mail.gmail.com>
	<CAHjBcHP8bqFX9gD15O+v9FU4L=xRSkCVMzjzTKFa08wGkYN3JA@mail.gmail.com>
Message-ID: <556EE484.2070000@oracle.com>

Looks fine to me, please push.

Thanks!

Jan

On 3.6.2015 11:47, ShinyaYoshida wrote:
> I've updated my patch:
> http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.01/
>
> Please do again!
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2015-06-03 18:21 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
> <mailto:bitterfoxc at gmail.com>>:
>
>     Hi Jan,
>     Thank you for your review.
>
>     2015-06-03 17:51 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>     <mailto:jan.lahoda at oracle.com>>:
>
>         Hi Shinya,
>
>         Overall looks good, thanks! Two comments:
>         -it seems that it might make sense to create a single method
>         that would for a TreePath look up the enclosing ImportTree, if
>         any, and that would be used in the other methods. Something like:
>              public ImportTree findImport(TreePath tp) {
>                  switch (tp.getParentPath().getLeaf().getKind()) {
>                  case MEMBER_SELECT:
>                      return findImport(tp.getParentPath());
>                  case IMPORT:
>                      return (ImporTree) tp.getLeaf();
>                  default:
>                      return null;
>                  }
>              }
>
>         And this would then be used to detect if TreePath is inside the
>         import (isImport) and to detect static imports. Note there is
>         another usecase for such detection in computeSuggestions in the
>         IDENTIFIER identifier section.
>
>     Ok, I'll fix!
>
>         -membersOf has parameter isStaticContext, which in fact mean
>         "shouldGenerateDotClassItem" - would it make sense to rename the
>         parameter?
>
>     Certainly, I'll rename.
>
>     Regards,
>     shinyafox(Shinya Yoshida)
>
>
>         Thanks,
>             Jan
>
>
>         On 2.6.2015 06:12, ShinyaYoshida wrote:
>
>             Hi Jan,
>             Please review this patch:
>
>             webrev:
>             http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.00/
>
>             bugs:
>             https://bugs.openjdk.java.net/browse/JDK-8081638
>
>             Regards,
>             shinyafox(Shinya Yoshida)
>
>
>

From bitterfoxc at gmail.com  Wed Jun  3 16:04:29 2015
From: bitterfoxc at gmail.com (bitterfoxc at gmail.com)
Date: Wed, 03 Jun 2015 16:04:29 +0000
Subject: hg: kulla/dev/langtools: 8081638: JShell tool: Improve completion for
	static import
Message-ID: <201506031604.t53G4Tk0023371@aojmv0008.oracle.com>

Changeset: ddd8e5ac9dc0
Author:    shinyafox
Date:      2015-06-04 00:59 +0900
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/ddd8e5ac9dc0

8081638: JShell tool: Improve completion for static import
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! test/jdk/jshell/CompletionSuggestionTest.java


From bitterfoxc at gmail.com  Wed Jun  3 16:04:57 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 4 Jun 2015 01:04:57 +0900
Subject: RFR 8081638: JShell tool: Improve completion for static import
In-Reply-To: <556EE484.2070000@oracle.com>
References: <CAHjBcHPhqsBhu-qUOJKCa-t2MQT9L8dpA1WQbVOe5=gHjZVoUA@mail.gmail.com>
	<556EBFFA.8000005@oracle.com>
	<CAHjBcHPkO-ur5i6-3fQ5n7nn7F0PExWRLRNOS_PcUNEaYkujNA@mail.gmail.com>
	<CAHjBcHP8bqFX9gD15O+v9FU4L=xRSkCVMzjzTKFa08wGkYN3JA@mail.gmail.com>
	<556EE484.2070000@oracle.com>
Message-ID: <CAHjBcHNsWb+0Gb9+3=n9aidrMKGMgTiEUjXJ-_CobQUvAN_K_Q@mail.gmail.com>

I've pushed.

Thank you,
shinyafox(Shinya Yoshida)

2015-06-03 20:27 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Looks fine to me, please push.
>
> Thanks!
>
> Jan
>
> On 3.6.2015 11:47, ShinyaYoshida wrote:
>
>> I've updated my patch:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.01/
>>
>> Please do again!
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>> 2015-06-03 18:21 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>> <mailto:bitterfoxc at gmail.com>>:
>>
>>     Hi Jan,
>>     Thank you for your review.
>>
>>     2015-06-03 17:51 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com
>>     <mailto:jan.lahoda at oracle.com>>:
>>
>>
>>         Hi Shinya,
>>
>>         Overall looks good, thanks! Two comments:
>>         -it seems that it might make sense to create a single method
>>         that would for a TreePath look up the enclosing ImportTree, if
>>         any, and that would be used in the other methods. Something like:
>>              public ImportTree findImport(TreePath tp) {
>>                  switch (tp.getParentPath().getLeaf().getKind()) {
>>                  case MEMBER_SELECT:
>>                      return findImport(tp.getParentPath());
>>                  case IMPORT:
>>                      return (ImporTree) tp.getLeaf();
>>                  default:
>>                      return null;
>>                  }
>>              }
>>
>>         And this would then be used to detect if TreePath is inside the
>>         import (isImport) and to detect static imports. Note there is
>>         another usecase for such detection in computeSuggestions in the
>>         IDENTIFIER identifier section.
>>
>>     Ok, I'll fix!
>>
>>         -membersOf has parameter isStaticContext, which in fact mean
>>         "shouldGenerateDotClassItem" - would it make sense to rename the
>>         parameter?
>>
>>     Certainly, I'll rename.
>>
>>     Regards,
>>     shinyafox(Shinya Yoshida)
>>
>>
>>         Thanks,
>>             Jan
>>
>>
>>         On 2.6.2015 06:12, ShinyaYoshida wrote:
>>
>>             Hi Jan,
>>             Please review this patch:
>>
>>             webrev:
>>
>> http://cr.openjdk.java.net/~shinyafox/kulla/8081638/webrev.00/
>>
>>             bugs:
>>             https://bugs.openjdk.java.net/browse/JDK-8081638
>>
>>             Regards,
>>             shinyafox(Shinya Yoshida)
>>
>>
>>
>>

From jonathan.gibbons at oracle.com  Wed Jun  3 16:09:13 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 03 Jun 2015 09:09:13 -0700
Subject: JShell with Readers and Writers
Message-ID: <556F26A9.9050209@oracle.com>

JShell has the following method:

     /**
      * Create a evaluation processing environment from which the state 
engine
      * and analysis support can be accessed.
      *
      * @param in Input for the running evaluation (it's System.in).
      * @param out Output for the running evaluation (it's System.out).
      * @param err Error output for the running evaluation (it's 
System.err).
      * @return the entry point into evaluation processing support.
      */
     public static JShell create(InputStream in, PrintStream out, 
PrintStream err) {
         return new JShellImpl(in, out, err);
     }

but while InputStream and PrintStream are convenient for hooking up to a 
Unix-like terminal window, for embedded use, it would be more convenient 
if it also had a method that took Readers and Writers, and so avoid the 
round trip from characters to bytes and back again.

-- Jon

From bitterfoxc at gmail.com  Wed Jun  3 16:58:54 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 4 Jun 2015 01:58:54 +0900
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
Message-ID: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>

Hi Jan,
Please review this.

webrev:
http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/

bugs:
https://bugs.openjdk.java.net/browse/JDK-8081780

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Wed Jun  3 17:08:44 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 03 Jun 2015 10:08:44 -0700
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
Message-ID: <556F349C.4050501@oracle.com>

Hi Shinya,

Not a full review, but, defining DOESNOTMATTER is good, but then it 
should match the code that creates it, so, Eval.trialCompile() should 
use this constant,

Thanks,
Robert

On 06/03/15 09:58, ShinyaYoshida wrote:
> Hi Jan,
> Please review this.
>
> webrev:
> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
>
> bugs:
> https://bugs.openjdk.java.net/browse/JDK-8081780
>
> Regards,
> shinyafox(Shinya Yoshida)


From bitterfoxc at gmail.com  Wed Jun  3 18:18:25 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 4 Jun 2015 03:18:25 +0900
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <556F349C.4050501@oracle.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
	<556F349C.4050501@oracle.com>
Message-ID: <CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>

Hi Robert,
Thank you for your review.

I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in the
different context between SourceCodeAnalysisImpl.
Appearing $REPL00DOESNOTMATTER in completion is not caused by
Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.

Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
DOESNOTMATTER even if it is in the different context?

If I replace, should DOESNOTMATTER be in Util?

Regards,
shinyafox(Shinya Yoshida)


2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:

> Hi Shinya,
>
> Not a full review, but, defining DOESNOTMATTER is good, but then it should
> match the code that creates it, so, Eval.trialCompile() should use this
> constant,
>
> Thanks,
> Robert
>
>
> On 06/03/15 09:58, ShinyaYoshida wrote:
>
>> Hi Jan,
>> Please review this.
>>
>> webrev:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
>>
>> bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8081780
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>
>

From robert.field at oracle.com  Wed Jun  3 21:12:42 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 03 Jun 2015 14:12:42 -0700
Subject: Fix for 8080771
In-Reply-To: <5568772A.5090108@oracle.com>
References: <e73a9bd6-f9aa-427b-b568-8dc6bfa22f07@default>	<5564C021.1060801@oracle.com>	<14d9b0e4fe0.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<5568772A.5090108@oracle.com>
Message-ID: <556F6DCA.6000408@oracle.com>

[resending, somehow this mail did not get delivered]

On 05/29/15 07:26, andrei.eremeev wrote:
> Hi Robert,
>
> The second version: http://cr.openjdk.java.net/~aeremeev/8080771.01/

Hi Andrei,

I don't understand why the special treatment for dot:    \\.|
This version doesn't handle when quotes start in the middle of the 
string, which is sometimes done in a command:  someeditor editorArg="foo 
bar"
You are using both parsing logic and Patterns, I think that adds 
complexity. -- I would stick with one or the other  I think you could 
use groups to detect unmatched quotes (but maybe that's over the top) 
or, go back to character-by-character parsing.
We are going for user-friendly error messages where we can, maybe change 
"Unexpected EOL while looking for matching quote " to just "Unmatched 
quote in editor command".

Oh, and you are using "+", a string could be empty, so, using "*" would 
be better.

-Robert



>
> Andrei
>
> On 05/28/2015 06:05 PM, Robert Field wrote:
>>
>> Resending....
>>
>> On May 26, 2015 11:49:07 AM Robert Field <robert.field at oracle.com> 
>> wrote:
>>
>>>
>>> On 05/26/15 04:08, Andrei Eremeev wrote:
>>>> Hi all,
>>>>
>>>> Could anybody review the fix?
>>>> Fix:http://cr.openjdk.java.net/~aeremeev/8080771.00/
>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8080771
>>>>
>>>> Andrei Eremeev
>>>
>>> Sure.
>>>
>>> parseSetEditorCmd --
>>>   * My approach would have been to use regular expressions rather 
>>> than hand rolling.
>>>   * There are many other white-space characters besides space.
>>>   * Multiple initial spaces are handled, but if there are multiple 
>>> non-initial spaces occur empty arguments are added.
>>>   * If the break is is removed from the space case then the ++index 
>>> can be too.
>>>   * What about slash escape?  Escaped quotes?  Do we want to support 
>>> that?
>>>
>>> cmdSetEditor --
>>>   * I'd move the Unexpected EOL message to the cause site in 
>>> parseSetEditorCmd.
>>>
>


From robert.field at oracle.com  Wed Jun  3 21:48:33 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 03 Jun 2015 21:48:33 +0000
Subject: hg: kulla/dev/langtools: Rename ExecutionException to EvalException
	to avoid clash with java.util.concurrent.ExecutionException
Message-ID: <201506032148.t53LmXod023248@aojmv0008.oracle.com>

Changeset: bcebfb12b22c
Author:    rfield
Date:      2015-06-03 14:48 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/bcebfb12b22c

Rename ExecutionException to EvalException to avoid clash with java.util.concurrent.ExecutionException

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JDIExecution.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
+ src/jdk.jshell/share/classes/jdk/jshell/EvalException.java
- src/jdk.jshell/share/classes/jdk/jshell/ExecutionException.java
! test/jdk/jshell/EditorPadTest.java
! test/jdk/jshell/ExceptionsTest.java


From robert.field at oracle.com  Thu Jun  4 04:10:19 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 04 Jun 2015 04:10:19 +0000
Subject: hg: kulla/dev/langtools: 8081551: JShell API: Remove Outcome and
	Result.updates; ...
Message-ID: <201506040410.t544AK5p001015@aojmv0008.oracle.com>

Changeset: edebe0a776e9
Author:    rfield
Date:      2015-06-03 21:10 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/edebe0a776e9

8081551: JShell API: Remove Outcome and Result.updates
8085656: JShell API: Remove accesses to Result.diagnostics and allow some state.xxx(Key) queries on closed state

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
! src/jdk.jshell/share/classes/jdk/jshell/Result.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/RejectedFailedTest.java


From robert.field at oracle.com  Thu Jun  4 05:35:29 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 04 Jun 2015 05:35:29 +0000
Subject: hg: kulla/dev/langtools: 8081849: JShelll API: Code style for enum
	values is to use CONSTANT_CASE
Message-ID: <201506040535.t545ZTrd015276@aojmv0008.oracle.com>

Changeset: 15782ee3fec9
Author:    rfield
Date:      2015-06-03 22:35 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9

8081849: JShelll API: Code style for enum values is to use CONSTANT_CASE
Also, rename Variety to SubKind, and similiarly for all accessors, internal vars and method, and the enum constants.

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
+ src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
- src/jdk.jshell/share/classes/jdk/jshell/Variety.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/VariablesTest.java


From bitterfoxc at gmail.com  Thu Jun  4 06:35:33 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 4 Jun 2015 15:35:33 +0900
Subject: hg: kulla/dev/langtools: 8081849: JShelll API: Code style for
	enum values is to use CONSTANT_CASE
In-Reply-To: <201506040535.t545ZTrd015276@aojmv0008.oracle.com>
References: <201506040535.t545ZTrd015276@aojmv0008.oracle.com>
Message-ID: <CAHjBcHPcwTx5WBYeAOVpxV+=SUhLzr8oQ5+ROnLSG95sX241CQ@mail.gmail.com>

Hi Robert,
SubKind.ImportSubKind is still CamelCase:
http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9#l6.36
http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9#l1.35

Is this just as you intended?

Regards,
shinyafox(Shinya Yoshida)

2015-06-04 14:35 GMT+09:00 <robert.field at oracle.com>:

> Changeset: 15782ee3fec9
> Author:    rfield
> Date:      2015-06-03 22:35 -0700
> URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9
>
> 8081849: JShelll API: Code style for enum values is to use CONSTANT_CASE
> Also, rename Variety to SubKind, and similiarly for all accessors,
> internal vars and method, and the enum constants.
>
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
> !
> src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
> ! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
> + src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
> - src/jdk.jshell/share/classes/jdk/jshell/Variety.java
> ! test/jdk/jshell/ClassesTest.java
> ! test/jdk/jshell/IgnoreTest.java
> ! test/jdk/jshell/IllegalArgumentExceptionTest.java
> ! test/jdk/jshell/JShellStateClosedExceptionTest.java
> ! test/jdk/jshell/KullaTesting.java
> ! test/jdk/jshell/MethodsTest.java
> ! test/jdk/jshell/ReplaceTest.java
> ! test/jdk/jshell/SimpleRegressionTest.java
> ! test/jdk/jshell/SnippetTest.java
> ! test/jdk/jshell/VariablesTest.java
>
>

From robert.field at oracle.com  Thu Jun  4 06:54:28 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 03 Jun 2015 23:54:28 -0700
Subject: hg: kulla/dev/langtools: 8081849: JShelll API: Code style for
	enum values is to use CONSTANT_CASE
In-Reply-To: <CAHjBcHPcwTx5WBYeAOVpxV+=SUhLzr8oQ5+ROnLSG95sX241CQ@mail.gmail.com>
References: <201506040535.t545ZTrd015276@aojmv0008.oracle.com>
	<CAHjBcHPcwTx5WBYeAOVpxV+=SUhLzr8oQ5+ROnLSG95sX241CQ@mail.gmail.com>
Message-ID: <14dbd5978b8.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Oops, no missed that. Thanks!

Feel free to change, or leave it for me.

Robert



On June 3, 2015 11:35:36 PM ShinyaYoshida <bitterfoxc at gmail.com> wrote:

> Hi Robert,
> SubKind.ImportSubKind is still CamelCase:
> http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9#l6.36
> http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9#l1.35
>
> Is this just as you intended?
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2015-06-04 14:35 GMT+09:00 <robert.field at oracle.com>:
>
> > Changeset: 15782ee3fec9
> > Author:    rfield
> > Date:      2015-06-03 22:35 -0700
> > URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9
> >
> > 8081849: JShelll API: Code style for enum values is to use CONSTANT_CASE
> > Also, rename Variety to SubKind, and similiarly for all accessors,
> > internal vars and method, and the enum constants.
> >
> > ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
> > !
> > src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
> > ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
> > ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
> > ! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
> > + src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
> > - src/jdk.jshell/share/classes/jdk/jshell/Variety.java
> > ! test/jdk/jshell/ClassesTest.java
> > ! test/jdk/jshell/IgnoreTest.java
> > ! test/jdk/jshell/IllegalArgumentExceptionTest.java
> > ! test/jdk/jshell/JShellStateClosedExceptionTest.java
> > ! test/jdk/jshell/KullaTesting.java
> > ! test/jdk/jshell/MethodsTest.java
> > ! test/jdk/jshell/ReplaceTest.java
> > ! test/jdk/jshell/SimpleRegressionTest.java
> > ! test/jdk/jshell/SnippetTest.java
> > ! test/jdk/jshell/VariablesTest.java
> >
> >

From bitterfoxc at gmail.com  Thu Jun  4 06:59:34 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 4 Jun 2015 15:59:34 +0900
Subject: hg: kulla/dev/langtools: 8081849: JShelll API: Code style for
	enum values is to use CONSTANT_CASE
In-Reply-To: <14dbd5978b8.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <201506040535.t545ZTrd015276@aojmv0008.oracle.com>
	<CAHjBcHPcwTx5WBYeAOVpxV+=SUhLzr8oQ5+ROnLSG95sX241CQ@mail.gmail.com>
	<14dbd5978b8.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAHjBcHOayfYeUnurqF0vh89GkoFJJ-LJCKBPgz+6CGx9YCAxgA@mail.gmail.com>

Ok,
I'll leave it, please fix.

Regards,
shinyafox(Shinya Yoshida)

2015-06-04 15:54 GMT+09:00 Robert Field <robert.field at oracle.com>:

>   Oops, no missed that. Thanks!
>
> Feel free to change, or leave it for me.
>
> Robert
>
> On June 3, 2015 11:35:36 PM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>
>> Hi Robert,
>> SubKind.ImportSubKind is still CamelCase:
>> http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9#l6.36
>> http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9#l1.35
>>
>> Is this just as you intended?
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>> 2015-06-04 14:35 GMT+09:00 <robert.field at oracle.com>:
>>
>>> Changeset: 15782ee3fec9
>>> Author:    rfield
>>> Date:      2015-06-03 22:35 -0700
>>> URL:
>>> http://hg.openjdk.java.net/kulla/dev/langtools/rev/15782ee3fec9
>>>
>>> 8081849: JShelll API: Code style for enum values is to use CONSTANT_CASE
>>> Also, rename Variety to SubKind, and similiarly for all accessors,
>>> internal vars and method, and the enum constants.
>>>
>>> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
>>> !
>>> src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
>>> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
>>> ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
>>> ! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
>>> + src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
>>> - src/jdk.jshell/share/classes/jdk/jshell/Variety.java
>>> ! test/jdk/jshell/ClassesTest.java
>>> ! test/jdk/jshell/IgnoreTest.java
>>> ! test/jdk/jshell/IllegalArgumentExceptionTest.java
>>> ! test/jdk/jshell/JShellStateClosedExceptionTest.java
>>> ! test/jdk/jshell/KullaTesting.java
>>> ! test/jdk/jshell/MethodsTest.java
>>> ! test/jdk/jshell/ReplaceTest.java
>>> ! test/jdk/jshell/SimpleRegressionTest.java
>>> ! test/jdk/jshell/SnippetTest.java
>>> ! test/jdk/jshell/VariablesTest.java
>>>
>>>
>>

From jan.lahoda at oracle.com  Thu Jun  4 07:05:25 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 04 Jun 2015 09:05:25 +0200
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>	<556F349C.4050501@oracle.com>
	<CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
Message-ID: <556FF8B5.7050707@oracle.com>

The changes to completion seem fine to me. I'd suggest to reuse the 
constant also in tests (no need for another round of review just for that).

Thanks!

Jan

On 3.6.2015 20:18, ShinyaYoshida wrote:
> Hi Robert,
> Thank you for your review.
>
> I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in the
> different context between SourceCodeAnalysisImpl.
> Appearing $REPL00DOESNOTMATTER in completion is not caused by
> Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.
>
> Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
> DOESNOTMATTER even if it is in the different context?
>
> If I replace, should DOESNOTMATTER be in Util?
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
> 2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:
>
>> Hi Shinya,
>>
>> Not a full review, but, defining DOESNOTMATTER is good, but then it should
>> match the code that creates it, so, Eval.trialCompile() should use this
>> constant,
>>
>> Thanks,
>> Robert
>>
>>
>> On 06/03/15 09:58, ShinyaYoshida wrote:
>>
>>> Hi Jan,
>>> Please review this.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
>>>
>>> bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8081780
>>>
>>> Regards,
>>> shinyafox(Shinya Yoshida)
>>>
>>
>>

From bitterfoxc at gmail.com  Thu Jun  4 08:16:01 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 4 Jun 2015 17:16:01 +0900
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <556FF8B5.7050707@oracle.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
	<556F349C.4050501@oracle.com>
	<CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
	<556FF8B5.7050707@oracle.com>
Message-ID: <CAHjBcHOqvX-yhKuUY8fdwSQ=du579vM_SkuAHkaOh+GvGYYT7A@mail.gmail.com>

Hi Jan,
Thank you for your review.

Ok, I'll make DOESNOTMATTER as public and fix to reuse it.

I'll push after recieving the responce from Robert.

Regards,
shinyafox(Shinya Yoshida)




2015-06-04 16:05 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> The changes to completion seem fine to me. I'd suggest to reuse the
> constant also in tests (no need for another round of review just for that).
>
> Thanks!
>
> Jan
>
>
> On 3.6.2015 20:18, ShinyaYoshida wrote:
>
>> Hi Robert,
>> Thank you for your review.
>>
>> I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in the
>> different context between SourceCodeAnalysisImpl.
>> Appearing $REPL00DOESNOTMATTER in completion is not caused by
>> Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.
>>
>> Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
>> DOESNOTMATTER even if it is in the different context?
>>
>> If I replace, should DOESNOTMATTER be in Util?
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>
>> 2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:
>>
>>  Hi Shinya,
>>>
>>> Not a full review, but, defining DOESNOTMATTER is good, but then it
>>> should
>>> match the code that creates it, so, Eval.trialCompile() should use this
>>> constant,
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>> On 06/03/15 09:58, ShinyaYoshida wrote:
>>>
>>>  Hi Jan,
>>>> Please review this.
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
>>>>
>>>> bugs:
>>>> https://bugs.openjdk.java.net/browse/JDK-8081780
>>>>
>>>> Regards,
>>>> shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>
>>>

From robert.field at oracle.com  Thu Jun  4 15:47:15 2015
From: robert.field at oracle.com (Robert Field)
Date: Thu, 04 Jun 2015 08:47:15 -0700
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <CAHjBcHOqvX-yhKuUY8fdwSQ=du579vM_SkuAHkaOh+GvGYYT7A@mail.gmail.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
	<556F349C.4050501@oracle.com>
	<CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
	<556FF8B5.7050707@oracle.com>
	<CAHjBcHOqvX-yhKuUY8fdwSQ=du579vM_SkuAHkaOh+GvGYYT7A@mail.gmail.com>
Message-ID: <14dbf413fd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Hi Shinya,
I don't think DOESNOTMATTER should be part of the API, so making it public 
for tests is not what I would recommend.  The tests can just verify that 
nothing unexpected shows up.  And, yes, it should be defined in Util and 
the constant used in each place including Eval.

Thanks,
Robert



On June 4, 2015 1:16:04 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:

> Hi Jan,
> Thank you for your review.
>
> Ok, I'll make DOESNOTMATTER as public and fix to reuse it.
>
> I'll push after recieving the responce from Robert.
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
>
>
> 2015-06-04 16:05 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
>
> > The changes to completion seem fine to me. I'd suggest to reuse the
> > constant also in tests (no need for another round of review just for that).
> >
> > Thanks!
> >
> > Jan
> >
> >
> > On 3.6.2015 20:18, ShinyaYoshida wrote:
> >
> >> Hi Robert,
> >> Thank you for your review.
> >>
> >> I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in the
> >> different context between SourceCodeAnalysisImpl.
> >> Appearing $REPL00DOESNOTMATTER in completion is not caused by
> >> Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.
> >>
> >> Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
> >> DOESNOTMATTER even if it is in the different context?
> >>
> >> If I replace, should DOESNOTMATTER be in Util?
> >>
> >> Regards,
> >> shinyafox(Shinya Yoshida)
> >>
> >>
> >> 2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:
> >>
> >>  Hi Shinya,
> >>>
> >>> Not a full review, but, defining DOESNOTMATTER is good, but then it
> >>> should
> >>> match the code that creates it, so, Eval.trialCompile() should use this
> >>> constant,
> >>>
> >>> Thanks,
> >>> Robert
> >>>
> >>>
> >>> On 06/03/15 09:58, ShinyaYoshida wrote:
> >>>
> >>>  Hi Jan,
> >>>> Please review this.
> >>>>
> >>>> webrev:
> >>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
> >>>>
> >>>> bugs:
> >>>> https://bugs.openjdk.java.net/browse/JDK-8081780
> >>>>
> >>>> Regards,
> >>>> shinyafox(Shinya Yoshida)
> >>>>
> >>>>
> >>>
> >>>

From bitterfoxc at gmail.com  Thu Jun  4 16:24:27 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Fri, 5 Jun 2015 01:24:27 +0900
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <14dbf413fd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
	<556F349C.4050501@oracle.com>
	<CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
	<556FF8B5.7050707@oracle.com>
	<CAHjBcHOqvX-yhKuUY8fdwSQ=du579vM_SkuAHkaOh+GvGYYT7A@mail.gmail.com>
	<14dbf413fd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAHjBcHNrD-0t9PDg5ZtQWGqZZPKesBaBwGogAU8Swx4b5N5Eqg@mail.gmail.com>

Hi Robert,
Thank you for your review.

I've updated:
http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.01/

* declare REPL_DOESNOTMATTER_CLASS_NAME in Util
* replace string literal in Eval
* In the test, the string literal is still the string literal

Regards,
shinyafox(Shinya Yoshida)


2015-06-05 0:47 GMT+09:00 Robert Field <robert.field at oracle.com>:

>   Hi Shinya,
> I don't think DOESNOTMATTER should be part of the API, so making it public
> for tests is not what I would recommend.  The tests can just verify that
> nothing unexpected shows up.  And, yes, it should be defined in Util and
> the constant used in each place including Eval.
>
> Thanks,
> Robert
>
> On June 4, 2015 1:16:04 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>
>> Hi Jan,
>> Thank you for your review.
>>
>> Ok, I'll make DOESNOTMATTER as public and fix to reuse it.
>>
>> I'll push after recieving the responce from Robert.
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>
>>
>>
>> 2015-06-04 16:05 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
>>
>>> The changes to completion seem fine to me. I'd suggest to reuse the
>>> constant also in tests (no need for another round of review just for that).
>>>
>>> Thanks!
>>>
>>> Jan
>>>
>>>
>>> On 3.6.2015 20:18, ShinyaYoshida wrote:
>>>
>>>> Hi Robert,
>>>> Thank you for your review.
>>>>
>>>> I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in the
>>>> different context between SourceCodeAnalysisImpl.
>>>> Appearing $REPL00DOESNOTMATTER in completion is not caused by
>>>> Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.
>>>>
>>>> Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
>>>> DOESNOTMATTER even if it is in the different context?
>>>>
>>>> If I replace, should DOESNOTMATTER be in Util?
>>>>
>>>> Regards,
>>>> shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>> 2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:
>>>>
>>>>  Hi Shinya,
>>>>>
>>>>> Not a full review, but, defining DOESNOTMATTER is good, but then it
>>>>> should
>>>>> match the code that creates it, so, Eval.trialCompile() should use this
>>>>> constant,
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>>
>>>>> On 06/03/15 09:58, ShinyaYoshida wrote:
>>>>>
>>>>>  Hi Jan,
>>>>>> Please review this.
>>>>>>
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
>>>>>>
>>>>>> bugs:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081780
>>>>>>
>>>>>> Regards,
>>>>>> shinyafox(Shinya Yoshida)
>>>>>>
>>>>>>
>>>>>
>>>>>
>>

From robert.field at oracle.com  Thu Jun  4 16:35:20 2015
From: robert.field at oracle.com (Robert Field)
Date: Thu, 04 Jun 2015 09:35:20 -0700
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <CAHjBcHNrD-0t9PDg5ZtQWGqZZPKesBaBwGogAU8Swx4b5N5Eqg@mail.gmail.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
	<556F349C.4050501@oracle.com>
	<CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
	<556FF8B5.7050707@oracle.com>
	<CAHjBcHOqvX-yhKuUY8fdwSQ=du579vM_SkuAHkaOh+GvGYYT7A@mail.gmail.com>
	<14dbf413fd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAHjBcHNrD-0t9PDg5ZtQWGqZZPKesBaBwGogAU8Swx4b5N5Eqg@mail.gmail.com>
Message-ID: <14dbf6d4558.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Looks good.
Please push.

Thanks,
Robert



On June 4, 2015 9:24:30 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:

> Hi Robert,
> Thank you for your review.
>
> I've updated:
> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.01/
>
> * declare REPL_DOESNOTMATTER_CLASS_NAME in Util
> * replace string literal in Eval
> * In the test, the string literal is still the string literal
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
> 2015-06-05 0:47 GMT+09:00 Robert Field <robert.field at oracle.com>:
>
> >   Hi Shinya,
> > I don't think DOESNOTMATTER should be part of the API, so making it public
> > for tests is not what I would recommend.  The tests can just verify that
> > nothing unexpected shows up.  And, yes, it should be defined in Util and
> > the constant used in each place including Eval.
> >
> > Thanks,
> > Robert
> >
> > On June 4, 2015 1:16:04 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> >
> >> Hi Jan,
> >> Thank you for your review.
> >>
> >> Ok, I'll make DOESNOTMATTER as public and fix to reuse it.
> >>
> >> I'll push after recieving the responce from Robert.
> >>
> >> Regards,
> >> shinyafox(Shinya Yoshida)
> >>
> >>
> >>
> >>
> >> 2015-06-04 16:05 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
> >>
> >>> The changes to completion seem fine to me. I'd suggest to reuse the
> >>> constant also in tests (no need for another round of review just for that).
> >>>
> >>> Thanks!
> >>>
> >>> Jan
> >>>
> >>>
> >>> On 3.6.2015 20:18, ShinyaYoshida wrote:
> >>>
> >>>> Hi Robert,
> >>>> Thank you for your review.
> >>>>
> >>>> I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in the
> >>>> different context between SourceCodeAnalysisImpl.
> >>>> Appearing $REPL00DOESNOTMATTER in completion is not caused by
> >>>> Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.
> >>>>
> >>>> Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
> >>>> DOESNOTMATTER even if it is in the different context?
> >>>>
> >>>> If I replace, should DOESNOTMATTER be in Util?
> >>>>
> >>>> Regards,
> >>>> shinyafox(Shinya Yoshida)
> >>>>
> >>>>
> >>>> 2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:
> >>>>
> >>>>  Hi Shinya,
> >>>>>
> >>>>> Not a full review, but, defining DOESNOTMATTER is good, but then it
> >>>>> should
> >>>>> match the code that creates it, so, Eval.trialCompile() should use this
> >>>>> constant,
> >>>>>
> >>>>> Thanks,
> >>>>> Robert
> >>>>>
> >>>>>
> >>>>> On 06/03/15 09:58, ShinyaYoshida wrote:
> >>>>>
> >>>>>  Hi Jan,
> >>>>>> Please review this.
> >>>>>>
> >>>>>> webrev:
> >>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
> >>>>>>
> >>>>>> bugs:
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8081780
> >>>>>>
> >>>>>> Regards,
> >>>>>> shinyafox(Shinya Yoshida)
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>

From bitterfoxc at gmail.com  Thu Jun  4 17:55:00 2015
From: bitterfoxc at gmail.com (bitterfoxc at gmail.com)
Date: Thu, 04 Jun 2015 17:55:00 +0000
Subject: hg: kulla/dev/langtools: 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
Message-ID: <201506041755.t54Ht1Sj000482@aojmv0008.oracle.com>

Changeset: f4bb1ac6714b
Author:    shinyafox
Date:      2015-06-05 02:51 +0900
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/f4bb1ac6714b

8081780: JShell tool: Completion contains $REPL00DOESNOTMATTER
Reviewed-by: rfield, jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Util.java
! test/jdk/jshell/CompletionSuggestionTest.java


From bitterfoxc at gmail.com  Thu Jun  4 17:55:16 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Fri, 5 Jun 2015 02:55:16 +0900
Subject: xxs: RFR 8081780: JShell tool: Completion contains
	$REPL00DOESNOTMATTER
In-Reply-To: <14dbf6d4558.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAHjBcHMFWL6ewiLuqCqcnx+eK9HHYSo0FPFGqmwauBtCHH99qA@mail.gmail.com>
	<556F349C.4050501@oracle.com>
	<CAHjBcHP5PpgyJDt+O8Rf60r+xWG5svWxR0tEgReUwPYRDFsQ9Q@mail.gmail.com>
	<556FF8B5.7050707@oracle.com>
	<CAHjBcHOqvX-yhKuUY8fdwSQ=du579vM_SkuAHkaOh+GvGYYT7A@mail.gmail.com>
	<14dbf413fd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAHjBcHNrD-0t9PDg5ZtQWGqZZPKesBaBwGogAU8Swx4b5N5Eqg@mail.gmail.com>
	<14dbf6d4558.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAHjBcHMoeRWjY_SwvZhb_KyaVGvpXXk-K_zSym7QOsLhprR5zQ@mail.gmail.com>

I've pushed.

Regards,
shinyafox(Shinya Yoshida)

2015-06-05 1:35 GMT+09:00 Robert Field <robert.field at oracle.com>:

>   Looks good.
> Please push.
>
> Thanks,
> Robert
>
> On June 4, 2015 9:24:30 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>
>> Hi Robert,
>> Thank you for your review.
>>
>> I've updated:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.01/
>>
>> * declare REPL_DOESNOTMATTER_CLASS_NAME in Util
>> * replace string literal in Eval
>> * In the test, the string literal is still the string literal
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>
>> 2015-06-05 0:47 GMT+09:00 Robert Field <robert.field at oracle.com>:
>>
>>>   Hi Shinya,
>>> I don't think DOESNOTMATTER should be part of the API, so making it
>>> public for tests is not what I would recommend.  The tests can just verify
>>> that nothing unexpected shows up.  And, yes, it should be defined in Util
>>> and the constant used in each place including Eval.
>>>
>>> Thanks,
>>> Robert
>>>
>>> On June 4, 2015 1:16:04 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>>>
>>>> Hi Jan,
>>>> Thank you for your review.
>>>>
>>>> Ok, I'll make DOESNOTMATTER as public and fix to reuse it.
>>>>
>>>> I'll push after recieving the responce from Robert.
>>>>
>>>> Regards,
>>>> shinyafox(Shinya Yoshida)
>>>>
>>>>
>>>>
>>>>
>>>> 2015-06-04 16:05 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:
>>>>
>>>>> The changes to completion seem fine to me. I'd suggest to reuse the
>>>>> constant also in tests (no need for another round of review just for that).
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>> On 3.6.2015 20:18, ShinyaYoshida wrote:
>>>>>
>>>>>> Hi Robert,
>>>>>> Thank you for your review.
>>>>>>
>>>>>> I think the use of "$REPL00DOESNOTMATTER" in Eval#trialCompile is in
>>>>>> the
>>>>>> different context between SourceCodeAnalysisImpl.
>>>>>> Appearing $REPL00DOESNOTMATTER in completion is not caused by
>>>>>> Eval#trialCompile but SourceCodeAnalysisImpl#wrapInClass.
>>>>>>
>>>>>> Should I replace "$REPL00DOESNOTMATTER" in Eval#trialCompile by
>>>>>> DOESNOTMATTER even if it is in the different context?
>>>>>>
>>>>>> If I replace, should DOESNOTMATTER be in Util?
>>>>>>
>>>>>> Regards,
>>>>>> shinyafox(Shinya Yoshida)
>>>>>>
>>>>>>
>>>>>> 2015-06-04 2:08 GMT+09:00 Robert Field <robert.field at oracle.com>:
>>>>>>
>>>>>>  Hi Shinya,
>>>>>>>
>>>>>>> Not a full review, but, defining DOESNOTMATTER is good, but then it
>>>>>>> should
>>>>>>> match the code that creates it, so, Eval.trialCompile() should use
>>>>>>> this
>>>>>>> constant,
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On 06/03/15 09:58, ShinyaYoshida wrote:
>>>>>>>
>>>>>>>  Hi Jan,
>>>>>>>> Please review this.
>>>>>>>>
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~shinyafox/kulla/8081780/webrev.00/
>>>>>>>>
>>>>>>>> bugs:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081780
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> shinyafox(Shinya Yoshida)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>

From bitterfoxc at gmail.com  Fri Jun  5 13:17:55 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Fri, 5 Jun 2015 22:17:55 +0900
Subject: RFR 8085882: JShell tool: Completion for primitive types
Message-ID: <CAHjBcHO98X=OwBn6mzWW7P5Q5maAtOq5SauXT4r6GZWjEZqu3Q@mail.gmail.com>

Hi Jan,
Could you review this?

bugs:
https://bugs.openjdk.java.net/browse/JDK-8085882

webrev:
http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.00/

Regards,
shinyafox(Shinya Yoshida)

From bitterfoxc at gmail.com  Fri Jun  5 14:06:07 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Fri, 5 Jun 2015 23:06:07 +0900
Subject: RFR 8085882: JShell tool: Completion for primitive types
In-Reply-To: <CAHjBcHO98X=OwBn6mzWW7P5Q5maAtOq5SauXT4r6GZWjEZqu3Q@mail.gmail.com>
References: <CAHjBcHO98X=OwBn6mzWW7P5Q5maAtOq5SauXT4r6GZWjEZqu3Q@mail.gmail.com>
Message-ID: <CAHjBcHMaghP3AVTUh2Fr+n9LPSQHfnVW13KOMdDbWbyfKkpQ=g@mail.gmail.com>

I've updated.
http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.01/

2015-06-05 22:17 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com>:

> Hi Jan,
> Could you review this?
>
> bugs:
> https://bugs.openjdk.java.net/browse/JDK-8085882
>
> webrev:
> http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.00/
>
> Regards,
> shinyafox(Shinya Yoshida)
>

From jan.lahoda at oracle.com  Mon Jun  8 10:14:27 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Mon, 08 Jun 2015 10:14:27 +0000
Subject: hg: kulla/dev/langtools: Fixing bugs in narrowing history: making
	narrowing history work even if obsolette entries has been
	removed; fixing setBuffer invocation
Message-ID: <201506081014.t58AERsr017929@aojmv0008.oracle.com>

Changeset: 8dae0a90605c
Author:    jlahoda
Date:      2015-06-08 10:22 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/8dae0a90605c

Fixing bugs in narrowing history: making narrowing history work even if obsolette entries has been removed; fixing setBuffer invocation

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
! test/jdk/jshell/HistoryTest.java


From jan.lahoda at oracle.com  Mon Jun  8 14:23:01 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Mon, 08 Jun 2015 14:23:01 +0000
Subject: hg: kulla/dev/langtools: When detecting Ctrl-C,
	instead of wrapping the System.in,
	wrap the InputStream used by the terminal - it may differ from
	System.in
Message-ID: <201506081423.t58EN1kS025178@aojmv0008.oracle.com>

Changeset: 8a44b8c07ec3
Author:    jlahoda
Date:      2015-06-08 16:12 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/8a44b8c07ec3

When detecting Ctrl-C, instead of wrapping the System.in, wrap the InputStream used by the terminal - it may differ from System.in

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java


From jan.lahoda at oracle.com  Mon Jun  8 14:23:02 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Mon, 08 Jun 2015 14:23:02 +0000
Subject: hg: kulla/dev/jdk: Adding support for custom shortcuts for jshell
Message-ID: <201506081423.t58EN2mj025211@aojmv0008.oracle.com>

Changeset: 65f453161726
Author:    jlahoda
Date:      2015-06-08 16:10 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/jdk/rev/65f453161726

Adding support for custom shortcuts for jshell

! src/jdk.jline/share/classes/jdk/internal/jline/WindowsTerminal.java


From bitterfoxc at gmail.com  Tue Jun  9 06:05:44 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 9 Jun 2015 15:05:44 +0900
Subject: RFR 8085882: JShell tool: Completion for primitive types
In-Reply-To: <CAHjBcHMaghP3AVTUh2Fr+n9LPSQHfnVW13KOMdDbWbyfKkpQ=g@mail.gmail.com>
References: <CAHjBcHO98X=OwBn6mzWW7P5Q5maAtOq5SauXT4r6GZWjEZqu3Q@mail.gmail.com>
	<CAHjBcHMaghP3AVTUh2Fr+n9LPSQHfnVW13KOMdDbWbyfKkpQ=g@mail.gmail.com>
Message-ID: <CAHjBcHOUBtf=j=SdbiSgr1kzoqO337j6wniQ4YCN26BvX0pZrA@mail.gmail.com>

Ping.

Could you review?

Regards,
shinyafox(Shinya Yoshida)

2015-06-05 23:06 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com>:

> I've updated.
> http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.01/
>
> 2015-06-05 22:17 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com>:
>
>> Hi Jan,
>> Could you review this?
>>
>> bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8085882
>>
>> webrev:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.00/
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>
>

From jan.lahoda at oracle.com  Tue Jun  9 11:59:30 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 09 Jun 2015 13:59:30 +0200
Subject: RFR 8085882: JShell tool: Completion for primitive types
In-Reply-To: <CAHjBcHOUBtf=j=SdbiSgr1kzoqO337j6wniQ4YCN26BvX0pZrA@mail.gmail.com>
References: <CAHjBcHO98X=OwBn6mzWW7P5Q5maAtOq5SauXT4r6GZWjEZqu3Q@mail.gmail.com>	<CAHjBcHMaghP3AVTUh2Fr+n9LPSQHfnVW13KOMdDbWbyfKkpQ=g@mail.gmail.com>
	<CAHjBcHOUBtf=j=SdbiSgr1kzoqO337j6wniQ4YCN26BvX0pZrA@mail.gmail.com>
Message-ID: <5576D522.202@oracle.com>

Seems good to me. Please push.

Thanks,
    Jan

On 9.6.2015 08:05, ShinyaYoshida wrote:
> Ping.
>
> Could you review?
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2015-06-05 23:06 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
> <mailto:bitterfoxc at gmail.com>>:
>
>     I've updated.
>     http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.01/
>
>     2015-06-05 22:17 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>     <mailto:bitterfoxc at gmail.com>>:
>
>         Hi Jan,
>         Could you review this?
>
>         bugs:
>         https://bugs.openjdk.java.net/browse/JDK-8085882
>
>         webrev:
>         http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.00/
>
>         Regards,
>         shinyafox(Shinya Yoshida)
>
>
>

From bitterfoxc at gmail.com  Tue Jun  9 12:15:19 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 9 Jun 2015 21:15:19 +0900
Subject: RFR 8085882: JShell tool: Completion for primitive types
In-Reply-To: <5576D522.202@oracle.com>
References: <CAHjBcHO98X=OwBn6mzWW7P5Q5maAtOq5SauXT4r6GZWjEZqu3Q@mail.gmail.com>
	<CAHjBcHMaghP3AVTUh2Fr+n9LPSQHfnVW13KOMdDbWbyfKkpQ=g@mail.gmail.com>
	<CAHjBcHOUBtf=j=SdbiSgr1kzoqO337j6wniQ4YCN26BvX0pZrA@mail.gmail.com>
	<5576D522.202@oracle.com>
Message-ID: <CAHjBcHMufoNr42cS+CeVh6w8HuD0BQmUxFRBh06eW37+EjunjQ@mail.gmail.com>

Hi Jan,
Thank you for your review. I'll push.

Thanks,
shinyafox(Shinya Yoshida)

2015-06-09 20:59 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Seems good to me. Please push.
>
> Thanks,
>    Jan
>
> On 9.6.2015 08:05, ShinyaYoshida wrote:
>
>> Ping.
>>
>> Could you review?
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>> 2015-06-05 23:06 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>> <mailto:bitterfoxc at gmail.com>>:
>>
>>     I've updated.
>>     http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.01/
>>
>>     2015-06-05 22:17 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
>>     <mailto:bitterfoxc at gmail.com>>:
>>
>>         Hi Jan,
>>         Could you review this?
>>
>>         bugs:
>>         https://bugs.openjdk.java.net/browse/JDK-8085882
>>
>>         webrev:
>>         http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.00/
>>
>>         Regards,
>>         shinyafox(Shinya Yoshida)
>>
>>
>>
>>

From bitterfoxc at gmail.com  Tue Jun  9 12:29:17 2015
From: bitterfoxc at gmail.com (bitterfoxc at gmail.com)
Date: Tue, 09 Jun 2015 12:29:17 +0000
Subject: hg: kulla/dev/langtools: 8085882: JShell tool: Completion for
	primitive types
Message-ID: <201506091229.t59CTH3M019623@aojmv0008.oracle.com>

Changeset: 7c748bccd597
Author:    shinyafox
Date:      2015-06-09 21:23 +0900
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/7c748bccd597

8085882: JShell tool: Completion for primitive types
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! test/jdk/jshell/CompletionSuggestionTest.java


From robert.field at oracle.com  Wed Jun 10 00:44:10 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 09 Jun 2015 17:44:10 -0700
Subject: Kulla issues -- Fix Version
Message-ID: <5577885A.2070602@oracle.com>

For issues that I'm pushing or which need to fixed soon I've been using 
the Fix Version 9-repo-kulla.
For further out issues I've been using 9.
I notice that Michel uses 9.

My assumption is that when we push into 9 we will do so under one issue, 
for many reasons including that it would need to be reviewed as a whole 
and most of the code went in before we started using JBS.  Thus, any 
issued that go in before we merge with JDK9 would be 9-repo-kulla only.  
Yes?

Thoughts?

-Robert


From robert.field at oracle.com  Wed Jun 10 04:59:59 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 10 Jun 2015 04:59:59 +0000
Subject: hg: kulla/dev/langtools: 8082751: JShell API: add event dispatch
Message-ID: <201506100459.t5A4xxnb021222@aojmv0008.oracle.com>

Changeset: 0ad9e3e0008b
Author:    rfield
Date:      2015-06-09 21:59 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/0ad9e3e0008b

8082751: JShell API: add event dispatch

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
+ src/jdk.jshell/share/classes/jdk/jshell/KeyStatusEvent.java
! src/jdk.jshell/share/classes/jdk/jshell/Result.java
- src/jdk.jshell/share/classes/jdk/jshell/StatusTransitionEvent.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/ShutdownTest.java


From bitterfoxc at gmail.com  Thu Jun 11 02:05:19 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 11 Jun 2015 11:05:19 +0900
Subject: Reverting a WIP code WAS: hg: kulla/dev/langtools: 8085882: JShell
	tool: Completion for primitive types
Message-ID: <CAHjBcHMhkO86uhm-ZsUAiiCU1SLcZ53-gLurPQJ82zXm8hAwZw@mail.gmail.com>

Hi Jan,
I notice that I included a WIP code in the previous commit. I must
apologize.
Could or should I make the code revert?

Reverting commit will be:
Commit message: Revert WIP code in
http://hg.openjdk.java.net/kulla/dev/langtools/rev/7c748bccd597
webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.02/

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Thu Jun 11 02:10:30 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 10 Jun 2015 19:10:30 -0700
Subject: Reverting a WIP code WAS: hg: kulla/dev/langtools: 8085882: JShell
	tool: Completion for primitive types
In-Reply-To: <CAHjBcHMhkO86uhm-ZsUAiiCU1SLcZ53-gLurPQJ82zXm8hAwZw@mail.gmail.com>
References: <CAHjBcHMhkO86uhm-ZsUAiiCU1SLcZ53-gLurPQJ82zXm8hAwZw@mail.gmail.com>
Message-ID: <5578EE16.20505@oracle.com>

Fine with me.

-Robert

On 06/10/15 19:05, ShinyaYoshida wrote:
> Hi Jan,
> I notice that I included a WIP code in the previous commit. I must
> apologize.
> Could or should I make the code revert?
>
> Reverting commit will be:
> Commit message: Revert WIP code in
> http://hg.openjdk.java.net/kulla/dev/langtools/rev/7c748bccd597
> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.02/
>
> Regards,
> shinyafox(Shinya Yoshida)


From bitterfoxc at gmail.com  Thu Jun 11 02:19:17 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 11 Jun 2015 11:19:17 +0900
Subject: Reverting a WIP code WAS: hg: kulla/dev/langtools: 8085882:
	JShell tool: Completion for primitive types
In-Reply-To: <5578EE16.20505@oracle.com>
References: <CAHjBcHMhkO86uhm-ZsUAiiCU1SLcZ53-gLurPQJ82zXm8hAwZw@mail.gmail.com>
	<5578EE16.20505@oracle.com>
Message-ID: <CAHjBcHMbOTUF232wnbWoVcNJkGVR4U6BUZjdjbTF5EC+uB4fsQ@mail.gmail.com>

Thank you, Robert.
I'll push it.

Regards,
shinyafox(Shinya Yoshida)

2015-06-11 11:10 GMT+09:00 Robert Field <robert.field at oracle.com>:

> Fine with me.
>
> -Robert
>
>
> On 06/10/15 19:05, ShinyaYoshida wrote:
>
>> Hi Jan,
>> I notice that I included a WIP code in the previous commit. I must
>> apologize.
>> Could or should I make the code revert?
>>
>> Reverting commit will be:
>> Commit message: Revert WIP code in
>> http://hg.openjdk.java.net/kulla/dev/langtools/rev/7c748bccd597
>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8085882/webrev.02/
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>
>

From bitterfoxc at gmail.com  Thu Jun 11 02:22:24 2015
From: bitterfoxc at gmail.com (bitterfoxc at gmail.com)
Date: Thu, 11 Jun 2015 02:22:24 +0000
Subject: hg: kulla/dev/langtools: Revert WIP code in
	http://hg.openjdk.java.net/kulla/dev/langtools/rev/7c748bccd597
Message-ID: <201506110222.t5B2MPQu019401@aojmv0008.oracle.com>

Changeset: 77aea9fd992d
Author:    shinyafox
Date:      2015-06-11 11:21 +0900
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/77aea9fd992d

Revert WIP code in http://hg.openjdk.java.net/kulla/dev/langtools/rev/7c748bccd597
Reviewed-by: rfield

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java


From bitterfoxc at gmail.com  Thu Jun 11 04:53:11 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 11 Jun 2015 13:53:11 +0900
Subject: RFR 8087169: JShell tool: Missing some suggestions as SMART or
	documentation when the target-type or the argument-type is boxed or
	unboxed type
Message-ID: <CAHjBcHPU0iAyGBe1nuQcMPd9QsZ5TmMj5RjFuqMnta7yOk54DQ@mail.gmail.com>

Hi Jan,
Please review this patch:

webrev:
http://cr.openjdk.java.net/~shinyafox/kulla/8087169/webrev.00/

bugs:
https://bugs.openjdk.java.net/browse/JDK-8087169

Regards,
shinyafox(Shinya Yoshida)

From jan.lahoda at oracle.com  Thu Jun 11 07:04:25 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 11 Jun 2015 09:04:25 +0200
Subject: RFR 8087169: JShell tool: Missing some suggestions as SMART or
	documentation when the target-type or the argument-type is boxed or
	unboxed type
In-Reply-To: <CAHjBcHPU0iAyGBe1nuQcMPd9QsZ5TmMj5RjFuqMnta7yOk54DQ@mail.gmail.com>
References: <CAHjBcHPU0iAyGBe1nuQcMPd9QsZ5TmMj5RjFuqMnta7yOk54DQ@mail.gmail.com>
Message-ID: <557932F9.2060003@oracle.com>

Hi Shinya,

Seems good to me, please push.

Thanks!

Jan

On 11.6.2015 06:53, ShinyaYoshida wrote:
> Hi Jan,
> Please review this patch:
>
> webrev:
> http://cr.openjdk.java.net/~shinyafox/kulla/8087169/webrev.00/
>
> bugs:
> https://bugs.openjdk.java.net/browse/JDK-8087169
>
> Regards,
> shinyafox(Shinya Yoshida)
>

From jan.lahoda at oracle.com  Thu Jun 11 08:33:50 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Thu, 11 Jun 2015 08:33:50 +0000
Subject: hg: kulla/dev/langtools: Adding ability to refer to previous snippets
	via shorthand commands.
Message-ID: <201506110833.t5B8XoX3015746@aojmv0008.oracle.com>

Changeset: 61606c9d1d35
Author:    jlahoda
Date:      2015-06-11 10:31 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/61606c9d1d35

Adding ability to refer to previous snippets via shorthand commands.

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! test/jdk/jshell/ToolBasicTest.java


From bitterfoxc at gmail.com  Thu Jun 11 12:15:21 2015
From: bitterfoxc at gmail.com (bitterfoxc at gmail.com)
Date: Thu, 11 Jun 2015 12:15:21 +0000
Subject: hg: kulla/dev/langtools: 8087169: JShell tool: Missing some
	suggestions as SMART or documentation when the target-type or
	the argument-type is boxed or unboxed type
Message-ID: <201506111215.t5BCFLKm023102@aojmv0008.oracle.com>

Changeset: 05c597ae36ed
Author:    shinyafox
Date:      2015-06-11 21:13 +0900
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/05c597ae36ed

8087169: JShell tool: Missing some suggestions as SMART or documentation when the target-type or the argument-type is boxed or unboxed type
Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! test/jdk/jshell/CompletionSuggestionTest.java


From bitterfoxc at gmail.com  Thu Jun 11 12:15:56 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Thu, 11 Jun 2015 21:15:56 +0900
Subject: RFR 8087169: JShell tool: Missing some suggestions as SMART or
	documentation when the target-type or the argument-type is boxed or
	unboxed type
In-Reply-To: <557932F9.2060003@oracle.com>
References: <CAHjBcHPU0iAyGBe1nuQcMPd9QsZ5TmMj5RjFuqMnta7yOk54DQ@mail.gmail.com>
	<557932F9.2060003@oracle.com>
Message-ID: <CAHjBcHPcqXXZeUc-F1dPQez7imdW_-TAySHVMK5LeFZJqDfBaQ@mail.gmail.com>

Thank you, Jan.
I've pushed.

Regards,
shinyafox(Shinya Yoshida)

2015-06-11 16:04 GMT+09:00 Jan Lahoda <jan.lahoda at oracle.com>:

> Hi Shinya,
>
> Seems good to me, please push.
>
> Thanks!
>
> Jan
>
>
> On 11.6.2015 06:53, ShinyaYoshida wrote:
>
>> Hi Jan,
>> Please review this patch:
>>
>> webrev:
>> http://cr.openjdk.java.net/~shinyafox/kulla/8087169/webrev.00/
>>
>> bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8087169
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>>

From jan.lahoda at oracle.com  Thu Jun 11 13:06:28 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Thu, 11 Jun 2015 13:06:28 +0000
Subject: hg: kulla/dev/langtools: Fixing mistakes in narrowing history and
	history persistence
Message-ID: <201506111306.t5BD6SFk001112@aojmv0008.oracle.com>

Changeset: 6e09f4cfdc46
Author:    jlahoda
Date:      2015-06-11 15:05 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/6e09f4cfdc46

Fixing mistakes in narrowing history and history persistence

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java


From jan.lahoda at oracle.com  Thu Jun 11 13:08:35 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Thu, 11 Jun 2015 13:08:35 +0000
Subject: hg: kulla/dev/jdk: Improving control key handling on Win
Message-ID: <201506111308.t5BD8Zt9001455@aojmv0008.oracle.com>

Changeset: cb7ca218e5f2
Author:    jlahoda
Date:      2015-06-11 15:08 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/jdk/rev/cb7ca218e5f2

Improving control key handling on Win

! src/jdk.jline/share/classes/jdk/internal/jline/WindowsTerminal.java


From robert.field at oracle.com  Fri Jun 12 04:34:37 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 12 Jun 2015 04:34:37 +0000
Subject: hg: kulla/dev/langtools: 8087296: JShell API: add value and exception
	information to KeyStatusEvent; ...
Message-ID: <201506120434.t5C4YbTw009002@aojmv0008.oracle.com>

Changeset: 2b7392071784
Author:    rfield
Date:      2015-06-11 21:34 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/2b7392071784

8087296: JShell API: add value and exception information to KeyStatusEvent
8087137: jshell tool: switch tool to use KeyStatusEvent
8087139: JShell tests: convert tests to use KeyStatusEvent
8082779: JShell API: remove Result
Summary: API now completely event based

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
! src/jdk.jshell/share/classes/jdk/jshell/KeyStatusEvent.java
- src/jdk.jshell/share/classes/jdk/jshell/Result.java
! test/jdk/jshell/ClassMembersTest.java
! test/jdk/jshell/ClassPathTest.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/EmptyTest.java
! test/jdk/jshell/ExceptionsTest.java
! test/jdk/jshell/IOTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ModifiersTest.java
! test/jdk/jshell/NullTest.java
! test/jdk/jshell/RejectedFailedTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/ShutdownTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/StopExecutionTest.java
! test/jdk/jshell/TypeNameTest.java
! test/jdk/jshell/VariablesTest.java


From jan.lahoda at oracle.com  Fri Jun 12 13:18:44 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Fri, 12 Jun 2015 13:18:44 +0000
Subject: hg: kulla/dev/jdk: Fixing trailing whitespaces;
	adding newlines at the end of the files
Message-ID: <201506121318.t5CDIiYg003438@aojmv0008.oracle.com>

Changeset: 51fcffa4c693
Author:    jlahoda
Date:      2015-06-12 15:16 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/jdk/rev/51fcffa4c693

Fixing trailing whitespaces; adding newlines at the end of the files

! src/jdk.jline/share/classes/jdk/internal/jline/WindowsTerminal.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/ConsoleReader.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/CursorBuffer.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/KeyMap.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/completer/EnumCompleter.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/completer/NullCompleter.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/completer/StringsCompleter.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/completer/package-info.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/history/FileHistory.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/history/History.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/history/PersistentHistory.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/history/package-info.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/internal/ConsoleReaderInputStream.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/internal/ConsoleRunner.java
! src/jdk.jline/share/classes/jdk/internal/jline/console/package-info.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/Configuration.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/InputStreamReader.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/Log.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/NonBlockingInputStream.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/Preconditions.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/ShutdownHooks.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/TestAccessible.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/Urls.java
! src/jdk.jline/share/classes/jdk/internal/jline/internal/package-info.java
! src/jdk.jline/share/classes/jdk/internal/jline/package-info.java


From robert.field at oracle.com  Sun Jun 14 06:07:52 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Sun, 14 Jun 2015 06:07:52 +0000
Subject: hg: kulla/dev/langtools: Rationalize and normalize assertEval test
	framework. All eval() testing now channelled through one
	method. Resultant tests inspect all returned information. Also
	clean-up key retrieval. And clarify KeyStatusEvent.exception
Message-ID: <201506140607.t5E67qsC021793@aojmv0008.oracle.com>

Changeset: 35e0284f0a30
Author:    rfield
Date:      2015-06-13 23:07 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/35e0284f0a30

Rationalize and normalize assertEval test framework.  All eval() testing now channelled through one method.  Resultant tests inspect all returned information.  Also clean-up key retrieval.  And clarify KeyStatusEvent.exception

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/jshell/KeyStatusEvent.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/EmptyTest.java
! test/jdk/jshell/ExceptionsTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ModifiersTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Sun Jun 14 17:41:47 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Sun, 14 Jun 2015 17:41:47 +0000
Subject: hg: kulla/dev/langtools: Clean up assertEvalKey usage. Clean up
	imports.
Message-ID: <201506141741.t5EHflDR003343@aojmv0008.oracle.com>

Changeset: 3b9c10f5fdad
Author:    rfield
Date:      2015-06-14 10:41 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/3b9c10f5fdad

Clean up assertEvalKey usage. Clean up imports.

! test/jdk/jshell/ClassMembersTest.java
! test/jdk/jshell/ClassPathTest.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/EmptyTest.java
! test/jdk/jshell/ExceptionsTest.java
! test/jdk/jshell/IOTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ModifiersTest.java
! test/jdk/jshell/NullTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/StopExecutionTest.java
! test/jdk/jshell/TypeNameTest.java


From robert.field at oracle.com  Sun Jun 14 18:59:35 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Sun, 14 Jun 2015 18:59:35 +0000
Subject: hg: kulla/dev/langtools: Clean-up key access and checking in tests.
Message-ID: <201506141859.t5EIxZtI014303@aojmv0008.oracle.com>

Changeset: e11953e8701f
Author:    rfield
Date:      2015-06-14 11:59 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/e11953e8701f

Clean-up key access and checking in tests.

! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/ExceptionsTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/ShutdownTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/TypeNameTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Mon Jun 15 04:18:45 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Mon, 15 Jun 2015 04:18:45 +0000
Subject: hg: kulla/dev/langtools: More prep for event dispatch testing. Unify
	drop and eval event testing. Deepen drop testing.
Message-ID: <201506150418.t5F4IjZO005409@aojmv0008.oracle.com>

Changeset: f8bedc348233
Author:    rfield
Date:      2015-06-14 21:18 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/f8bedc348233

More prep for event dispatch testing. Unify drop and eval event testing.  Deepen drop testing.

! test/jdk/jshell/DropTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Mon Jun 15 06:30:22 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Mon, 15 Jun 2015 06:30:22 +0000
Subject: hg: kulla/dev/langtools: 8081275: JShell API: switch to status
	transition events; ...
Message-ID: <201506150630.t5F6UMmT025417@aojmv0008.oracle.com>

Changeset: 35fd521a15df
Author:    rfield
Date:      2015-06-14 23:30 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/35fd521a15df

8081275: JShell API: switch to status transition events
8087297: JShell tests: add event dispatch tests
Summary: This completes the series of commits for moving to an event based model and adding event dispatch. Every eval() and drop() test has dispatched events compared to returned events.

! test/jdk/jshell/KullaTesting.java


From robert.field at oracle.com  Mon Jun 15 15:32:02 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Mon, 15 Jun 2015 15:32:02 +0000
Subject: hg: kulla/dev/langtools: 8082911: JShell API: Remove
	JShellStateClosedException, use IllegalStateException instead
Message-ID: <201506151532.t5FFW2hd003976@aojmv0008.oracle.com>

Changeset: 7e8995e214f9
Author:    rfield
Date:      2015-06-15 08:31 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/7e8995e214f9

8082911: JShell API: Remove JShellStateClosedException, use IllegalStateException instead

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
- src/jdk.jshell/share/classes/jdk/jshell/JShellStateClosedException.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/ShutdownTest.java


From robert.field at oracle.com  Mon Jun 15 16:39:34 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Mon, 15 Jun 2015 16:39:34 +0000
Subject: hg: kulla/dev/langtools: 8081849: JShell API: Code style for enum
	values is to use CONSTANT_CASE, not ClassCase
Message-ID: <201506151639.t5FGdYSp017182@aojmv0008.oracle.com>

Changeset: 931863fc203d
Author:    rfield
Date:      2015-06-15 09:39 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/931863fc203d

8081849: JShell API: Code style for enum values is to use CONSTANT_CASE, not ClassCase

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyMap.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
! src/jdk.jshell/share/classes/jdk/jshell/Key.java
! src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/RejectedFailedTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/TypeNameTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Mon Jun 15 18:39:25 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Mon, 15 Jun 2015 18:39:25 +0000
Subject: hg: kulla/dev/langtools: 8084732: JShell API: move JShellState.Status
	to Key.Status
Message-ID: <201506151839.t5FIdPc2006159@aojmv0008.oracle.com>

Changeset: 8e56a0d26a25
Author:    rfield
Date:      2015-06-15 11:39 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/8e56a0d26a25

8084732: JShell API: move JShellState.Status to Key.Status

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
! src/jdk.jshell/share/classes/jdk/jshell/Key.java
! src/jdk.jshell/share/classes/jdk/jshell/KeyStatusEvent.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/RejectedFailedTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/TypeNameTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Tue Jun 16 06:23:08 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 16 Jun 2015 06:23:08 +0000
Subject: hg: kulla/dev/langtools: 8081851: JShell API: merge JShellState into
	JShell
Message-ID: <201506160623.t5G6N8vv019995@aojmv0008.oracle.com>

Changeset: ff5f775df948
Author:    rfield
Date:      2015-06-15 23:22 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/ff5f775df948

8081851: JShell API: merge JShellState into JShell

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JDIEnv.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JDIExecution.java
+ src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellFactory.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java < src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellStateImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyMap.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/MemoryFileManager.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetMaps.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/TaskFactory.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/VMConnection.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
- src/jdk.jshell/share/classes/jdk/jshell/JShellState.java
! src/jdk.jshell/share/classes/jdk/jshell/Key.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/HistoryTest.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/ShutdownTest.java
! test/jdk/jshell/StopExecutionTest.java


From robert.field at oracle.com  Thu Jun 18 04:35:21 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 18 Jun 2015 04:35:21 +0000
Subject: hg: kulla/dev/langtools: partial (JShell and EvalException) 8129093:
	JShell API: flesh-out, update, and properly format the API javadocs
Message-ID: <201506180435.t5I4ZLEU019964@aojmv0008.oracle.com>

Changeset: 35ff264aef86
Author:    rfield
Date:      2015-06-17 21:35 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/35ff264aef86

partial (JShell and EvalException) 8129093: JShell API: flesh-out, update, and properly format the API javadocs

! src/jdk.jshell/share/classes/jdk/jshell/EvalException.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java


From andrei.eremeev at oracle.com  Fri Jun 19 15:21:28 2015
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Fri, 19 Jun 2015 18:21:28 +0300
Subject: Bugs
Message-ID: <55843378.3030403@oracle.com>

Hi REPL team,

Currently, I am working on JShell plugin which uses JCK to test JShell 
(thank you to Sergei Pikalev who made the flexible mechanism for test 
manipulation).
The plugin uncovered several issues in forward references.

https://bugs.openjdk.java.net/browse/JDK-8129337
https://bugs.openjdk.java.net/browse/JDK-8114842
https://bugs.openjdk.java.net/browse/JDK-8114837
https://bugs.openjdk.java.net/browse/JDK-8114836

Andrei Eremeev

From sebastien.cogneau at gmail.com  Fri Jun 19 15:26:49 2015
From: sebastien.cogneau at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Cogneau?=)
Date: Fri, 19 Jun 2015 17:26:49 +0200
Subject: Interested in contributing to kulla
Message-ID: <CACz5XrbRa7CK_RundHcQQxeqkQktAvB0NVeLHU5S+1dVxRb5Lw@mail.gmail.com>

Hi all,

I've just discovered kulla and I find it really nice.
I am wondering if you'd like to have new contributor, and if yes is there
some open issues which would make a good starting point to contribute?

Cheers,
S?bastien

From robert.field at oracle.com  Sat Jun 20 01:11:35 2015
From: robert.field at oracle.com (Robert Field)
Date: Fri, 19 Jun 2015 18:11:35 -0700
Subject: JShell/Kulla towards JDK9 and Fix Version
Message-ID: <5584BDC7.40905@oracle.com>

We believe the core work of JShell is done, that the functionality is 
there and fairly stable, and yes sure there are bugs to fix, but they 
are not too glaring.  What that means is it is time to work towards 
moving JShell into the JDK9 main-line repo!

This also has an effect on what Fix Version we use.  Work that we need 
to do before it goes into JDK9 (e.g., API docs clean-up) or, because of 
timing, we know will go into the Kulla repo should continue to use the 
9-repo-kulla Fix Version.  Everything else, including almost all bug 
reports, should have Fix Version: 9.

-Robert


From andrei.eremeev at oracle.com  Sat Jun 20 15:01:37 2015
From: andrei.eremeev at oracle.com (Andrei Eremeev)
Date: Sat, 20 Jun 2015 08:01:37 -0700 (PDT)
Subject: Interested in contributing to kulla
Message-ID: <2fdd273a-e3b0-4cf0-8ae9-a6beb420cb33@default>

Hi Sebastien,

To find open issues, go to http://bugs.openjdk.java.net/, there use the following query: "component = tools AND Subcomponent = jshell and resolution = unresolved".
There you can find three dozens of open bugs. Moreover, you can find some new bugs. :)

Additionally, look at code coverage (http://cr.openjdk.java.net/~aeremeev/jshell-coverage/), not the latest version, but you can develop some new tests for jshell.

Andrei Eremeev

----- Original Message -----
From: sebastien.cogneau at gmail.com
To: kulla-dev at openjdk.java.net
Sent: Friday, June 19, 2015 6:27:34 PM GMT +03:00 Iraq
Subject: Interested in contributing to kulla

Hi all,

I've just discovered kulla and I find it really nice.
I am wondering if you'd like to have new contributor, and if yes is there
some open issues which would make a good starting point to contribute?

Cheers,
S?bastien

From andrei.eremeev at oracle.com  Sat Jun 20 17:47:01 2015
From: andrei.eremeev at oracle.com (Andrei Eremeev)
Date: Sat, 20 Jun 2015 10:47:01 -0700 (PDT)
Subject: JShell/Kulla towards JDK9 and Fix Version
Message-ID: <9b501b35-bc2f-4501-87b4-71e9f295711f@default>

Noted!

Before integrating Kulla to JDK9 all excluded tests for JShell should be cleaned up:
1. Now if a test is excluded, it has "@Test(enabled = false)" annotation, so jtreg does not indicate nothing. Instead of using the annotation, "@ignore" jtreg tag should be used. In this case, we won't miss that a test will never be run.
2. Each of the excluded tests should have an open bug in JBS. The bug id should be written in "@ignore" tag.

Andrei Eremeev

----- Original Message -----
From: robert.field at oracle.com
To: kulla-dev at openjdk.java.net
Sent: Saturday, June 20, 2015 4:12:14 AM GMT +03:00 Iraq
Subject: JShell/Kulla towards JDK9 and Fix Version

We believe the core work of JShell is done, that the functionality is 
there and fairly stable, and yes sure there are bugs to fix, but they 
are not too glaring.  What that means is it is time to work towards 
moving JShell into the JDK9 main-line repo!

This also has an effect on what Fix Version we use.  Work that we need 
to do before it goes into JDK9 (e.g., API docs clean-up) or, because of 
timing, we know will go into the Kulla repo should continue to use the 
9-repo-kulla Fix Version.  Everything else, including almost all bug 
reports, should have Fix Version: 9.

-Robert


From robert.field at oracle.com  Sat Jun 20 23:17:24 2015
From: robert.field at oracle.com (Robert Field)
Date: Sat, 20 Jun 2015 16:17:24 -0700
Subject: JShell/Kulla towards JDK9 and Fix Version
In-Reply-To: <9b501b35-bc2f-4501-87b4-71e9f295711f@default>
References: <9b501b35-bc2f-4501-87b4-71e9f295711f@default>
Message-ID: <5585F484.1060809@oracle.com>


On 06/20/15 10:47, Andrei Eremeev wrote:
> Noted!
>
> Before integrating Kulla to JDK9 all excluded tests for JShell should be cleaned up:
> 1. Now if a test is excluded, it has "@Test(enabled = false)" annotation, so jtreg does not indicate nothing. Instead of using the annotation, "@ignore" jtreg tag should be used. In this case, we won't miss that a test will never be run.
> 2. Each of the excluded tests should have an open bug in JBS. The bug id should be written in "@ignore" tag.

Sounds good.  Are you signed up for that task?  Would you like a bug 
assigned to you for it?

Thanks,
Robert

>
> Andrei Eremeev
>
> ----- Original Message -----
> From: robert.field at oracle.com
> To: kulla-dev at openjdk.java.net
> Sent: Saturday, June 20, 2015 4:12:14 AM GMT +03:00 Iraq
> Subject: JShell/Kulla towards JDK9 and Fix Version
>
> We believe the core work of JShell is done, that the functionality is
> there and fairly stable, and yes sure there are bugs to fix, but they
> are not too glaring.  What that means is it is time to work towards
> moving JShell into the JDK9 main-line repo!
>
> This also has an effect on what Fix Version we use.  Work that we need
> to do before it goes into JDK9 (e.g., API docs clean-up) or, because of
> timing, we know will go into the Kulla repo should continue to use the
> 9-repo-kulla Fix Version.  Everything else, including almost all bug
> reports, should have Fix Version: 9.
>
> -Robert
>


From robert.field at oracle.com  Sun Jun 21 02:19:15 2015
From: robert.field at oracle.com (Robert Field)
Date: Sat, 20 Jun 2015 19:19:15 -0700
Subject: Kulla: API naming question JLS vs JVM class
Message-ID: <55861F23.9090707@oracle.com>

Keys for what is called a "class" in the JVM (that is a class, enum, 
interface, or annotation interface in JLS speak) have Key.Kind.CLASS and 
are instances of Key.ClassKey.

This is awkward both in terms of documenting them (I'm referencing the 
JLS) and because the SubKind values are JLS-speak:

     CLASS_SUBKIND(Key.Kind.CLASS),
     INTERFACE_SUBKIND(Key.Kind.CLASS),
     ENUM_SUBKIND(Key.Kind.CLASS),
     ANNOTATION_TYPE_SUBKIND(Key.Kind.CLASS),

Looking at the JLS the syntax production is TypeDeclaration.  So, I 
think the Key.Kind should be changed to TYPE.

It could be changed to TYPE_DECLARATION but then we would want to also 
change VARIABLE and METHOD to

    VARIABLE_DECLARATION
    METHOD_DECLARATION

Which would make use pretty verbose.  Could be abbreviated, but the API 
currently mostly shies away from abbreviations.

So, the choices are:

(1)   TYPE   TypeKey

(2)   TYPE_DECLARATION   TypeDeclarationKey

(3)    TYPE_DECL   TypeDeclKey

(4)    CLASS   ClassKey

What do you all think?

Thanks,
Robert


From robert.field at oracle.com  Sun Jun 21 03:21:49 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Sun, 21 Jun 2015 03:21:49 +0000
Subject: hg: kulla/dev/langtools: partial (Key) 8129093: JShell API: flesh-out,
	update, and properly format the API javadocs
Message-ID: <201506210321.t5L3LnZF025954@aojmv0008.oracle.com>

Changeset: 047fc2fc11ae
Author:    rfield
Date:      2015-06-20 20:21 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/047fc2fc11ae

partial (Key) 8129093: JShell API: flesh-out, update, and properly format the API javadocs

! src/jdk.jshell/share/classes/jdk/jshell/Key.java


From forax at univ-mlv.fr  Sun Jun 21 08:06:41 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sun, 21 Jun 2015 08:06:41 +0000
Subject: Kulla: API naming question JLS vs JVM class
In-Reply-To: <55861F23.9090707@oracle.com>
References: <55861F23.9090707@oracle.com>
Message-ID: <973E22C3-4484-455C-9A83-69D489295A88@univ-mlv.fr>

TYPE is ok for me.

R?mi 

Le 21 juin 2015 04:19:15 CEST, Robert Field <robert.field at oracle.com> a ?crit :
>Keys for what is called a "class" in the JVM (that is a class, enum, 
>interface, or annotation interface in JLS speak) have Key.Kind.CLASS
>and 
>are instances of Key.ClassKey.
>
>This is awkward both in terms of documenting them (I'm referencing the 
>JLS) and because the SubKind values are JLS-speak:
>
>     CLASS_SUBKIND(Key.Kind.CLASS),
>     INTERFACE_SUBKIND(Key.Kind.CLASS),
>     ENUM_SUBKIND(Key.Kind.CLASS),
>     ANNOTATION_TYPE_SUBKIND(Key.Kind.CLASS),
>
>Looking at the JLS the syntax production is TypeDeclaration.  So, I 
>think the Key.Kind should be changed to TYPE.
>
>It could be changed to TYPE_DECLARATION but then we would want to also 
>change VARIABLE and METHOD to
>
>    VARIABLE_DECLARATION
>    METHOD_DECLARATION
>
>Which would make use pretty verbose.  Could be abbreviated, but the API
>
>currently mostly shies away from abbreviations.
>
>So, the choices are:
>
>(1)   TYPE   TypeKey
>
>(2)   TYPE_DECLARATION   TypeDeclarationKey
>
>(3)    TYPE_DECL   TypeDeclKey
>
>(4)    CLASS   ClassKey
>
>What do you all think?
>
>Thanks,
>Robert


From martijnverburg at gmail.com  Sun Jun 21 17:48:27 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 21 Jun 2015 18:48:27 +0100
Subject: How to build kulla
In-Reply-To: <5585FA73.4020108@oracle.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<CAGHtMWkripHkxhD63jT__LhFacwA4PkOqXRqn3vRty+e6-L4JQ@mail.gmail.com>
	<14cae0ac278.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWn7nYSaOU8Q2tqz-HnM7z=OZLExwTeixom54HFWJ0akTg@mail.gmail.com>
	<CAP7YuASF3KNrj0oRRdsTVB6O23Ng7MXYT+uhh+mcZFm3LczfUQ@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
Message-ID: <CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>

Hi Robert,

Does this mean for the kulla-dev forest I could go:

hg clone <url for kulla-dev>
./get_source.sh
make clean images

And the REPL will be available?



Cheers,
Martijn

On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com> wrote:

>  Dear Mani, Martijn,
>
> Thank you for this work.
>
> Kulla (aka JShell) has moved quite a ways now towards being ready to merge
> into JDK9.  Jline is now integrated into the jdk side of the Kulla repo.
> This version of jline has been made more platform independent (no longer
> requiring the external native libraries).  JShell now uses this.
>
> As a result the unit of a Kulla/JShell build is now a full JDK build.
> Would it be possible to do full Kulla JDK builds now?
>
> Thanks,
> Robert
>
>
>
> On 04/25/15 05:40, Mani Sarkar wrote:
>
> You are welcome Robert.
>
>  I noticed you guys have moved the sources around, so I have update our
> build farm to reflect that.
>
>  Start build 27, see
> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/27/,
> we have a working version again (please do not download artefacts previous
> to this one).
>
>  Cheers,
> Mani
>
>
> On Mon, Apr 20, 2015 at 4:21 PM, Robert Field <robert.field at oracle.com>
> wrote:
>
>>   Thank you Mani!
>> Once the integration with the JDK is done (my hope is in a couple weeks)
>> the build process will be a normal JDK build process.
>>
>> Thanks,
>> Robert
>>
>> On April 19, 2015 11:38:40 AM Mani Sarkar <sadhak001 at gmail.com> wrote:
>>
>>> Your/our wish is now a reality. We can now download the latest builds of
>>> kulla.jar from the AdoptOpenJDK Cloudbees farm, see
>>>
>>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/lastSuccessfulBuild/artifact/
>>>
>>>  Both the artefacts are the fact same binaries, I have named them to
>>> identify the version and timestamp in one and mavenised the name in the
>>> other.
>>>
>>>  It takes about 2 minutes to build and will be triggered regularly as
>>> and when changes are pushed into the repo.
>>>
>>>  It does not run test or stress tests yet, but depending on the
>>> stability of these on the Cloudbees we will enable it. Of course it will be
>>> good to build and distribute binaries after it passes these checks.
>>>
>>>  Thanks and enjoy using it - please send your feedback to the mailing
>>> list.
>>>
>>>  Cheers,
>>> Mani
>>>
>>> On Wed, Apr 15, 2015 at 9:15 PM, Robert Field <robert.field at oracle.com>
>>> wrote:
>>>
>>>> Yes, we want regular OpenJDK Kulla builds.  I first step along that
>>>> path is that I need to integrate the REPL into the JDK/langtools.  I will
>>>> be beginning on that probably next week.
>>>>
>>>> -Robert
>>>>
>>>>
>>>> On 04/15/15 00:09, Martijn Verburg wrote:
>>>>
>>>>> Hi Mani,
>>>>>
>>>>> For now you'll have to replace the location of kulla.jar with
>>>>> instructions
>>>>> on how to build it from scratch.
>>>>>
>>>>> @kull-dev - Robert - is it possible to talk to the powers that be about
>>>>> being allowed to host nightly/weekly builds of kulla.jar? I'd prefer
>>>>> to see
>>>>> it hosted/provided by official OpenJDK infrastructure but we could also
>>>>> build and host it nightly on our Adopt OpenJDK Cloudbees instance.
>>>>>
>>>>> I know that most of code-tools is now allowed to be hosted in a binary
>>>>> format (you can speak to Jonathan Gibbons about that) so hopefully this
>>>>> should be doable.
>>>>>
>>>>> Cheers,
>>>>> Martijn
>>>>>
>>>>> On 15 April 2015 at 02:02, Mani Sarkar <sadhak001 at gmail.com> wrote:
>>>>>
>>>>>  I meant this page
>>>>>>
>>>>>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/openjdk-projects/kulla.html
>>>>>> .
>>>>>>
>>>>>> On Wed, Apr 15, 2015 at 1:00 AM, Mani Sarkar <sadhak001 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>  I have put together a page, with all the tips, tricks and links one
>>>>>>> must
>>>>>>> have at their finger tips with regards to Kulla.
>>>>>>>
>>>>>>> If you have any more to add to it, please let me know.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mani
>>>>>>>
>>>>>>> On Tue, Apr 14, 2015 at 11:41 PM, Mani Sarkar <sadhak001 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>  Hi Martijn
>>>>>>>>
>>>>>>>> Just saw the message, glad all is good. I think the instructions
>>>>>>>> should
>>>>>>>> mention to keep a tab of the JDK on the PATH and the JAVA_HOME env
>>>>>>>> variables, and they point to JDK9.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mani
>>>>>>>>
>>>>>>>> On Tue, Apr 14, 2015 at 10:34 AM, Martijn Verburg <
>>>>>>>> martijnverburg at gmail.com> wrote:
>>>>>>>>
>>>>>>>>  Hi Andrei,
>>>>>>>>>
>>>>>>>>> It was the incorrect JDK!  All working now thanks.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Martijn
>>>>>>>>>
>>>>>>>>> On 14 April 2015 at 09:57, andrei.eremeev <
>>>>>>>>> andrei.eremeev at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  Hi Martijn,
>>>>>>>>>>
>>>>>>>>>>  Hi Mani/All,
>>>>>>>>>>>
>>>>>>>>>>> I'm running across compile issues like:
>>>>>>>>>>>
>>>>>>>>>>> src/impl/CompletenessAnalyzer.java:28: error: package
>>>>>>>>>>> com.sun.tools.javac.code does not exist
>>>>>>>>>>> import com.sun.tools.javac.code.Source;
>>>>>>>>>>>                                  ^
>>>>>>>>>>>
>>>>>>>>>>>  What JDK do you use to build/run REPL? JDK 8?
>>>>>>>>>> Clone and build this JDK:
>>>>>>>>>>    hg clone http://hg.openjdk.java.net/kulla/dev repl
>>>>>>>>>>    cd repl
>>>>>>>>>>    bash get_source.sh
>>>>>>>>>>    make images
>>>>>>>>>> Building might require installing additional packages.
>>>>>>>>>>
>>>>>>>>>> Thereafter, set and export JAVA_HOME:
>>>>>>>>>> ${PATH-TO-REPO}/build/${OS}/images/jdk
>>>>>>>>>> and PATH: ${JAVA_HOME}/bin:${PATH}.
>>>>>>>>>> Ensure that the version of JDK is 1.9:
>>>>>>>>>>    java -version
>>>>>>>>>>
>>>>>>>>>>  Also as an aside, the shell script assumes Linux (Mac OS X has sh
>>>>>>>>>>> located
>>>>>>>>>>> at #!/bin/sh)
>>>>>>>>>>>
>>>>>>>>>>>  Run script as "sh scripts/compile.sh" or "bash
>>>>>>>>>> scripts/compile.sh".
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Martijn
>>>>>>>>>>>
>>>>>>>>>>>  Andrei Eremeev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  On 14 April 2015 at 00:25, Mani Sarkar <sadhak001 at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>   Thanks Robert, works like  charm, also figured out how to
>>>>>>>>>>> create the
>>>>>>>>>>>
>>>>>>>>>>>> jar
>>>>>>>>>>>> for it.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Mani
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Apr 12, 2015 at 3:31 PM, Robert Field <
>>>>>>>>>>>> robert.field at oracle.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>   Yes, that is the right library. Get that library and install
>>>>>>>>>>>> on your
>>>>>>>>>>>>
>>>>>>>>>>>>> machine. There is an environment variable in compile.sh --
>>>>>>>>>>>>> don't
>>>>>>>>>>>>> have
>>>>>>>>>>>>> access right now so I don't remainder is name but it should be
>>>>>>>>>>>>> obvious --
>>>>>>>>>>>>> set that environment variable to the location of the unpacked
>>>>>>>>>>>>> jline2
>>>>>>>>>>>>> library.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then run using the run.sh script.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hour that helps,
>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On April 12, 2015 6:58:38 AM Mani Sarkar <sadhak001 at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    To give some more information from the above, when I did the
>>>>>>>>>>>>> below:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     sh ./scripts/compile.sh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the response we got:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/tool/Repl.java:88: error: package jline.console does not
>>>>>>>>>>>>>> exist
>>>>>>>>>>>>>> import jline.console.ConsoleReader;
>>>>>>>>>>>>>>                       ^
>>>>>>>>>>>>>> src/tool/Repl.java:89: error: package jline.console does not
>>>>>>>>>>>>>> exist
>>>>>>>>>>>>>> import jline.console.KeyMap;
>>>>>>>>>>>>>>                       ^
>>>>>>>>>>>>>> src/tool/Repl.java:90: error: package jline.console.completer
>>>>>>>>>>>>>> does
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> exist
>>>>>>>>>>>>>> import jline.console.completer.Completer;
>>>>>>>>>>>>>>                                 ^
>>>>>>>>>>>>>> src/tool/Repl.java:91: error: package jline.console.history
>>>>>>>>>>>>>> does
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  exist
>>>>>>>>>>>>> import jline.console.history.History;
>>>>>>>>>>>>>
>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>> src/tool/Repl.java:92: error: package jline.console.history
>>>>>>>>>>>>>> does
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  exist
>>>>>>>>>>>>> import jline.console.history.MemoryHistory;
>>>>>>>>>>>>>
>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>> src/tool/Repl.java:1502: error: cannot find symbol
>>>>>>>>>>>>>>       final ConsoleReader in;
>>>>>>>>>>>>>>             ^
>>>>>>>>>>>>>>     symbol:   class ConsoleReader
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1645: error: cannot find symbol
>>>>>>>>>>>>>>       private final class EditingHistory implements History {
>>>>>>>>>>>>>>                                                     ^
>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1647: error: cannot find symbol
>>>>>>>>>>>>>>           private final History fullHistory;
>>>>>>>>>>>>>>                         ^
>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>> src/tool/Repl.java:1648: error: cannot find symbol
>>>>>>>>>>>>>>           private History currentDelegate;
>>>>>>>>>>>>>>                   ^
>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>> src/tool/Repl.java:1650: error: cannot find symbol
>>>>>>>>>>>>>>           public EditingHistory(History delegateTo) {
>>>>>>>>>>>>>>                                 ^
>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>> error: Class names, 'build', are only accepted if annotation
>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  is
>>>>>>>>>>>>> explicitly requested
>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/tool/Repl.java:1507: error: cannot find symbol
>>>>>>>>>>>>>>           in = new ConsoleReader(cmdin, cmdout);
>>>>>>>>>>>>>>                    ^
>>>>>>>>>>>>>>     symbol:   class ConsoleReader
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1532: error: cannot find symbol
>>>>>>>>>>>>>>           in.addCompleter(new Completer() {
>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>     symbol:   class Completer
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1596: error: cannot find symbol
>>>>>>>>>>>>>>           KeyMap km = in.getKeys();
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1599: error: cannot find symbol
>>>>>>>>>>>>>>               if (value instanceof KeyMap) {
>>>>>>>>>>>>>>                                    ^
>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1600: error: cannot find symbol
>>>>>>>>>>>>>>                   km = (KeyMap) value;
>>>>>>>>>>>>>>                         ^
>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>> src/tool/Repl.java:1655: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1660: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1665: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1670: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1677: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1682: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1687: error: cannot find symbol
>>>>>>>>>>>>>>                           if (!(entry.value() instanceof
>>>>>>>>>>>>>> NarrowingHistoryLine))
>>>>>>>>>>>>>>                                      ^
>>>>>>>>>>>>>>     symbol:   method value()
>>>>>>>>>>>>>>     location: variable entry of type Entry
>>>>>>>>>>>>>> src/tool/Repl.java:1689: error: cannot find symbol
>>>>>>>>>>>>>>                           int[] cluster =
>>>>>>>>>>>>>> ((NarrowingHistoryLine)
>>>>>>>>>>>>>> entry.value()).span;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      ^
>>>>>>>>>>>>>>     symbol:   method value()
>>>>>>>>>>>>>>     location: variable entry of type Entry
>>>>>>>>>>>>>> src/tool/Repl.java:1691: error: cannot find symbol
>>>>>>>>>>>>>>                               currentDelegate = new
>>>>>>>>>>>>>> MemoryHistory();
>>>>>>>>>>>>>>                                                     ^
>>>>>>>>>>>>>>     symbol:   class MemoryHistory
>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>> src/tool/Repl.java:1722: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1729: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1736: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1743: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1750: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1757: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1762: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1767: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1772: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1777: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1782: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1787: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1792: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1797: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> src/tool/Repl.java:1802: error: method does not override or
>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>> 40 errors
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Apr 12, 2015 at 1:50 PM, Mani Sarkar <
>>>>>>>>>>>>>> sadhak001 at gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  I'm at the LJC hackday in London and we are trying out Kulla
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> like to know how to go about build kulla.jar from the
>>>>>>>>>>>>>>> OpenjDK code
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  base, I
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  came across this link (README file)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://hg.openjdk.java.net/kulla/dev/langtools/file/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  4933dc482be7/repl/README
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  but no luck trying to build it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What should this variable point to JLINE2LIB ? Is this the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  library
>>>>>>>>>>>>>>
>>>>>>>>>>>>> as
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  https://github.com/jline/jline2 ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any help is appreciated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>>>>>> **Blog
>>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
>>>>>>>>>>>>>>> LJC
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Advocate
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>>> success
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  come
>>>>>>>>>>>>>>
>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>>>>> **Blog
>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
>>>>>>>>>>>>>> LJC
>>>>>>>>>>>>>> Advocate
>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>>>>>>> will come
>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>  --
>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>>> **Blog
>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>>>>>> Advocate
>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>
>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>>>>> will
>>>>>>>>>>>> come
>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> --
>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>> Advocate
>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>
>>>>>>>> *Don't chase success, rather aim for "Excellence", and success will
>>>>>>>> come
>>>>>>>> chasing after you!*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>> Advocate
>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>
>>>>>>> *Don't chase success, rather aim for "Excellence", and success will
>>>>>>> come
>>>>>>> chasing after you!*
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>> Advocate
>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>
>>>>>> *Don't chase success, rather aim for "Excellence", and success will
>>>>>> come
>>>>>> chasing after you!*
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>  --
>>>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
>>> (@adoptopenjdk & @adoptajsr programs)
>>> *Meet-a-Project - *MutabilityDetector
>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>
>>>  *Don't chase success, rather aim for "Excellence", and success will
>>> come chasing after you!*
>>>
>>
>
>
>  --
>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> <https://bitbucket.org/neomatrix369>* * |  **Github
> <https://github.com/neomatrix369>* * |  **LinkedIn
> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>
>  *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>
>
>

From robert.field at oracle.com  Sun Jun 21 18:20:23 2015
From: robert.field at oracle.com (Robert Field)
Date: Sun, 21 Jun 2015 11:20:23 -0700
Subject: How to build kulla
In-Reply-To: <CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<CAGHtMWkripHkxhD63jT__LhFacwA4PkOqXRqn3vRty+e6-L4JQ@mail.gmail.com>
	<14cae0ac278.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWn7nYSaOU8Q2tqz-HnM7z=OZLExwTeixom54HFWJ0akTg@mail.gmail.com>
	<CAP7YuASF3KNrj0oRRdsTVB6O23Ng7MXYT+uhh+mcZFm3LczfUQ@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
Message-ID: <14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Yep.

Executed with: jshell

-R



On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com> wrote:

> Hi Robert,
>
> Does this mean for the kulla-dev forest I could go:
>
> hg clone <url for kulla-dev>
> ./get_source.sh
> make clean images
>
> And the REPL will be available?
>
>
>
> Cheers,
> Martijn
>
> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com> wrote:
>
> >  Dear Mani, Martijn,
> >
> > Thank you for this work.
> >
> > Kulla (aka JShell) has moved quite a ways now towards being ready to merge
> > into JDK9.  Jline is now integrated into the jdk side of the Kulla repo.
> > This version of jline has been made more platform independent (no longer
> > requiring the external native libraries).  JShell now uses this.
> >
> > As a result the unit of a Kulla/JShell build is now a full JDK build.
> > Would it be possible to do full Kulla JDK builds now?
> >
> > Thanks,
> > Robert
> >
> >
> >
> > On 04/25/15 05:40, Mani Sarkar wrote:
> >
> > You are welcome Robert.
> >
> >  I noticed you guys have moved the sources around, so I have update our
> > build farm to reflect that.
> >
> >  Start build 27, see
> > 
> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/27/,
> > we have a working version again (please do not download artefacts previous
> > to this one).
> >
> >  Cheers,
> > Mani
> >
> >
> > On Mon, Apr 20, 2015 at 4:21 PM, Robert Field <robert.field at oracle.com>
> > wrote:
> >
> >>   Thank you Mani!
> >> Once the integration with the JDK is done (my hope is in a couple weeks)
> >> the build process will be a normal JDK build process.
> >>
> >> Thanks,
> >> Robert
> >>
> >> On April 19, 2015 11:38:40 AM Mani Sarkar <sadhak001 at gmail.com> wrote:
> >>
> >>> Your/our wish is now a reality. We can now download the latest builds of
> >>> kulla.jar from the AdoptOpenJDK Cloudbees farm, see
> >>>
> >>> 
> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/lastSuccessfulBuild/artifact/
> >>>
> >>>  Both the artefacts are the fact same binaries, I have named them to
> >>> identify the version and timestamp in one and mavenised the name in the
> >>> other.
> >>>
> >>>  It takes about 2 minutes to build and will be triggered regularly as
> >>> and when changes are pushed into the repo.
> >>>
> >>>  It does not run test or stress tests yet, but depending on the
> >>> stability of these on the Cloudbees we will enable it. Of course it will be
> >>> good to build and distribute binaries after it passes these checks.
> >>>
> >>>  Thanks and enjoy using it - please send your feedback to the mailing
> >>> list.
> >>>
> >>>  Cheers,
> >>> Mani
> >>>
> >>> On Wed, Apr 15, 2015 at 9:15 PM, Robert Field <robert.field at oracle.com>
> >>> wrote:
> >>>
> >>>> Yes, we want regular OpenJDK Kulla builds.  I first step along that
> >>>> path is that I need to integrate the REPL into the JDK/langtools.  I will
> >>>> be beginning on that probably next week.
> >>>>
> >>>> -Robert
> >>>>
> >>>>
> >>>> On 04/15/15 00:09, Martijn Verburg wrote:
> >>>>
> >>>>> Hi Mani,
> >>>>>
> >>>>> For now you'll have to replace the location of kulla.jar with
> >>>>> instructions
> >>>>> on how to build it from scratch.
> >>>>>
> >>>>> @kull-dev - Robert - is it possible to talk to the powers that be about
> >>>>> being allowed to host nightly/weekly builds of kulla.jar? I'd prefer
> >>>>> to see
> >>>>> it hosted/provided by official OpenJDK infrastructure but we could also
> >>>>> build and host it nightly on our Adopt OpenJDK Cloudbees instance.
> >>>>>
> >>>>> I know that most of code-tools is now allowed to be hosted in a binary
> >>>>> format (you can speak to Jonathan Gibbons about that) so hopefully this
> >>>>> should be doable.
> >>>>>
> >>>>> Cheers,
> >>>>> Martijn
> >>>>>
> >>>>> On 15 April 2015 at 02:02, Mani Sarkar <sadhak001 at gmail.com> wrote:
> >>>>>
> >>>>>  I meant this page
> >>>>>>
> >>>>>> 
> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/openjdk-projects/kulla.html
> >>>>>> .
> >>>>>>
> >>>>>> On Wed, Apr 15, 2015 at 1:00 AM, Mani Sarkar <sadhak001 at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>  I have put together a page, with all the tips, tricks and links one
> >>>>>>> must
> >>>>>>> have at their finger tips with regards to Kulla.
> >>>>>>>
> >>>>>>> If you have any more to add to it, please let me know.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Mani
> >>>>>>>
> >>>>>>> On Tue, Apr 14, 2015 at 11:41 PM, Mani Sarkar <sadhak001 at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>  Hi Martijn
> >>>>>>>>
> >>>>>>>> Just saw the message, glad all is good. I think the instructions
> >>>>>>>> should
> >>>>>>>> mention to keep a tab of the JDK on the PATH and the JAVA_HOME env
> >>>>>>>> variables, and they point to JDK9.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Mani
> >>>>>>>>
> >>>>>>>> On Tue, Apr 14, 2015 at 10:34 AM, Martijn Verburg <
> >>>>>>>> martijnverburg at gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>  Hi Andrei,
> >>>>>>>>>
> >>>>>>>>> It was the incorrect JDK!  All working now thanks.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Martijn
> >>>>>>>>>
> >>>>>>>>> On 14 April 2015 at 09:57, andrei.eremeev <
> >>>>>>>>> andrei.eremeev at oracle.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>  Hi Martijn,
> >>>>>>>>>>
> >>>>>>>>>>  Hi Mani/All,
> >>>>>>>>>>>
> >>>>>>>>>>> I'm running across compile issues like:
> >>>>>>>>>>>
> >>>>>>>>>>> src/impl/CompletenessAnalyzer.java:28: error: package
> >>>>>>>>>>> com.sun.tools.javac.code does not exist
> >>>>>>>>>>> import com.sun.tools.javac.code.Source;
> >>>>>>>>>>>                                  ^
> >>>>>>>>>>>
> >>>>>>>>>>>  What JDK do you use to build/run REPL? JDK 8?
> >>>>>>>>>> Clone and build this JDK:
> >>>>>>>>>>    hg clone http://hg.openjdk.java.net/kulla/dev repl
> >>>>>>>>>>    cd repl
> >>>>>>>>>>    bash get_source.sh
> >>>>>>>>>>    make images
> >>>>>>>>>> Building might require installing additional packages.
> >>>>>>>>>>
> >>>>>>>>>> Thereafter, set and export JAVA_HOME:
> >>>>>>>>>> ${PATH-TO-REPO}/build/${OS}/images/jdk
> >>>>>>>>>> and PATH: ${JAVA_HOME}/bin:${PATH}.
> >>>>>>>>>> Ensure that the version of JDK is 1.9:
> >>>>>>>>>>    java -version
> >>>>>>>>>>
> >>>>>>>>>>  Also as an aside, the shell script assumes Linux (Mac OS X has sh
> >>>>>>>>>>> located
> >>>>>>>>>>> at #!/bin/sh)
> >>>>>>>>>>>
> >>>>>>>>>>>  Run script as "sh scripts/compile.sh" or "bash
> >>>>>>>>>> scripts/compile.sh".
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Martijn
> >>>>>>>>>>>
> >>>>>>>>>>>  Andrei Eremeev
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>  On 14 April 2015 at 00:25, Mani Sarkar <sadhak001 at gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>   Thanks Robert, works like  charm, also figured out how to
> >>>>>>>>>>> create the
> >>>>>>>>>>>
> >>>>>>>>>>>> jar
> >>>>>>>>>>>> for it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Mani
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sun, Apr 12, 2015 at 3:31 PM, Robert Field <
> >>>>>>>>>>>> robert.field at oracle.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>   Yes, that is the right library. Get that library and install
> >>>>>>>>>>>> on your
> >>>>>>>>>>>>
> >>>>>>>>>>>>> machine. There is an environment variable in compile.sh --
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>> access right now so I don't remainder is name but it should be
> >>>>>>>>>>>>> obvious --
> >>>>>>>>>>>>> set that environment variable to the location of the unpacked
> >>>>>>>>>>>>> jline2
> >>>>>>>>>>>>> library.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Then run using the run.sh script.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hour that helps,
> >>>>>>>>>>>>> Robert
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On April 12, 2015 6:58:38 AM Mani Sarkar <sadhak001 at gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>    To give some more information from the above, when I did the
> >>>>>>>>>>>>> below:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>     sh ./scripts/compile.sh
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Here's the response we got:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> src/tool/Repl.java:88: error: package jline.console does not
> >>>>>>>>>>>>>> exist
> >>>>>>>>>>>>>> import jline.console.ConsoleReader;
> >>>>>>>>>>>>>>                       ^
> >>>>>>>>>>>>>> src/tool/Repl.java:89: error: package jline.console does not
> >>>>>>>>>>>>>> exist
> >>>>>>>>>>>>>> import jline.console.KeyMap;
> >>>>>>>>>>>>>>                       ^
> >>>>>>>>>>>>>> src/tool/Repl.java:90: error: package jline.console.completer
> >>>>>>>>>>>>>> does
> >>>>>>>>>>>>>> not
> >>>>>>>>>>>>>> exist
> >>>>>>>>>>>>>> import jline.console.completer.Completer;
> >>>>>>>>>>>>>>                                 ^
> >>>>>>>>>>>>>> src/tool/Repl.java:91: error: package jline.console.history
> >>>>>>>>>>>>>> does
> >>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  exist
> >>>>>>>>>>>>> import jline.console.history.History;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>                               ^
> >>>>>>>>>>>>>> src/tool/Repl.java:92: error: package jline.console.history
> >>>>>>>>>>>>>> does
> >>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  exist
> >>>>>>>>>>>>> import jline.console.history.MemoryHistory;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>                               ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1502: error: cannot find symbol
> >>>>>>>>>>>>>>       final ConsoleReader in;
> >>>>>>>>>>>>>>             ^
> >>>>>>>>>>>>>>     symbol:   class ConsoleReader
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1645: error: cannot find symbol
> >>>>>>>>>>>>>>       private final class EditingHistory implements History {
> >>>>>>>>>>>>>>                                                     ^
> >>>>>>>>>>>>>>     symbol:   class History
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1647: error: cannot find symbol
> >>>>>>>>>>>>>>           private final History fullHistory;
> >>>>>>>>>>>>>>                         ^
> >>>>>>>>>>>>>>     symbol:   class History
> >>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
> >>>>>>>>>>>>>> src/tool/Repl.java:1648: error: cannot find symbol
> >>>>>>>>>>>>>>           private History currentDelegate;
> >>>>>>>>>>>>>>                   ^
> >>>>>>>>>>>>>>     symbol:   class History
> >>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
> >>>>>>>>>>>>>> src/tool/Repl.java:1650: error: cannot find symbol
> >>>>>>>>>>>>>>           public EditingHistory(History delegateTo) {
> >>>>>>>>>>>>>>                                 ^
> >>>>>>>>>>>>>>     symbol:   class History
> >>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
> >>>>>>>>>>>>>> error: Class names, 'build', are only accepted if annotation
> >>>>>>>>>>>>>> processing
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  is
> >>>>>>>>>>>>> explicitly requested
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> src/tool/Repl.java:1507: error: cannot find symbol
> >>>>>>>>>>>>>>           in = new ConsoleReader(cmdin, cmdout);
> >>>>>>>>>>>>>>                    ^
> >>>>>>>>>>>>>>     symbol:   class ConsoleReader
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1532: error: cannot find symbol
> >>>>>>>>>>>>>>           in.addCompleter(new Completer() {
> >>>>>>>>>>>>>>                               ^
> >>>>>>>>>>>>>>     symbol:   class Completer
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1596: error: cannot find symbol
> >>>>>>>>>>>>>>           KeyMap km = in.getKeys();
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>>     symbol:   class KeyMap
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1599: error: cannot find symbol
> >>>>>>>>>>>>>>               if (value instanceof KeyMap) {
> >>>>>>>>>>>>>>                                    ^
> >>>>>>>>>>>>>>     symbol:   class KeyMap
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1600: error: cannot find symbol
> >>>>>>>>>>>>>>                   km = (KeyMap) value;
> >>>>>>>>>>>>>>                         ^
> >>>>>>>>>>>>>>     symbol:   class KeyMap
> >>>>>>>>>>>>>>     location: class ConsoleIOContext
> >>>>>>>>>>>>>> src/tool/Repl.java:1655: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1660: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1665: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1670: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1677: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1682: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1687: error: cannot find symbol
> >>>>>>>>>>>>>>                           if (!(entry.value() instanceof
> >>>>>>>>>>>>>> NarrowingHistoryLine))
> >>>>>>>>>>>>>>                                      ^
> >>>>>>>>>>>>>>     symbol:   method value()
> >>>>>>>>>>>>>>     location: variable entry of type Entry
> >>>>>>>>>>>>>> src/tool/Repl.java:1689: error: cannot find symbol
> >>>>>>>>>>>>>>                           int[] cluster =
> >>>>>>>>>>>>>> ((NarrowingHistoryLine)
> >>>>>>>>>>>>>> entry.value()).span;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>      ^
> >>>>>>>>>>>>>>     symbol:   method value()
> >>>>>>>>>>>>>>     location: variable entry of type Entry
> >>>>>>>>>>>>>> src/tool/Repl.java:1691: error: cannot find symbol
> >>>>>>>>>>>>>>                               currentDelegate = new
> >>>>>>>>>>>>>> MemoryHistory();
> >>>>>>>>>>>>>>                                                     ^
> >>>>>>>>>>>>>>     symbol:   class MemoryHistory
> >>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
> >>>>>>>>>>>>>> src/tool/Repl.java:1722: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1729: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1736: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1743: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1750: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1757: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1762: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1767: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1772: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1777: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1782: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1787: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1792: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1797: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> src/tool/Repl.java:1802: error: method does not override or
> >>>>>>>>>>>>>> implement a
> >>>>>>>>>>>>>> method from a supertype
> >>>>>>>>>>>>>>           @Override
> >>>>>>>>>>>>>>           ^
> >>>>>>>>>>>>>> 40 errors
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>> Mani
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sun, Apr 12, 2015 at 1:50 PM, Mani Sarkar <
> >>>>>>>>>>>>>> sadhak001 at gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  wrote:
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>  I'm at the LJC hackday in London and we are trying out Kulla
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>> like to know how to go about build kulla.jar from the
> >>>>>>>>>>>>>>> OpenjDK code
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  base, I
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  came across this link (README file)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> http://hg.openjdk.java.net/kulla/dev/langtools/file/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  4933dc482be7/repl/README
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  but no luck trying to build it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> What should this variable point to JLINE2LIB ? Is this the
> >>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  library
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> as
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>  https://github.com/jline/jline2 ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Any help is appreciated.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>> Mani
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
> >>>>>>>>>>>>>>> **Blog
> >>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
> >>>>>>>>>>>>>>> LJC
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  Advocate
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>  *Meet-a-Project - *MutabilityDetector
> >>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
> >>>>>>>>>>>>>>> success
> >>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  come
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> chasing after you!*
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  --
> >>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
> >>>>>>>>>>>>>> **Blog
> >>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
> >>>>>>>>>>>>>> LJC
> >>>>>>>>>>>>>> Advocate
> >>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
> >>>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
> >>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
> >>>>>>>>>>>>>> will come
> >>>>>>>>>>>>>> chasing after you!*
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>  --
> >>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
> >>>>>>>>>>>> **Blog
> >>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
> >>>>>>>>>>>> Advocate
> >>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
> >>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
> >>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>>>>>>>>>>
> >>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
> >>>>>>>>>>>> will
> >>>>>>>>>>>> come
> >>>>>>>>>>>> chasing after you!*
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>> --
> >>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> >>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
> >>>>>>>> Advocate
> >>>>>>>> (@adoptopenjdk & @adoptajsr programs)
> >>>>>>>> *Meet-a-Project - *MutabilityDetector
> >>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>>>>>>
> >>>>>>>> *Don't chase success, rather aim for "Excellence", and success will
> >>>>>>>> come
> >>>>>>>> chasing after you!*
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> >>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
> >>>>>>> Advocate
> >>>>>>> (@adoptopenjdk & @adoptajsr programs)
> >>>>>>> *Meet-a-Project - *MutabilityDetector
> >>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>>>>>
> >>>>>>> *Don't chase success, rather aim for "Excellence", and success will
> >>>>>>> come
> >>>>>>> chasing after you!*
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> >>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
> >>>>>> Advocate
> >>>>>> (@adoptopenjdk & @adoptajsr programs)
> >>>>>> *Meet-a-Project - *MutabilityDetector
> >>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>>>>
> >>>>>> *Don't chase success, rather aim for "Excellence", and success will
> >>>>>> come
> >>>>>> chasing after you!*
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>>  --
> >>>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> >>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
> >>> (@adoptopenjdk & @adoptajsr programs)
> >>> *Meet-a-Project - *MutabilityDetector
> >>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> >>> <https://bitbucket.org/neomatrix369>* * |  **Github
> >>> <https://github.com/neomatrix369>* * |  **LinkedIn
> >>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> >>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >>>
> >>>  *Don't chase success, rather aim for "Excellence", and success will
> >>> come chasing after you!*
> >>>
> >>
> >
> >
> >  --
> >  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> > <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
> > (@adoptopenjdk & @adoptajsr programs)
> > *Meet-a-Project - *MutabilityDetector
> > <https://github.com/MutabilityDetector>*  |  **Bitbucket
> > <https://bitbucket.org/neomatrix369>* * |  **Github
> > <https://github.com/neomatrix369>* * |  **LinkedIn
> > <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> > *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
> >
> >  *Don't chase success, rather aim for "Excellence", and success will come
> > chasing after you!*
> >
> >
> >

From martijnverburg at gmail.com  Sun Jun 21 18:44:09 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 21 Jun 2015 19:44:09 +0100
Subject: How to build kulla
In-Reply-To: <14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<CAGHtMWkripHkxhD63jT__LhFacwA4PkOqXRqn3vRty+e6-L4JQ@mail.gmail.com>
	<14cae0ac278.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWn7nYSaOU8Q2tqz-HnM7z=OZLExwTeixom54HFWJ0akTg@mail.gmail.com>
	<CAP7YuASF3KNrj0oRRdsTVB6O23Ng7MXYT+uhh+mcZFm3LczfUQ@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>

Hi Robert,

We should be able to help.  I'm a little out of action at present, but
hopefully Mani sees this and will get the build up and running.

Cheers,
Martijn

On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:

>   Yep.
>
> Executed with: jshell
>
> -R
>
> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> Hi Robert,
>>
>> Does this mean for the kulla-dev forest I could go:
>>
>> hg clone <url for kulla-dev>
>> ./get_source.sh
>> make clean images
>>
>> And the REPL will be available?
>>
>>
>>
>> Cheers,
>> Martijn
>>
>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com> wrote:
>>
>>>  Dear Mani, Martijn,
>>>
>>> Thank you for this work.
>>>
>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>> repo.  This version of jline has been made more platform independent (no
>>> longer requiring the external native libraries).  JShell now uses this.
>>>
>>> As a result the unit of a Kulla/JShell build is now a full JDK build.
>>> Would it be possible to do full Kulla JDK builds now?
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>>
>>> On 04/25/15 05:40, Mani Sarkar wrote:
>>>
>>> You are welcome Robert.
>>>
>>>  I noticed you guys have moved the sources around, so I have update our
>>> build farm to reflect that.
>>>
>>>  Start build 27, see
>>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/27/,
>>> we have a working version again (please do not download artefacts previous
>>> to this one).
>>>
>>>  Cheers,
>>> Mani
>>>
>>>
>>> On Mon, Apr 20, 2015 at 4:21 PM, Robert Field <robert.field at oracle.com>
>>> wrote:
>>>
>>>>   Thank you Mani!
>>>> Once the integration with the JDK is done (my hope is in a couple
>>>> weeks) the build process will be a normal JDK build process.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>> On April 19, 2015 11:38:40 AM Mani Sarkar <sadhak001 at gmail.com> wrote:
>>>>
>>>>> Your/our wish is now a reality. We can now download the latest builds
>>>>> of kulla.jar from the AdoptOpenJDK Cloudbees farm, see
>>>>>
>>>>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/lastSuccessfulBuild/artifact/
>>>>>
>>>>>  Both the artefacts are the fact same binaries, I have named them to
>>>>> identify the version and timestamp in one and mavenised the name in the
>>>>> other.
>>>>>
>>>>>  It takes about 2 minutes to build and will be triggered regularly as
>>>>> and when changes are pushed into the repo.
>>>>>
>>>>>  It does not run test or stress tests yet, but depending on the
>>>>> stability of these on the Cloudbees we will enable it. Of course it will be
>>>>> good to build and distribute binaries after it passes these checks.
>>>>>
>>>>>  Thanks and enjoy using it - please send your feedback to the mailing
>>>>> list.
>>>>>
>>>>>  Cheers,
>>>>> Mani
>>>>>
>>>>> On Wed, Apr 15, 2015 at 9:15 PM, Robert Field <robert.field at oracle.com
>>>>> > wrote:
>>>>>
>>>>>> Yes, we want regular OpenJDK Kulla builds.  I first step along that
>>>>>> path is that I need to integrate the REPL into the JDK/langtools.  I will
>>>>>> be beginning on that probably next week.
>>>>>>
>>>>>> -Robert
>>>>>>
>>>>>>
>>>>>> On 04/15/15 00:09, Martijn Verburg wrote:
>>>>>>
>>>>>>> Hi Mani,
>>>>>>>
>>>>>>> For now you'll have to replace the location of kulla.jar with
>>>>>>> instructions
>>>>>>> on how to build it from scratch.
>>>>>>>
>>>>>>> @kull-dev - Robert - is it possible to talk to the powers that be
>>>>>>> about
>>>>>>> being allowed to host nightly/weekly builds of kulla.jar? I'd prefer
>>>>>>> to see
>>>>>>> it hosted/provided by official OpenJDK infrastructure but we could
>>>>>>> also
>>>>>>> build and host it nightly on our Adopt OpenJDK Cloudbees instance.
>>>>>>>
>>>>>>> I know that most of code-tools is now allowed to be hosted in a
>>>>>>> binary
>>>>>>> format (you can speak to Jonathan Gibbons about that) so hopefully
>>>>>>> this
>>>>>>> should be doable.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martijn
>>>>>>>
>>>>>>> On 15 April 2015 at 02:02, Mani Sarkar <sadhak001 at gmail.com> wrote:
>>>>>>>
>>>>>>>  I meant this page
>>>>>>>>
>>>>>>>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/openjdk-projects/kulla.html
>>>>>>>> .
>>>>>>>>
>>>>>>>> On Wed, Apr 15, 2015 at 1:00 AM, Mani Sarkar <sadhak001 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>  I have put together a page, with all the tips, tricks and links
>>>>>>>>> one must
>>>>>>>>> have at their finger tips with regards to Kulla.
>>>>>>>>>
>>>>>>>>> If you have any more to add to it, please let me know.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Mani
>>>>>>>>>
>>>>>>>>> On Tue, Apr 14, 2015 at 11:41 PM, Mani Sarkar <sadhak001 at gmail.com
>>>>>>>>> >
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  Hi Martijn
>>>>>>>>>>
>>>>>>>>>> Just saw the message, glad all is good. I think the instructions
>>>>>>>>>> should
>>>>>>>>>> mention to keep a tab of the JDK on the PATH and the JAVA_HOME env
>>>>>>>>>> variables, and they point to JDK9.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Mani
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 14, 2015 at 10:34 AM, Martijn Verburg <
>>>>>>>>>> martijnverburg at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>  Hi Andrei,
>>>>>>>>>>>
>>>>>>>>>>> It was the incorrect JDK!  All working now thanks.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Martijn
>>>>>>>>>>>
>>>>>>>>>>> On 14 April 2015 at 09:57, andrei.eremeev <
>>>>>>>>>>> andrei.eremeev at oracle.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>  Hi Martijn,
>>>>>>>>>>>>
>>>>>>>>>>>>  Hi Mani/All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm running across compile issues like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> src/impl/CompletenessAnalyzer.java:28: error: package
>>>>>>>>>>>>> com.sun.tools.javac.code does not exist
>>>>>>>>>>>>> import com.sun.tools.javac.code.Source;
>>>>>>>>>>>>>                                  ^
>>>>>>>>>>>>>
>>>>>>>>>>>>>  What JDK do you use to build/run REPL? JDK 8?
>>>>>>>>>>>> Clone and build this JDK:
>>>>>>>>>>>>    hg clone http://hg.openjdk.java.net/kulla/dev repl
>>>>>>>>>>>>    cd repl
>>>>>>>>>>>>    bash get_source.sh
>>>>>>>>>>>>    make images
>>>>>>>>>>>> Building might require installing additional packages.
>>>>>>>>>>>>
>>>>>>>>>>>> Thereafter, set and export JAVA_HOME:
>>>>>>>>>>>> ${PATH-TO-REPO}/build/${OS}/images/jdk
>>>>>>>>>>>> and PATH: ${JAVA_HOME}/bin:${PATH}.
>>>>>>>>>>>> Ensure that the version of JDK is 1.9:
>>>>>>>>>>>>    java -version
>>>>>>>>>>>>
>>>>>>>>>>>>  Also as an aside, the shell script assumes Linux (Mac OS X has
>>>>>>>>>>>>> sh
>>>>>>>>>>>>> located
>>>>>>>>>>>>> at #!/bin/sh)
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Run script as "sh scripts/compile.sh" or "bash
>>>>>>>>>>>> scripts/compile.sh".
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Martijn
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Andrei Eremeev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  On 14 April 2015 at 00:25, Mani Sarkar <sadhak001 at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Thanks Robert, works like  charm, also figured out how to
>>>>>>>>>>>>> create the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>> for it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Apr 12, 2015 at 3:31 PM, Robert Field <
>>>>>>>>>>>>>> robert.field at oracle.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Yes, that is the right library. Get that library and
>>>>>>>>>>>>>> install on your
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> machine. There is an environment variable in compile.sh --
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> access right now so I don't remainder is name but it should
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> obvious --
>>>>>>>>>>>>>>> set that environment variable to the location of the
>>>>>>>>>>>>>>> unpacked jline2
>>>>>>>>>>>>>>> library.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then run using the run.sh script.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hour that helps,
>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On April 12, 2015 6:58:38 AM Mani Sarkar <
>>>>>>>>>>>>>>> sadhak001 at gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    To give some more information from the above, when I did
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     sh ./scripts/compile.sh
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's the response we got:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> src/tool/Repl.java:88: error: package jline.console does
>>>>>>>>>>>>>>>> not exist
>>>>>>>>>>>>>>>> import jline.console.ConsoleReader;
>>>>>>>>>>>>>>>>                       ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:89: error: package jline.console does
>>>>>>>>>>>>>>>> not exist
>>>>>>>>>>>>>>>> import jline.console.KeyMap;
>>>>>>>>>>>>>>>>                       ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:90: error: package
>>>>>>>>>>>>>>>> jline.console.completer does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> exist
>>>>>>>>>>>>>>>> import jline.console.completer.Completer;
>>>>>>>>>>>>>>>>                                 ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:91: error: package jline.console.history
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  exist
>>>>>>>>>>>>>>> import jline.console.history.History;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:92: error: package jline.console.history
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  exist
>>>>>>>>>>>>>>> import jline.console.history.MemoryHistory;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1502: error: cannot find symbol
>>>>>>>>>>>>>>>>       final ConsoleReader in;
>>>>>>>>>>>>>>>>             ^
>>>>>>>>>>>>>>>>     symbol:   class ConsoleReader
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1645: error: cannot find symbol
>>>>>>>>>>>>>>>>       private final class EditingHistory implements History
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>                                                     ^
>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1647: error: cannot find symbol
>>>>>>>>>>>>>>>>           private final History fullHistory;
>>>>>>>>>>>>>>>>                         ^
>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>> src/tool/Repl.java:1648: error: cannot find symbol
>>>>>>>>>>>>>>>>           private History currentDelegate;
>>>>>>>>>>>>>>>>                   ^
>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>> src/tool/Repl.java:1650: error: cannot find symbol
>>>>>>>>>>>>>>>>           public EditingHistory(History delegateTo) {
>>>>>>>>>>>>>>>>                                 ^
>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>> error: Class names, 'build', are only accepted if annotation
>>>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  is
>>>>>>>>>>>>>>> explicitly requested
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> src/tool/Repl.java:1507: error: cannot find symbol
>>>>>>>>>>>>>>>>           in = new ConsoleReader(cmdin, cmdout);
>>>>>>>>>>>>>>>>                    ^
>>>>>>>>>>>>>>>>     symbol:   class ConsoleReader
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1532: error: cannot find symbol
>>>>>>>>>>>>>>>>           in.addCompleter(new Completer() {
>>>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>>>     symbol:   class Completer
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1596: error: cannot find symbol
>>>>>>>>>>>>>>>>           KeyMap km = in.getKeys();
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1599: error: cannot find symbol
>>>>>>>>>>>>>>>>               if (value instanceof KeyMap) {
>>>>>>>>>>>>>>>>                                    ^
>>>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1600: error: cannot find symbol
>>>>>>>>>>>>>>>>                   km = (KeyMap) value;
>>>>>>>>>>>>>>>>                         ^
>>>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>> src/tool/Repl.java:1655: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1660: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1665: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1670: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1677: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1682: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1687: error: cannot find symbol
>>>>>>>>>>>>>>>>                           if (!(entry.value() instanceof
>>>>>>>>>>>>>>>> NarrowingHistoryLine))
>>>>>>>>>>>>>>>>                                      ^
>>>>>>>>>>>>>>>>     symbol:   method value()
>>>>>>>>>>>>>>>>     location: variable entry of type Entry
>>>>>>>>>>>>>>>> src/tool/Repl.java:1689: error: cannot find symbol
>>>>>>>>>>>>>>>>                           int[] cluster =
>>>>>>>>>>>>>>>> ((NarrowingHistoryLine)
>>>>>>>>>>>>>>>> entry.value()).span;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      ^
>>>>>>>>>>>>>>>>     symbol:   method value()
>>>>>>>>>>>>>>>>     location: variable entry of type Entry
>>>>>>>>>>>>>>>> src/tool/Repl.java:1691: error: cannot find symbol
>>>>>>>>>>>>>>>>                               currentDelegate = new
>>>>>>>>>>>>>>>> MemoryHistory();
>>>>>>>>>>>>>>>>                                                     ^
>>>>>>>>>>>>>>>>     symbol:   class MemoryHistory
>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>> src/tool/Repl.java:1722: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1729: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1736: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1743: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1750: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1757: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1762: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1767: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1772: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1777: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1782: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1787: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1792: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1797: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> src/tool/Repl.java:1802: error: method does not override or
>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>> 40 errors
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Apr 12, 2015 at 1:50 PM, Mani Sarkar <
>>>>>>>>>>>>>>>> sadhak001 at gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  I'm at the LJC hackday in London and we are trying out
>>>>>>>>>>>>>>>>> Kulla and
>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>> like to know how to go about build kulla.jar from the
>>>>>>>>>>>>>>>>> OpenjDK code
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  base, I
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  came across this link (README file)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/kulla/dev/langtools/file/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  4933dc482be7/repl/README
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  but no luck trying to build it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What should this variable point to JLINE2LIB ? Is this the
>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  library
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  https://github.com/jline/jline2 ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any help is appreciated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*
>>>>>>>>>>>>>>>>> |  **Blog
>>>>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate
>>>>>>>>>>>>>>>>> & LJC
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  Advocate
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>>>>> success
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  come
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>>>>>>> **Blog
>>>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
>>>>>>>>>>>>>>>> LJC
>>>>>>>>>>>>>>>> Advocate
>>>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>>>> success
>>>>>>>>>>>>>>>> will come
>>>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>>>>> **Blog
>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
>>>>>>>>>>>>>> LJC
>>>>>>>>>>>>>> Advocate
>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>> success will
>>>>>>>>>>>>>> come
>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>>>> Advocate
>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>
>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>>> will come
>>>>>>>>>> chasing after you!*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>>> Advocate
>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>
>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>> will come
>>>>>>>>> chasing after you!*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>> Advocate
>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>
>>>>>>>> *Don't chase success, rather aim for "Excellence", and success will
>>>>>>>> come
>>>>>>>> chasing after you!*
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>> Advocate (@adoptopenjdk & @adoptajsr programs)
>>>>> *Meet-a-Project - *MutabilityDetector
>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>
>>>>>  *Don't chase success, rather aim for "Excellence", and success will
>>>>> come chasing after you!*
>>>>>
>>>>
>>>
>>>
>>>  --
>>>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
>>> (@adoptopenjdk & @adoptajsr programs)
>>> *Meet-a-Project - *MutabilityDetector
>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>
>>>  *Don't chase success, rather aim for "Excellence", and success will
>>> come chasing after you!*
>>>
>>>
>>>
>>

From sadhak001 at gmail.com  Sun Jun 21 19:06:57 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Sun, 21 Jun 2015 20:06:57 +0100
Subject: How to build kulla
In-Reply-To: <CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<CAGHtMWkripHkxhD63jT__LhFacwA4PkOqXRqn3vRty+e6-L4JQ@mail.gmail.com>
	<14cae0ac278.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWn7nYSaOU8Q2tqz-HnM7z=OZLExwTeixom54HFWJ0akTg@mail.gmail.com>
	<CAP7YuASF3KNrj0oRRdsTVB6O23Ng7MXYT+uhh+mcZFm3LczfUQ@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>
Message-ID: <CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>

Hi Martijn, Robert,

This is good news, I should get my head around this soon and have something
in place using your suggestions.

@Robert - we still like to extract the classes and produce a .jar file so
that others can download it from our CI servers, does the mechanism to do
that remains the same. Or are you also saying that the make clean images
creates a .jar file in the build folder alongside the images folder (JDK
and JRE).

Cheers.
Mani

On Sun, Jun 21, 2015 at 7:44 PM, Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi Robert,
>
> We should be able to help.  I'm a little out of action at present, but
> hopefully Mani sees this and will get the build up and running.
>
> Cheers,
> Martijn
>
> On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:
>
>>   Yep.
>>
>> Executed with: jshell
>>
>> -R
>>
>> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Does this mean for the kulla-dev forest I could go:
>>>
>>> hg clone <url for kulla-dev>
>>> ./get_source.sh
>>> make clean images
>>>
>>> And the REPL will be available?
>>>
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com> wrote:
>>>
>>>>  Dear Mani, Martijn,
>>>>
>>>> Thank you for this work.
>>>>
>>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>>> repo.  This version of jline has been made more platform independent (no
>>>> longer requiring the external native libraries).  JShell now uses this.
>>>>
>>>> As a result the unit of a Kulla/JShell build is now a full JDK build.
>>>> Would it be possible to do full Kulla JDK builds now?
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
>>>>
>>>> On 04/25/15 05:40, Mani Sarkar wrote:
>>>>
>>>> You are welcome Robert.
>>>>
>>>>  I noticed you guys have moved the sources around, so I have update
>>>> our build farm to reflect that.
>>>>
>>>>  Start build 27, see
>>>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/27/,
>>>> we have a working version again (please do not download artefacts previous
>>>> to this one).
>>>>
>>>>  Cheers,
>>>> Mani
>>>>
>>>>
>>>> On Mon, Apr 20, 2015 at 4:21 PM, Robert Field <robert.field at oracle.com>
>>>> wrote:
>>>>
>>>>>   Thank you Mani!
>>>>> Once the integration with the JDK is done (my hope is in a couple
>>>>> weeks) the build process will be a normal JDK build process.
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>> On April 19, 2015 11:38:40 AM Mani Sarkar <sadhak001 at gmail.com> wrote:
>>>>>
>>>>>> Your/our wish is now a reality. We can now download the latest builds
>>>>>> of kulla.jar from the AdoptOpenJDK Cloudbees farm, see
>>>>>>
>>>>>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/lastSuccessfulBuild/artifact/
>>>>>>
>>>>>>  Both the artefacts are the fact same binaries, I have named them to
>>>>>> identify the version and timestamp in one and mavenised the name in the
>>>>>> other.
>>>>>>
>>>>>>  It takes about 2 minutes to build and will be triggered regularly
>>>>>> as and when changes are pushed into the repo.
>>>>>>
>>>>>>  It does not run test or stress tests yet, but depending on the
>>>>>> stability of these on the Cloudbees we will enable it. Of course it will be
>>>>>> good to build and distribute binaries after it passes these checks.
>>>>>>
>>>>>>  Thanks and enjoy using it - please send your feedback to the
>>>>>> mailing list.
>>>>>>
>>>>>>  Cheers,
>>>>>> Mani
>>>>>>
>>>>>> On Wed, Apr 15, 2015 at 9:15 PM, Robert Field <
>>>>>> robert.field at oracle.com> wrote:
>>>>>>
>>>>>>> Yes, we want regular OpenJDK Kulla builds.  I first step along that
>>>>>>> path is that I need to integrate the REPL into the JDK/langtools.  I will
>>>>>>> be beginning on that probably next week.
>>>>>>>
>>>>>>> -Robert
>>>>>>>
>>>>>>>
>>>>>>> On 04/15/15 00:09, Martijn Verburg wrote:
>>>>>>>
>>>>>>>> Hi Mani,
>>>>>>>>
>>>>>>>> For now you'll have to replace the location of kulla.jar with
>>>>>>>> instructions
>>>>>>>> on how to build it from scratch.
>>>>>>>>
>>>>>>>> @kull-dev - Robert - is it possible to talk to the powers that be
>>>>>>>> about
>>>>>>>> being allowed to host nightly/weekly builds of kulla.jar? I'd
>>>>>>>> prefer to see
>>>>>>>> it hosted/provided by official OpenJDK infrastructure but we could
>>>>>>>> also
>>>>>>>> build and host it nightly on our Adopt OpenJDK Cloudbees instance.
>>>>>>>>
>>>>>>>> I know that most of code-tools is now allowed to be hosted in a
>>>>>>>> binary
>>>>>>>> format (you can speak to Jonathan Gibbons about that) so hopefully
>>>>>>>> this
>>>>>>>> should be doable.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martijn
>>>>>>>>
>>>>>>>> On 15 April 2015 at 02:02, Mani Sarkar <sadhak001 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>  I meant this page
>>>>>>>>>
>>>>>>>>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/openjdk-projects/kulla.html
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> On Wed, Apr 15, 2015 at 1:00 AM, Mani Sarkar <sadhak001 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  I have put together a page, with all the tips, tricks and links
>>>>>>>>>> one must
>>>>>>>>>> have at their finger tips with regards to Kulla.
>>>>>>>>>>
>>>>>>>>>> If you have any more to add to it, please let me know.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Mani
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 14, 2015 at 11:41 PM, Mani Sarkar <
>>>>>>>>>> sadhak001 at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>  Hi Martijn
>>>>>>>>>>>
>>>>>>>>>>> Just saw the message, glad all is good. I think the instructions
>>>>>>>>>>> should
>>>>>>>>>>> mention to keep a tab of the JDK on the PATH and the JAVA_HOME
>>>>>>>>>>> env
>>>>>>>>>>> variables, and they point to JDK9.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Mani
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 14, 2015 at 10:34 AM, Martijn Verburg <
>>>>>>>>>>> martijnverburg at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>  Hi Andrei,
>>>>>>>>>>>>
>>>>>>>>>>>> It was the incorrect JDK!  All working now thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Martijn
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 April 2015 at 09:57, andrei.eremeev <
>>>>>>>>>>>> andrei.eremeev at oracle.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  Hi Martijn,
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Hi Mani/All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm running across compile issues like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/impl/CompletenessAnalyzer.java:28: error: package
>>>>>>>>>>>>>> com.sun.tools.javac.code does not exist
>>>>>>>>>>>>>> import com.sun.tools.javac.code.Source;
>>>>>>>>>>>>>>                                  ^
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  What JDK do you use to build/run REPL? JDK 8?
>>>>>>>>>>>>> Clone and build this JDK:
>>>>>>>>>>>>>    hg clone http://hg.openjdk.java.net/kulla/dev repl
>>>>>>>>>>>>>    cd repl
>>>>>>>>>>>>>    bash get_source.sh
>>>>>>>>>>>>>    make images
>>>>>>>>>>>>> Building might require installing additional packages.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thereafter, set and export JAVA_HOME:
>>>>>>>>>>>>> ${PATH-TO-REPO}/build/${OS}/images/jdk
>>>>>>>>>>>>> and PATH: ${JAVA_HOME}/bin:${PATH}.
>>>>>>>>>>>>> Ensure that the version of JDK is 1.9:
>>>>>>>>>>>>>    java -version
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Also as an aside, the shell script assumes Linux (Mac OS X
>>>>>>>>>>>>>> has sh
>>>>>>>>>>>>>> located
>>>>>>>>>>>>>> at #!/bin/sh)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Run script as "sh scripts/compile.sh" or "bash
>>>>>>>>>>>>> scripts/compile.sh".
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Martijn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Andrei Eremeev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  On 14 April 2015 at 00:25, Mani Sarkar <sadhak001 at gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Thanks Robert, works like  charm, also figured out how to
>>>>>>>>>>>>>> create the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>> for it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Apr 12, 2015 at 3:31 PM, Robert Field <
>>>>>>>>>>>>>>> robert.field at oracle.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Yes, that is the right library. Get that library and
>>>>>>>>>>>>>>> install on your
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> machine. There is an environment variable in compile.sh --
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> access right now so I don't remainder is name but it should
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> obvious --
>>>>>>>>>>>>>>>> set that environment variable to the location of the
>>>>>>>>>>>>>>>> unpacked jline2
>>>>>>>>>>>>>>>> library.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then run using the run.sh script.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hour that helps,
>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On April 12, 2015 6:58:38 AM Mani Sarkar <
>>>>>>>>>>>>>>>> sadhak001 at gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    To give some more information from the above, when I did
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     sh ./scripts/compile.sh
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here's the response we got:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> src/tool/Repl.java:88: error: package jline.console does
>>>>>>>>>>>>>>>>> not exist
>>>>>>>>>>>>>>>>> import jline.console.ConsoleReader;
>>>>>>>>>>>>>>>>>                       ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:89: error: package jline.console does
>>>>>>>>>>>>>>>>> not exist
>>>>>>>>>>>>>>>>> import jline.console.KeyMap;
>>>>>>>>>>>>>>>>>                       ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:90: error: package
>>>>>>>>>>>>>>>>> jline.console.completer does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> exist
>>>>>>>>>>>>>>>>> import jline.console.completer.Completer;
>>>>>>>>>>>>>>>>>                                 ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:91: error: package
>>>>>>>>>>>>>>>>> jline.console.history does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  exist
>>>>>>>>>>>>>>>> import jline.console.history.History;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:92: error: package
>>>>>>>>>>>>>>>>> jline.console.history does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  exist
>>>>>>>>>>>>>>>> import jline.console.history.MemoryHistory;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1502: error: cannot find symbol
>>>>>>>>>>>>>>>>>       final ConsoleReader in;
>>>>>>>>>>>>>>>>>             ^
>>>>>>>>>>>>>>>>>     symbol:   class ConsoleReader
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1645: error: cannot find symbol
>>>>>>>>>>>>>>>>>       private final class EditingHistory implements
>>>>>>>>>>>>>>>>> History {
>>>>>>>>>>>>>>>>>                                                     ^
>>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1647: error: cannot find symbol
>>>>>>>>>>>>>>>>>           private final History fullHistory;
>>>>>>>>>>>>>>>>>                         ^
>>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1648: error: cannot find symbol
>>>>>>>>>>>>>>>>>           private History currentDelegate;
>>>>>>>>>>>>>>>>>                   ^
>>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1650: error: cannot find symbol
>>>>>>>>>>>>>>>>>           public EditingHistory(History delegateTo) {
>>>>>>>>>>>>>>>>>                                 ^
>>>>>>>>>>>>>>>>>     symbol:   class History
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>>> error: Class names, 'build', are only accepted if
>>>>>>>>>>>>>>>>> annotation
>>>>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  is
>>>>>>>>>>>>>>>> explicitly requested
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1507: error: cannot find symbol
>>>>>>>>>>>>>>>>>           in = new ConsoleReader(cmdin, cmdout);
>>>>>>>>>>>>>>>>>                    ^
>>>>>>>>>>>>>>>>>     symbol:   class ConsoleReader
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1532: error: cannot find symbol
>>>>>>>>>>>>>>>>>           in.addCompleter(new Completer() {
>>>>>>>>>>>>>>>>>                               ^
>>>>>>>>>>>>>>>>>     symbol:   class Completer
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1596: error: cannot find symbol
>>>>>>>>>>>>>>>>>           KeyMap km = in.getKeys();
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1599: error: cannot find symbol
>>>>>>>>>>>>>>>>>               if (value instanceof KeyMap) {
>>>>>>>>>>>>>>>>>                                    ^
>>>>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1600: error: cannot find symbol
>>>>>>>>>>>>>>>>>                   km = (KeyMap) value;
>>>>>>>>>>>>>>>>>                         ^
>>>>>>>>>>>>>>>>>     symbol:   class KeyMap
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1655: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1660: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1665: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1670: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1677: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1682: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1687: error: cannot find symbol
>>>>>>>>>>>>>>>>>                           if (!(entry.value() instanceof
>>>>>>>>>>>>>>>>> NarrowingHistoryLine))
>>>>>>>>>>>>>>>>>                                      ^
>>>>>>>>>>>>>>>>>     symbol:   method value()
>>>>>>>>>>>>>>>>>     location: variable entry of type Entry
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1689: error: cannot find symbol
>>>>>>>>>>>>>>>>>                           int[] cluster =
>>>>>>>>>>>>>>>>> ((NarrowingHistoryLine)
>>>>>>>>>>>>>>>>> entry.value()).span;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>      ^
>>>>>>>>>>>>>>>>>     symbol:   method value()
>>>>>>>>>>>>>>>>>     location: variable entry of type Entry
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1691: error: cannot find symbol
>>>>>>>>>>>>>>>>>                               currentDelegate = new
>>>>>>>>>>>>>>>>> MemoryHistory();
>>>>>>>>>>>>>>>>>                                                     ^
>>>>>>>>>>>>>>>>>     symbol:   class MemoryHistory
>>>>>>>>>>>>>>>>>     location: class ConsoleIOContext.EditingHistory
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1722: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1729: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1736: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1743: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1750: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1757: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1762: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1767: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1772: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1777: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1782: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1787: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1792: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1797: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> src/tool/Repl.java:1802: error: method does not override or
>>>>>>>>>>>>>>>>> implement a
>>>>>>>>>>>>>>>>> method from a supertype
>>>>>>>>>>>>>>>>>           @Override
>>>>>>>>>>>>>>>>>           ^
>>>>>>>>>>>>>>>>> 40 errors
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sun, Apr 12, 2015 at 1:50 PM, Mani Sarkar <
>>>>>>>>>>>>>>>>> sadhak001 at gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  I'm at the LJC hackday in London and we are trying out
>>>>>>>>>>>>>>>>>> Kulla and
>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> like to know how to go about build kulla.jar from the
>>>>>>>>>>>>>>>>>> OpenjDK code
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  base, I
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  came across this link (README file)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/kulla/dev/langtools/file/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  4933dc482be7/repl/README
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  but no luck trying to build it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What should this variable point to JLINE2LIB ? Is this
>>>>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  library
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  https://github.com/jline/jline2 ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any help is appreciated.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Mani
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*
>>>>>>>>>>>>>>>>>> |  **Blog
>>>>>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate
>>>>>>>>>>>>>>>>>> & LJC
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  Advocate
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>>>>>> success
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  come
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*
>>>>>>>>>>>>>>>>> |  **Blog
>>>>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate
>>>>>>>>>>>>>>>>> & LJC
>>>>>>>>>>>>>>>>> Advocate
>>>>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>>>>> success
>>>>>>>>>>>>>>>>> will come
>>>>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>>>>>> **Blog
>>>>>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate &
>>>>>>>>>>>>>>> LJC
>>>>>>>>>>>>>>> Advocate
>>>>>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and
>>>>>>>>>>>>>>> success will
>>>>>>>>>>>>>>> come
>>>>>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |
>>>>>>>>>>> **Blog
>>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>>>>> Advocate
>>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>>
>>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>>>> will come
>>>>>>>>>>> chasing after you!*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>>>> Advocate
>>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>>
>>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>>> will come
>>>>>>>>>> chasing after you!*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>>>>> Advocate
>>>>>>>>> (@adoptopenjdk & @adoptajsr programs)
>>>>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>>>>
>>>>>>>>> *Don't chase success, rather aim for "Excellence", and success
>>>>>>>>> will come
>>>>>>>>> chasing after you!*
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>>>> Advocate (@adoptopenjdk & @adoptajsr programs)
>>>>>> *Meet-a-Project - *MutabilityDetector
>>>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>>>
>>>>>>  *Don't chase success, rather aim for "Excellence", and success will
>>>>>> come chasing after you!*
>>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>>  @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>>>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC
>>>> Advocate (@adoptopenjdk & @adoptajsr programs)
>>>> *Meet-a-Project - *MutabilityDetector
>>>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>>>> <https://bitbucket.org/neomatrix369>* * |  **Github
>>>> <https://github.com/neomatrix369>* * |  **LinkedIn
>>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>>> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>>>>
>>>>  *Don't chase success, rather aim for "Excellence", and success will
>>>> come chasing after you!*
>>>>
>>>>
>>>>
>>>
>


-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From sadhak001 at gmail.com  Sun Jun 21 19:10:36 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Sun, 21 Jun 2015 20:10:36 +0100
Subject: Fwd: How to build kulla
In-Reply-To: <CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<CAGHtMWkripHkxhD63jT__LhFacwA4PkOqXRqn3vRty+e6-L4JQ@mail.gmail.com>
	<14cae0ac278.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWn7nYSaOU8Q2tqz-HnM7z=OZLExwTeixom54HFWJ0akTg@mail.gmail.com>
	<CAP7YuASF3KNrj0oRRdsTVB6O23Ng7MXYT+uhh+mcZFm3LczfUQ@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>
	<CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>
Message-ID: <CAGHtMWkSFetqLEV+HWwVETXpZT+cCu4kqHK1Qrk=-1i7RJorYw@mail.gmail.com>

Resending due to exceeding max message size.
---------- Forwarded message ----------
From: Mani Sarkar <sadhak001 at gmail.com>
Date: Sun, Jun 21, 2015 at 8:06 PM
Subject: Re: How to build kulla
To: Martijn Verburg <martijnverburg at gmail.com>
Cc: Robert Field <robert.field at oracle.com>, kulla-dev at openjdk.java.net, "
adoption-discuss at openjdk.java.net" <adoption-discuss at openjdk.java.net>


Hi Martijn, Robert,

This is good news, I should get my head around this soon and have something
in place using your suggestions.

@Robert - we still like to extract the classes and produce a .jar file so
that others can download it from our CI servers, does the mechanism to do
that remains the same. Or are you also saying that the make clean images
creates a .jar file in the build folder alongside the images folder (JDK
and JRE).

Cheers.
Mani

On Sun, Jun 21, 2015 at 7:44 PM, Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi Robert,
>
> We should be able to help.  I'm a little out of action at present, but
> hopefully Mani sees this and will get the build up and running.
>
> Cheers,
> Martijn
>
> On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:
>
>>   Yep.
>>
>> Executed with: jshell
>>
>> -R
>>
>> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Does this mean for the kulla-dev forest I could go:
>>>
>>> hg clone <url for kulla-dev>
>>> ./get_source.sh
>>> make clean images
>>>
>>> And the REPL will be available?
>>>
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com> wrote:
>>>
>>>>  Dear Mani, Martijn,
>>>>
>>>> Thank you for this work.
>>>>
>>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>>> repo.  This version of jline has been made more platform independent (no
>>>> longer requiring the external native libraries).  JShell now uses this.
>>>>
>>>> As a result the unit of a Kulla/JShell build is now a full JDK build.
>>>> Would it be possible to do full Kulla JDK builds now?
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*



-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From robert.field at oracle.com  Sun Jun 21 20:45:37 2015
From: robert.field at oracle.com (Robert Field)
Date: Sun, 21 Jun 2015 13:45:37 -0700
Subject: Kulla: API naming question JLS vs JVM class
In-Reply-To: <55861F23.9090707@oracle.com>
References: <55861F23.9090707@oracle.com>
Message-ID: <55872271.8060801@oracle.com>

Two off lists responses --

-------------------------

I vote for: TYPE_DECL, VAR_DECL, METHOD_DECL.

-------------------------

"Type" usually references to a type not a declaration. Variable 
similarly.  And their Keys subclass off DeclarationKey. So, a _DECL 
suffix makes sense.

-------------------------

-R


On 06/20/15 19:19, Robert Field wrote:
> Keys for what is called a "class" in the JVM (that is a class, enum, 
> interface, or annotation interface in JLS speak) have Key.Kind.CLASS 
> and are instances of Key.ClassKey.
>
> This is awkward both in terms of documenting them (I'm referencing the 
> JLS) and because the SubKind values are JLS-speak:
>
>     CLASS_SUBKIND(Key.Kind.CLASS),
>     INTERFACE_SUBKIND(Key.Kind.CLASS),
>     ENUM_SUBKIND(Key.Kind.CLASS),
>     ANNOTATION_TYPE_SUBKIND(Key.Kind.CLASS),
>
> Looking at the JLS the syntax production is TypeDeclaration.  So, I 
> think the Key.Kind should be changed to TYPE.
>
> It could be changed to TYPE_DECLARATION but then we would want to also 
> change VARIABLE and METHOD to
>
>    VARIABLE_DECLARATION
>    METHOD_DECLARATION
>
> Which would make use pretty verbose.  Could be abbreviated, but the 
> API currently mostly shies away from abbreviations.
>
> So, the choices are:
>
> (1)   TYPE   TypeKey
>
> (2)   TYPE_DECLARATION   TypeDeclarationKey
>
> (3)    TYPE_DECL   TypeDeclKey
>
> (4)    CLASS   ClassKey
>
> What do you all think?
>
> Thanks,
> Robert
>


From forax at univ-mlv.fr  Sun Jun 21 23:12:01 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 22 Jun 2015 01:12:01 +0200
Subject: Kulla: API naming question JLS vs JVM class
In-Reply-To: <55872271.8060801@oracle.com>
References: <55861F23.9090707@oracle.com> <55872271.8060801@oracle.com>
Message-ID: <558744C1.7030206@univ-mlv.fr>

<bikesheding on>
We are talking about an enum value, so the name is not TYPE_DECL but 
KeyKind.TYPE_DECL,
the result is a name with a prefix component and a postfix component,
i find these kind of name hard to read.

but if KeyKind is mostly use with an import static, i'm fine with TYPE_DECL.

cheers,
R?mi

On 06/21/2015 10:45 PM, Robert Field wrote:
> Two off lists responses --
>
> -------------------------
>
> I vote for: TYPE_DECL, VAR_DECL, METHOD_DECL.
>
> -------------------------
>
> "Type" usually references to a type not a declaration. Variable 
> similarly.  And their Keys subclass off DeclarationKey. So, a _DECL 
> suffix makes sense.
>
> -------------------------
>
> -R
>
>
> On 06/20/15 19:19, Robert Field wrote:
>> Keys for what is called a "class" in the JVM (that is a class, enum, 
>> interface, or annotation interface in JLS speak) have Key.Kind.CLASS 
>> and are instances of Key.ClassKey.
>>
>> This is awkward both in terms of documenting them (I'm referencing 
>> the JLS) and because the SubKind values are JLS-speak:
>>
>>     CLASS_SUBKIND(Key.Kind.CLASS),
>>     INTERFACE_SUBKIND(Key.Kind.CLASS),
>>     ENUM_SUBKIND(Key.Kind.CLASS),
>>     ANNOTATION_TYPE_SUBKIND(Key.Kind.CLASS),
>>
>> Looking at the JLS the syntax production is TypeDeclaration. So, I 
>> think the Key.Kind should be changed to TYPE.
>>
>> It could be changed to TYPE_DECLARATION but then we would want to 
>> also change VARIABLE and METHOD to
>>
>>    VARIABLE_DECLARATION
>>    METHOD_DECLARATION
>>
>> Which would make use pretty verbose.  Could be abbreviated, but the 
>> API currently mostly shies away from abbreviations.
>>
>> So, the choices are:
>>
>> (1)   TYPE   TypeKey
>>
>> (2)   TYPE_DECLARATION   TypeDeclarationKey
>>
>> (3)    TYPE_DECL   TypeDeclKey
>>
>> (4)    CLASS   ClassKey
>>
>> What do you all think?
>>
>> Thanks,
>> Robert
>>
>


From robert.field at oracle.com  Mon Jun 22 04:05:47 2015
From: robert.field at oracle.com (Robert Field)
Date: Sun, 21 Jun 2015 21:05:47 -0700
Subject: Kulla: API naming question JLS vs JVM class
In-Reply-To: <558744C1.7030206@univ-mlv.fr>
References: <55861F23.9090707@oracle.com> <55872271.8060801@oracle.com>
	<558744C1.7030206@univ-mlv.fr>
Message-ID: <5587899B.8010503@oracle.com>


On 06/21/15 16:12, Remi Forax wrote:
> <bikesheding on>

;-)

> We are talking about an enum value, so the name is not TYPE_DECL but 
> KeyKind.TYPE_DECL,

Yes, Key.Kind.TYPE_DECL

> the result is a name with a prefix component and a postfix component,

Though one can import jdk.jshell.Key.Kind

then use Kind.TYPE_DECL

Or, import static jdk.jshell.Key.Kind.*;

and use just TYPE_DECL

> i find these kind of name hard to read.

Certainly as a whole, and names with underscores I find visually 
confusing in general.

All a matter of trade-offs.

>
> but if KeyKind is mostly use with an import static, i'm fine with 
> TYPE_DECL.

User's choice.

In the tool, which is our use-case now, it gets used exclusively in 
switch-statements, so no prefix.

-Robert

>
> cheers,
> R?mi
>
> On 06/21/2015 10:45 PM, Robert Field wrote:
>> Two off lists responses --
>>
>> -------------------------
>>
>> I vote for: TYPE_DECL, VAR_DECL, METHOD_DECL.
>>
>> -------------------------
>>
>> "Type" usually references to a type not a declaration. Variable 
>> similarly.  And their Keys subclass off DeclarationKey. So, a _DECL 
>> suffix makes sense.
>>
>> -------------------------
>>
>> -R
>>
>>
>> On 06/20/15 19:19, Robert Field wrote:
>>> Keys for what is called a "class" in the JVM (that is a class, enum, 
>>> interface, or annotation interface in JLS speak) have Key.Kind.CLASS 
>>> and are instances of Key.ClassKey.
>>>
>>> This is awkward both in terms of documenting them (I'm referencing 
>>> the JLS) and because the SubKind values are JLS-speak:
>>>
>>>     CLASS_SUBKIND(Key.Kind.CLASS),
>>>     INTERFACE_SUBKIND(Key.Kind.CLASS),
>>>     ENUM_SUBKIND(Key.Kind.CLASS),
>>>     ANNOTATION_TYPE_SUBKIND(Key.Kind.CLASS),
>>>
>>> Looking at the JLS the syntax production is TypeDeclaration. So, I 
>>> think the Key.Kind should be changed to TYPE.
>>>
>>> It could be changed to TYPE_DECLARATION but then we would want to 
>>> also change VARIABLE and METHOD to
>>>
>>>    VARIABLE_DECLARATION
>>>    METHOD_DECLARATION
>>>
>>> Which would make use pretty verbose.  Could be abbreviated, but the 
>>> API currently mostly shies away from abbreviations.
>>>
>>> So, the choices are:
>>>
>>> (1)   TYPE   TypeKey
>>>
>>> (2)   TYPE_DECLARATION   TypeDeclarationKey
>>>
>>> (3)    TYPE_DECL   TypeDeclKey
>>>
>>> (4)    CLASS   ClassKey
>>>
>>> What do you all think?
>>>
>>> Thanks,
>>> Robert
>>>
>>
>


From andrei.eremeev at oracle.com  Mon Jun 22 10:31:44 2015
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 22 Jun 2015 13:31:44 +0300
Subject: JShell/Kulla towards JDK9 and Fix Version
In-Reply-To: <5585F484.1060809@oracle.com>
References: <9b501b35-bc2f-4501-87b4-71e9f295711f@default>
	<5585F484.1060809@oracle.com>
Message-ID: <5587E410.4000401@oracle.com>

I created the tracking task and assigned it to me. BTW, what is the 
deadline of integration?

Now I see problems. What if we have a testng test with several test 
cases and one of the test cases fails. This test should be excluded, but 
the whole test won't be run, because of a minor bug. So we will lose 
some tests until the bug is not fixed. Does jtreg support exclusion of a 
test case?

Andrei Eremeev

On 06/21/2015 02:17 AM, Robert Field wrote:
>
> On 06/20/15 10:47, Andrei Eremeev wrote:
>> Noted!
>>
>> Before integrating Kulla to JDK9 all excluded tests for JShell should 
>> be cleaned up:
>> 1. Now if a test is excluded, it has "@Test(enabled = false)" 
>> annotation, so jtreg does not indicate nothing. Instead of using the 
>> annotation, "@ignore" jtreg tag should be used. In this case, we 
>> won't miss that a test will never be run.
>> 2. Each of the excluded tests should have an open bug in JBS. The bug 
>> id should be written in "@ignore" tag.
>
> Sounds good.  Are you signed up for that task?  Would you like a bug 
> assigned to you for it?
>
> Thanks,
> Robert
>
>>
>> Andrei Eremeev
>>
>> ----- Original Message -----
>> From: robert.field at oracle.com
>> To: kulla-dev at openjdk.java.net
>> Sent: Saturday, June 20, 2015 4:12:14 AM GMT +03:00 Iraq
>> Subject: JShell/Kulla towards JDK9 and Fix Version
>>
>> We believe the core work of JShell is done, that the functionality is
>> there and fairly stable, and yes sure there are bugs to fix, but they
>> are not too glaring.  What that means is it is time to work towards
>> moving JShell into the JDK9 main-line repo!
>>
>> This also has an effect on what Fix Version we use.  Work that we need
>> to do before it goes into JDK9 (e.g., API docs clean-up) or, because of
>> timing, we know will go into the Kulla repo should continue to use the
>> 9-repo-kulla Fix Version.  Everything else, including almost all bug
>> reports, should have Fix Version: 9.
>>
>> -Robert
>>
>


From andrei.eremeev at oracle.com  Mon Jun 22 10:34:39 2015
From: andrei.eremeev at oracle.com (andrei.eremeev at oracle.com)
Date: Mon, 22 Jun 2015 10:34:39 +0000
Subject: hg: kulla/dev/langtools: 8129412: JShell tests: add synchronization
	to StopExecutionTest
Message-ID: <201506221034.t5MAYdwe025550@aojmv0008.oracle.com>

Changeset: 6b3b06d23974
Author:    aeremeev
Date:      2015-06-22 13:33 +0300
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/6b3b06d23974

8129412: JShell tests: add synchronization to StopExecutionTest

! test/jdk/jshell/StopExecutionTest.java


From andrei.eremeev at oracle.com  Mon Jun 22 14:13:49 2015
From: andrei.eremeev at oracle.com (andrei.eremeev at oracle.com)
Date: Mon, 22 Jun 2015 14:13:49 +0000
Subject: hg: kulla/dev/langtools: 8129435: JShell tests: add bug id to
	excluded tests
Message-ID: <201506221413.t5MEDn79004709@aojmv0008.oracle.com>

Changeset: aa2e02c3ecad
Author:    aeremeev
Date:      2015-06-22 17:13 +0300
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/aa2e02c3ecad

8129435: JShell tests: add bug id to excluded tests

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! test/jdk/jshell/ClassMembersTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/EditorTest.java
! test/jdk/jshell/EditorTestBase.java
! test/jdk/jshell/ErrorTranslationTest.java
! test/jdk/jshell/ExceptionsTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/ImportTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/StartOptionTest.java
! test/jdk/jshell/StopExecutionTest.java


From andrei.eremeev at oracle.com  Mon Jun 22 14:19:22 2015
From: andrei.eremeev at oracle.com (andrei.eremeev at oracle.com)
Date: Mon, 22 Jun 2015 14:19:22 +0000
Subject: hg: kulla/dev/langtools: Revert changes in JShell tool.
Message-ID: <201506221419.t5MEJMRP006194@aojmv0008.oracle.com>

Changeset: e59fe8aaaa58
Author:    aeremeev
Date:      2015-06-22 17:18 +0300
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/e59fe8aaaa58

Revert changes in JShell tool.

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java


From andrei.eremeev at oracle.com  Mon Jun 22 14:34:48 2015
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 22 Jun 2015 17:34:48 +0300
Subject: JShell/Kulla towards JDK9 and Fix Version
In-Reply-To: <5585F484.1060809@oracle.com>
References: <9b501b35-bc2f-4501-87b4-71e9f295711f@default>
	<5585F484.1060809@oracle.com>
Message-ID: <55881D08.608@oracle.com>

Did the second point of the task: filed bugs and added comments.
Now all excluded tests conform the following style: @Test(enabled = 
false) // TODO 8081689

Andrei

On 06/21/2015 02:17 AM, Robert Field wrote:
>
> On 06/20/15 10:47, Andrei Eremeev wrote:
>> Noted!
>>
>> Before integrating Kulla to JDK9 all excluded tests for JShell should 
>> be cleaned up:
>> 1. Now if a test is excluded, it has "@Test(enabled = false)" 
>> annotation, so jtreg does not indicate nothing. Instead of using the 
>> annotation, "@ignore" jtreg tag should be used. In this case, we 
>> won't miss that a test will never be run.
>> 2. Each of the excluded tests should have an open bug in JBS. The bug 
>> id should be written in "@ignore" tag.
>
> Sounds good.  Are you signed up for that task?  Would you like a bug 
> assigned to you for it?
>
> Thanks,
> Robert
>
>>
>> Andrei Eremeev
>>
>> ----- Original Message -----
>> From: robert.field at oracle.com
>> To: kulla-dev at openjdk.java.net
>> Sent: Saturday, June 20, 2015 4:12:14 AM GMT +03:00 Iraq
>> Subject: JShell/Kulla towards JDK9 and Fix Version
>>
>> We believe the core work of JShell is done, that the functionality is
>> there and fairly stable, and yes sure there are bugs to fix, but they
>> are not too glaring.  What that means is it is time to work towards
>> moving JShell into the JDK9 main-line repo!
>>
>> This also has an effect on what Fix Version we use.  Work that we need
>> to do before it goes into JDK9 (e.g., API docs clean-up) or, because of
>> timing, we know will go into the Kulla repo should continue to use the
>> 9-repo-kulla Fix Version.  Everything else, including almost all bug
>> reports, should have Fix Version: 9.
>>
>> -Robert
>>
>


From andrei.eremeev at oracle.com  Mon Jun 22 14:37:20 2015
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 22 Jun 2015 17:37:20 +0300
Subject: Bugs
Message-ID: <55881DA0.9060601@oracle.com>

Hi REPL team,

new issues in REPL  (some of them were reported via e-mail, not via JBS):
https://bugs.openjdk.java.net/browse/JDK-8129418
https://bugs.openjdk.java.net/browse/JDK-8129420
https://bugs.openjdk.java.net/browse/JDK-8129421
https://bugs.openjdk.java.net/browse/JDK-8129422
https://bugs.openjdk.java.net/browse/JDK-8129427

Andrei Eremeev

From brian.goetz at oracle.com  Mon Jun 22 20:28:55 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 22 Jun 2015 16:28:55 -0400
Subject: Kulla API changes: shifting to events
In-Reply-To: <55787D9C.5080300@oracle.com>
References: <55677A59.8010909@oracle.com> <55677AC0.1060202@oracle.com>
	<55679678.60303@oracle.com> <55787D9C.5080300@oracle.com>
Message-ID: <55887007.8020407@oracle.com>

I'm looking at the API as it now stands; I realize there are still 
probably some changes in the pipe, so consider this a "checkpoint" review.

The event structure you outline in the message below seems reasonable to 
me.

Some additional Qs and comments:

1.  I see you left SourceCodeAnalysis as a separate, but dependent, 
abstraction.  I can imagine several reasons:

  - Just not finished refactoring yet, to pull up SCA methods into JShell;
  - You wanted to leave them on SCA, because that sent a valuable 
"grouping" method to the reader of the code;
  - You have decided that SCA is an optional part of the API (if so, 
spec should say), so you want to leave room for sourceCodeAnalysis() to 
return null / throw UOE, and having one branch-point for this is better 
than N.

Related style nit: in SourceCodeAnalysis, the 'static' on nested enums 
and the 'public' on nested classes of interfaces are redundant.  Also, 
the triple-nesting of SCA.CompletionInfo.Completeness seems excessive; 
I'd pull Completness up into SCA.

2.  I see you return a List<Event> from eval.  Is this where you landed, 
or a waypoint?  Am I to assume that the List<Event> returned from 
evaluation is a convenience copy of events also delivered to listeners?

If so, this seems a pragmatic compromise; a client that goes whole-hog 
on events can ignore the returned list, and a client who really just 
wants to know "what happened when I eval'ed" can process the lists and 
ignore the events.  And a client that wants both can even use the 
identity of events to track "I already processed this guy", and avoid 
duplicate-processing, say with a WeakHashSet.  (Right?)

3.  I would rename 'stop' to 'tryCancel()'.  You've already got a 
close() method (courtesy of AutoCloseable); the value-add of `stop()` is 
that it TRIES to CANCEL any outstanding evaluation.  Which means that 
the correct shutdown idiom would be:

    repl.tryCancel()
    repl.close()

However, cancellation is a tricky beast (See JCiP Ch7.)  I would 
consider returning either:
  - boolean indicating that the cancellation succeeded or failed
  - a Future on which the client can wait (perhaps with a timed wait) 
for cancelation to complete (if its possible to detect when it does.)

I believe the latter is practical if you wrap the eval() implementation 
with a semaphore.  In which case the shutdown protocol becomes:

     Future f = repl.tryCancel();
     f.timedWait(reasonableAmountOfTime);
     repl.close();

Also, you've explicitly introduced concurrency into the API, so you just 
bought yourself a call option on a bag of data race bugs...so let's put 
that on the code-review list.

Now that you have ONE method that is explicitly safe to call from other 
threads, you have to raise your spec game about what operations are or 
are not safe to call from multiple threads.  Lazy approach: declare 
that, with the exception of the tryCancel method, the JShell API is 
*not* designed to be thread-safe, and that the caller should arrange for 
all method invocations (including invocations in response to event 
delivery, whose thread context are not guaranteed) should be done in a 
fixed thread.  (We can talk about ways to enforce this if you want to go 
even further with this.)  Less lazy, but harder, approach: try to make 
some subset of JShell thread-safe.

Can close() be called from another thread?  If so, does it implicitly 
call tryCancel()?  If not, spec of close() should guide reader towards 
considering tryCancel in this case.

4.  I don't see any way to *remove* things from the class path.  Nor a 
way to inspect the contents of the class path.

5.  Do you wrap all returned lists/maps with unmodifiable?

6.  Doc for subKind leaves me wondering what subKind is and why I should 
be interested.

7.  Naming convention: for the key-accepting methods, consider 
xxxFor(key)?  diagnosticsFor(key), signatureFor(key), etc.

8.  onStateShutdown -> onShutdown.

9.  Should JShell be an interface or an abstract class?  Both have pros 
and cons.  Interface is cleaner, but has a higher spec burden.  Abstract 
class ties you into being the only implementor of JShell, but allows you 
more control.

10.  I don't think onShutdown needs to be passed the JShell instance. 
(1) Simple clients have only one JShell instance, and (2) more complex 
clients can capture the JShell instance:

     jShell.onShutdown(() -> {
         shellRegistry.remove(jShell); <-- ordinary lambda capture
     });

So I would have this method just take Runnable.

Spec for all onXxx methods must say that the caller should not count on 
the event being delivered in any specific thread context, and if the 
handler intends to invoke any jShell methods, it is the handlers job to 
enqueue them for processing on the thread to which JShell is confined.

11.  EvalException has a Javadoc ref to nonexistent method Class.asName.

12.  Key.beforeStatus -> previousStatus.

For Key.causeKey, you should distinguish between "proximate cause" and 
"ultimate cause", and make it clear which you mean.  For example:

repl> void a() { b(); }  // no b yet, so a is not yet valid
repl> void b() { c(); }  // no c yet, a and b not yet valid
repl> void c() { } // yay, everyone valid!

When you get a transition event for a, is the cause key bKey or cKey?  I 
would *think* that the answer is cKey for two reasons:

1.  Seems more useful, to associate transitions with the root cause;
2.  It avoids ambiguities, as in this case:

repl> void a() { b(); c(); }
repl> void b() { d(); }
repl> void c() { d(); }
repl> void d() { }

The "proximate cause" strategy would cause the causeKey for validating a 
to randomly be bKey or cKey, but the "root cause" strategy would make it 
stably dKey, which seems preferable.  We should (a) pick one, (b) pick 
the right one, and (c) spec which one we picked.

13.  Feels that it would be more consistent with the rest of the API for 
SubKind to be a nested type of Key, sibling to Key.Kind.

On 6/10/2015 2:10 PM, Robert Field wrote:
> As I'm working on implementing this, I've run into a place where the
> prettiness of the API makes for big pain for the API consumer -- in my
> case the jshell tool.  The Result structure, tentacled as it is, tied
> together information which needs to be processed together. Having
> separate key status events, value events, and exception events would
> require collecting all the events and cross linking them to get the kind
> of information  we can present now.  It is also kind of a lie, one only
> sees values through events at the point of status changes,
>
> Value and exception data only occur paired to status change points. If,
> instead of being separate events, the value/exception information is
> included in the event now named KeyStatusEvent then the information
> would be tied nicely -- even though this means the event is a bit
> bulky.  So, with this, the fields of the event would be:
>
>      /**
>       * Key which has changed
>       */
>      public final Key key;
>
>      /**
>       * The status before the transition.
>       */
>      public final Status beforeStatus;
>
>      /**
>       * The after status. Note: this may be the same as the before status.
>       */
>      public final Status status;
>
>      /**
>       * Has the signature changed?
>       */
>      public final boolean isSignatureChange;
>
>      /**
>       * Either the key whose change caused the this update.  If null, this
>       * change was caused by new eval() source for the key.
>       */
>      public final Key causeKey;
>
>      /**
>       * Exception thrown while running, or null.
>       */
>      public final Exception exception;
>
>      /**
>       * The result value of successful run. The value is null if not
> executed
>       * or an exception was thrown.  The value is the empty string if
> statement
>       * or void valued expression executed.
>       */
>      public final String value;
>
>
> Yes?
>
> -Robert
>
>
> On 05/28/15 15:28, Robert Field wrote:
>>
>> On 05/28/15 13:29, Brian Goetz wrote:
>>> Sounds good!  Can you post an API draft of what you're thinking?
>>
>> The event structure is already pushed --
>>
>>     public class StatusTransitionEvent {
>>         public StatusTransitionEvent(Key key, Status beforeStatus,
>>     Status status,
>>                 boolean isSignatureChange, Key causeKey) {
>>             this.key = key;
>>             this.beforeStatus = beforeStatus;
>>             this.status = status;
>>             this.isSignatureChange = isSignatureChange;
>>             this.causeKey = causeKey;
>>         }
>>
>>         /**
>>          * Key which has changed
>>          */
>>         public final Key key;
>>
>>         /**
>>          * The status before the transition.
>>          */
>>         public final Status beforeStatus;
>>
>>         /**
>>          * The after status. Note: this may be the same as the before
>>     status.
>>          */
>>         public final Status status;
>>
>>         /**
>>          * Has the signature changed?
>>          */
>>         public final boolean isSignatureChange;
>>
>>         /**
>>          * Either the key whose change caused the this update.  If
>>     null, this
>>          * change was caused by new eval() source for the key.
>>          */
>>         public final Key causeKey;
>>     }
>>
>> It will have event registration and at least initially and probably
>> permanently a List of events would be returned by eval() -- presumably
>> with value/exception -- and by drop().
>>
>> Thoughts?
>>
>> -Robert
>>
>>>
>>>
>>>
>>> On 5/28/2015 4:28 PM, Robert Field wrote:
>>>> With keys generated for RejectedFailed and the addition of Dropped and
>>>> particularly Overwritten Status, Outcome wasn't really making any sense
>>>> any more.  There has been a desire to move in the direction of events.
>>>> The two go well together.  I've introduced StatusTransitionEvent, and
>>>> plan to shift to it.
>>>>
>>>> As soon as I can get the tests converted, I will be using
>>>> StatusTransitionEvent as the event model for update.  I will leave the
>>>> existing enum Outcome and Result.updates in place until we can convert
>>>> everything, but please consider them deprecated.
>>>>
>>>> Please let me know any concerns, questions, ...
>>>>
>>>> -Robert
>>>>
>>
>

From jonathan.gibbons at oracle.com  Mon Jun 22 20:49:42 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 22 Jun 2015 13:49:42 -0700
Subject: Kulla API changes: shifting to events
In-Reply-To: <556C83ED.9020804@oracle.com>
References: <55677A59.8010909@oracle.com>
	<55677AC0.1060202@oracle.com>	<55679678.60303@oracle.com>
	<556C8104.6040800@oracle.com> <556C83ED.9020804@oracle.com>
Message-ID: <558874E6.1050702@oracle.com>


On 06/01/2015 09:10 AM, Robert Field wrote:
> I keep trying to steer away from complexity.  For our needs unicast is 
> enough, actually better since it is simpler.
> Would it be a reasonably approach to provide unicast and for those 
> that need it they can add their own multiplexing on top?
>
> Another perspective is that, for our current tool/testing needs, there 
> is no need to unsubscribe, so never dealing with tokens, letting them 
> fall on the ground, is fine.
>
> -Robert

Not being able to unsubscribe sounds somewhat shortsighted.

-- Jon

From brian.goetz at oracle.com  Mon Jun 22 20:51:14 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 22 Jun 2015 16:51:14 -0400
Subject: Kulla API changes: shifting to events
In-Reply-To: <558874E6.1050702@oracle.com>
References: <55677A59.8010909@oracle.com>	<55677AC0.1060202@oracle.com>	<55679678.60303@oracle.com>	<556C8104.6040800@oracle.com>
	<556C83ED.9020804@oracle.com> <558874E6.1050702@oracle.com>
Message-ID: <55887542.6020402@oracle.com>

> Not being able to unsubscribe sounds somewhat shortsighted.
>
> -- Jon

Yes, already corrected in the current API.  The onXxx methods return 
tokens that are valid for unsubscription.

From brian.goetz at oracle.com  Mon Jun 22 21:40:08 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 22 Jun 2015 17:40:08 -0400
Subject: Default kulla messages
Message-ID: <558880B8.9080501@oracle.com>

The messages produced by JShell during the course of 
evaluation/declaration have been in a placeholder state for a while, and 
its probably time to paint the bikeshed of what the default messages 
should look like (there are multiple message schemes, which can crank up 
and down the verbosity, but the default set is the most important.)

Here's what JShell prints now for an expression and a method declaration:

-> 1 + 1
|  Expression value is: 2
|    assigned to temporary variable $1 of type int

-> void foo() { }
|  Added method foo()

These are all useful bits of information:
  - the result of the expression, if any
  - side-effects on the REPL state
    - temporary name and type, for expressions
    - var/method/class name and type, for declarations

However, plenty of people have commented that these messages are "kind 
of verbose".

The Scala REPL output contains all this information too, but more compactly:

scala> 1 + 1
res1: Int = 2

scala> def m() { }
m: ()Unit

The Ruby IRB output is more taciturn:

irb(main):001:0> 1 + 1
=> 2
irb(main):002:0> def m()
irb(main):003:1>     puts "Hello"
irb(main):004:1> end
=> nil

The Perl re.pl even more so:

$ 1 + 1
2
$ sub m {
 >     return 1;
 > }
(empty line)
 >


While we could gather more examples, I think there's a pattern emerging: 
expression evaluation should put the result front-and-center.

Here are some possible options for the evaluation of 1+1 in jshell:

--
2 (assigned to temporary $1)
--
2 (assigned to temporary $1 : int)
--
$1 (int): 2
--
=> 2
(assigned to temporary $1 : int)
--
int: 2
(assigned to temporary $1 of type int)

There are obviously many more variations.

I propose using, as the default level:

=> expression value

to indicate the result of an expression, with statements producing no 
output, coupled with a convention to put all side-effect-on-REPL-state 
information in parentheses on its own line:

repl> 1 + 1
=> 2
(assigned to temporary $1 of type int)

repl> void m() { }
(defined method m())

repl> /drop m
(dropped method m())

repl> int x = 3
(declared variable x of type int)

repl> x = 4
(no output)


I think this scheme captures the essential information without too much 
noise (users can select a higher verbosity level if they want.)


From robert.field at oracle.com  Tue Jun 23 04:24:57 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 22 Jun 2015 21:24:57 -0700
Subject: Kulla API changes: shifting to events
In-Reply-To: <558874E6.1050702@oracle.com>
References: <55677A59.8010909@oracle.com> <55677AC0.1060202@oracle.com>
	<55679678.60303@oracle.com> <556C8104.6040800@oracle.com>
	<556C83ED.9020804@oracle.com> <558874E6.1050702@oracle.com>
Message-ID: <14e1ea94e68.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Sorry for the confusion. One could always unsubscribe, just with the 
initial unicast implementation you just passed it null to unsubscribe. But 
now it is multicast and it uses the token approach to unsubscribe that 
Brian suggested.

Thanks,
Robert



On June 22, 2015 1:50:30 PM Jonathan Gibbons <jonathan.gibbons at oracle.com> 
wrote:

>
> On 06/01/2015 09:10 AM, Robert Field wrote:
> > I keep trying to steer away from complexity.  For our needs unicast is
> > enough, actually better since it is simpler.
> > Would it be a reasonably approach to provide unicast and for those
> > that need it they can add their own multiplexing on top?
> >
> > Another perspective is that, for our current tool/testing needs, there
> > is no need to unsubscribe, so never dealing with tokens, letting them
> > fall on the ground, is fine.
> >
> > -Robert
>
> Not being able to unsubscribe sounds somewhat shortsighted.
>
> -- Jon



From robert.field at oracle.com  Tue Jun 23 06:53:35 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 23 Jun 2015 06:53:35 +0000
Subject: hg: kulla/dev/langtools: Changes per API review comments,
	see reply 22/06/2015 22:56PST
Message-ID: <201506230653.t5N6rZwo026412@aojmv0008.oracle.com>

Changeset: 57f20b613318
Author:    rfield
Date:      2015-06-22 23:53 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/57f20b613318

Changes per API review comments, see reply 22/06/2015 22:56PST

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/CompletenessAnalyzer.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/EvalException.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/KeyStatusEvent.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
! test/jdk/jshell/CompletenessStressTest.java
! test/jdk/jshell/CompletenessTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/ShutdownTest.java


From martijnverburg at gmail.com  Tue Jun 23 10:26:27 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 23 Jun 2015 11:26:27 +0100
Subject: Default kulla messages
In-Reply-To: <558880B8.9080501@oracle.com>
References: <558880B8.9080501@oracle.com>
Message-ID: <CAP7YuAT1MagpRqYQVo25U=U2yfqe7uZWXXhM=0RygfygbTPn7g@mail.gmail.com>

Hi Brian,

Anecdotally from our Hackday, many developers quite liked the default
verboseness but did express an interest in being able to reduce it once
they'd gotten used to the REPL.  Just one data point mind you.

Cheers,
Martijn

On 22 June 2015 at 22:40, Brian Goetz <brian.goetz at oracle.com> wrote:

> The messages produced by JShell during the course of
> evaluation/declaration have been in a placeholder state for a while, and
> its probably time to paint the bikeshed of what the default messages should
> look like (there are multiple message schemes, which can crank up and down
> the verbosity, but the default set is the most important.)
>
> Here's what JShell prints now for an expression and a method declaration:
>
> -> 1 + 1
> |  Expression value is: 2
> |    assigned to temporary variable $1 of type int
>
> -> void foo() { }
> |  Added method foo()
>
> These are all useful bits of information:
>  - the result of the expression, if any
>  - side-effects on the REPL state
>    - temporary name and type, for expressions
>    - var/method/class name and type, for declarations
>
> However, plenty of people have commented that these messages are "kind of
> verbose".
>
> The Scala REPL output contains all this information too, but more
> compactly:
>
> scala> 1 + 1
> res1: Int = 2
>
> scala> def m() { }
> m: ()Unit
>
> The Ruby IRB output is more taciturn:
>
> irb(main):001:0> 1 + 1
> => 2
> irb(main):002:0> def m()
> irb(main):003:1>     puts "Hello"
> irb(main):004:1> end
> => nil
>
> The Perl re.pl even more so:
>
> $ 1 + 1
> 2
> $ sub m {
> >     return 1;
> > }
> (empty line)
> >
>
>
> While we could gather more examples, I think there's a pattern emerging:
> expression evaluation should put the result front-and-center.
>
> Here are some possible options for the evaluation of 1+1 in jshell:
>
> --
> 2 (assigned to temporary $1)
> --
> 2 (assigned to temporary $1 : int)
> --
> $1 (int): 2
> --
> => 2
> (assigned to temporary $1 : int)
> --
> int: 2
> (assigned to temporary $1 of type int)
>
> There are obviously many more variations.
>
> I propose using, as the default level:
>
> => expression value
>
> to indicate the result of an expression, with statements producing no
> output, coupled with a convention to put all side-effect-on-REPL-state
> information in parentheses on its own line:
>
> repl> 1 + 1
> => 2
> (assigned to temporary $1 of type int)
>
> repl> void m() { }
> (defined method m())
>
> repl> /drop m
> (dropped method m())
>
> repl> int x = 3
> (declared variable x of type int)
>
> repl> x = 4
> (no output)
>
>
> I think this scheme captures the essential information without too much
> noise (users can select a higher verbosity level if they want.)
>
>

From roy.van.rijn at gmail.com  Tue Jun 23 15:27:15 2015
From: roy.van.rijn at gmail.com (Roy van Rijn)
Date: Tue, 23 Jun 2015 17:27:15 +0200
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
Message-ID: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>

Tomorrow I've offered to do some live coding at a conference and show the
new REPL.
But when I did a clean install this afternoon as a test I suddenly got a
REPL that didn't work. So panic is starting to come in...!

This is what I now get:

roy:repl royvanrijn$ ./scripts/run.sh
|  Unexpected exception reading start-up: java.lang.NullPointerException

|  Welcome to JShell -- Version 0.610
|  Type /help for help

-> System.out.println("Test");
Exception in thread "main" java.lang.NullPointerException
at jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79)
at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
at jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)

Any ideas on how I can fix this? I've looked at the recent checkins in hg,
but couldn't find anything related....?

From robert.field at oracle.com  Tue Jun 23 15:33:40 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 23 Jun 2015 08:33:40 -0700
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
In-Reply-To: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>
References: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>
Message-ID: <14e210da820.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Will look now!




On June 23, 2015 8:27:54 AM Roy van Rijn <roy.van.rijn at gmail.com> wrote:

> Tomorrow I've offered to do some live coding at a conference and show the
> new REPL.
> But when I did a clean install this afternoon as a test I suddenly got a
> REPL that didn't work. So panic is starting to come in...!
>
> This is what I now get:
>
> roy:repl royvanrijn$ ./scripts/run.sh
> |  Unexpected exception reading start-up: java.lang.NullPointerException
>
> |  Welcome to JShell -- Version 0.610
> |  Type /help for help
>
> -> System.out.println("Test");
> Exception in thread "main" java.lang.NullPointerException
> at jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79)
> at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
> at jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)
>
> Any ideas on how I can fix this? I've looked at the recent checkins in hg,
> but couldn't find anything related....?



From robert.field at oracle.com  Tue Jun 23 15:44:54 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 23 Jun 2015 08:44:54 -0700
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
In-Reply-To: <14e210da820.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>
	<14e210da820.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <55897EF6.4070309@oracle.com>

I can't reproduce.  I will keep looking.

Just to be clear, is this what you did for clean install?

hg clone  http://hg.openjdk.java.net/kulla/dev; cd dev; bash ./get_source.sh
bash ./configure
make images

???
If so, can you try running with "jshell" command instead of script?

-Robert


On 06/23/15 08:33, Robert Field wrote:
> Will look now!
>
>
>
>
> On June 23, 2015 8:27:54 AM Roy van Rijn <roy.van.rijn at gmail.com> wrote:
>
>> Tomorrow I've offered to do some live coding at a conference and show 
>> the
>> new REPL.
>> But when I did a clean install this afternoon as a test I suddenly got a
>> REPL that didn't work. So panic is starting to come in...!
>>
>> This is what I now get:
>>
>> roy:repl royvanrijn$ ./scripts/run.sh
>> |  Unexpected exception reading start-up: java.lang.NullPointerException
>>
>> |  Welcome to JShell -- Version 0.610
>> |  Type /help for help
>>
>> -> System.out.println("Test");
>> Exception in thread "main" java.lang.NullPointerException
>> at 
>> jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79)
>> at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
>> at jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
>> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)
>>
>> Any ideas on how I can fix this? I've looked at the recent checkins 
>> in hg,
>> but couldn't find anything related....?
>
>


From brian.goetz at oracle.com  Tue Jun 23 15:58:07 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 23 Jun 2015 11:58:07 -0400
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
In-Reply-To: <55897EF6.4070309@oracle.com>
References: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>	<14e210da820.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<55897EF6.4070309@oracle.com>
Message-ID: <5589820F.10807@oracle.com>

I've seen a similar behavior on Mac -- when my network settings are 
borked up due to running a VPN client.  Something keeps the JDI 
connection from being made, and then it falls into an NPE later in the 
program after something times out and returns null.

On 6/23/2015 11:44 AM, Robert Field wrote:
> I can't reproduce.  I will keep looking.
>
> Just to be clear, is this what you did for clean install?
>
> hg clone  http://hg.openjdk.java.net/kulla/dev; cd dev; bash
> ./get_source.sh
> bash ./configure
> make images
>
> ???
> If so, can you try running with "jshell" command instead of script?
>
> -Robert
>
>
> On 06/23/15 08:33, Robert Field wrote:
>> Will look now!
>>
>>
>>
>>
>> On June 23, 2015 8:27:54 AM Roy van Rijn <roy.van.rijn at gmail.com> wrote:
>>
>>> Tomorrow I've offered to do some live coding at a conference and show
>>> the
>>> new REPL.
>>> But when I did a clean install this afternoon as a test I suddenly got a
>>> REPL that didn't work. So panic is starting to come in...!
>>>
>>> This is what I now get:
>>>
>>> roy:repl royvanrijn$ ./scripts/run.sh
>>> |  Unexpected exception reading start-up: java.lang.NullPointerException
>>>
>>> |  Welcome to JShell -- Version 0.610
>>> |  Type /help for help
>>>
>>> -> System.out.println("Test");
>>> Exception in thread "main" java.lang.NullPointerException
>>> at
>>> jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79)
>>> at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
>>> at jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
>>> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)
>>>
>>> Any ideas on how I can fix this? I've looked at the recent checkins
>>> in hg,
>>> but couldn't find anything related....?
>>
>>
>

From robert.field at oracle.com  Tue Jun 23 16:05:18 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 23 Jun 2015 09:05:18 -0700
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
In-Reply-To: <5589820F.10807@oracle.com>
References: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>	<14e210da820.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<55897EF6.4070309@oracle.com> <5589820F.10807@oracle.com>
Message-ID: <558983BE.8060900@oracle.com>

Yep, from the failure it looks likely to be related to socket or memory 
issues, so I asked him to try a reboot while I dive deeper.

What is null is the output stream that gets set during opening the 
socket.  But if that fails it should throw an internal error and die, 
looking...

-Robert

On 06/23/15 08:58, Brian Goetz wrote:
> I've seen a similar behavior on Mac -- when my network settings are 
> borked up due to running a VPN client.  Something keeps the JDI 
> connection from being made, and then it falls into an NPE later in the 
> program after something times out and returns null.
>
> On 6/23/2015 11:44 AM, Robert Field wrote:
>> I can't reproduce.  I will keep looking.
>>
>> Just to be clear, is this what you did for clean install?
>>
>> hg clone  http://hg.openjdk.java.net/kulla/dev; cd dev; bash
>> ./get_source.sh
>> bash ./configure
>> make images
>>
>> ???
>> If so, can you try running with "jshell" command instead of script?
>>
>> -Robert
>>
>>
>> On 06/23/15 08:33, Robert Field wrote:
>>> Will look now!
>>>
>>>
>>>
>>>
>>> On June 23, 2015 8:27:54 AM Roy van Rijn <roy.van.rijn at gmail.com> 
>>> wrote:
>>>
>>>> Tomorrow I've offered to do some live coding at a conference and show
>>>> the
>>>> new REPL.
>>>> But when I did a clean install this afternoon as a test I suddenly 
>>>> got a
>>>> REPL that didn't work. So panic is starting to come in...!
>>>>
>>>> This is what I now get:
>>>>
>>>> roy:repl royvanrijn$ ./scripts/run.sh
>>>> |  Unexpected exception reading start-up: 
>>>> java.lang.NullPointerException
>>>>
>>>> |  Welcome to JShell -- Version 0.610
>>>> |  Type /help for help
>>>>
>>>> -> System.out.println("Test");
>>>> Exception in thread "main" java.lang.NullPointerException
>>>> at
>>>> jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79) 
>>>>
>>>> at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
>>>> at jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
>>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
>>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
>>>> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)
>>>>
>>>> Any ideas on how I can fix this? I've looked at the recent checkins
>>>> in hg,
>>>> but couldn't find anything related....?
>>>
>>>
>>


From robert.field at oracle.com  Tue Jun 23 16:16:29 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 23 Jun 2015 09:16:29 -0700
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
In-Reply-To: <558983BE.8060900@oracle.com>
References: <CAMJwwmvPG=dTMD_RSviAkWu8dhp35HtzV6v2MX+M8VgOWVPBGQ@mail.gmail.com>	<14e210da820.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<55897EF6.4070309@oracle.com> <5589820F.10807@oracle.com>
	<558983BE.8060900@oracle.com>
Message-ID: <5589865D.3090900@oracle.com>

Ah!

I believe it is trying to die with an internal error (because it could 
not create the socket) and is hitting the NPE on the way.

-Robert

On 06/23/15 09:05, Robert Field wrote:
> Yep, from the failure it looks likely to be related to socket or 
> memory issues, so I asked him to try a reboot while I dive deeper.
>
> What is null is the output stream that gets set during opening the 
> socket.  But if that fails it should throw an internal error and die, 
> looking...
>
> -Robert
>
> On 06/23/15 08:58, Brian Goetz wrote:
>> I've seen a similar behavior on Mac -- when my network settings are 
>> borked up due to running a VPN client.  Something keeps the JDI 
>> connection from being made, and then it falls into an NPE later in 
>> the program after something times out and returns null.
>>
>> On 6/23/2015 11:44 AM, Robert Field wrote:
>>> I can't reproduce.  I will keep looking.
>>>
>>> Just to be clear, is this what you did for clean install?
>>>
>>> hg clone  http://hg.openjdk.java.net/kulla/dev; cd dev; bash
>>> ./get_source.sh
>>> bash ./configure
>>> make images
>>>
>>> ???
>>> If so, can you try running with "jshell" command instead of script?
>>>
>>> -Robert
>>>
>>>
>>> On 06/23/15 08:33, Robert Field wrote:
>>>> Will look now!
>>>>
>>>>
>>>>
>>>>
>>>> On June 23, 2015 8:27:54 AM Roy van Rijn <roy.van.rijn at gmail.com> 
>>>> wrote:
>>>>
>>>>> Tomorrow I've offered to do some live coding at a conference and show
>>>>> the
>>>>> new REPL.
>>>>> But when I did a clean install this afternoon as a test I suddenly 
>>>>> got a
>>>>> REPL that didn't work. So panic is starting to come in...!
>>>>>
>>>>> This is what I now get:
>>>>>
>>>>> roy:repl royvanrijn$ ./scripts/run.sh
>>>>> |  Unexpected exception reading start-up: 
>>>>> java.lang.NullPointerException
>>>>>
>>>>> |  Welcome to JShell -- Version 0.610
>>>>> |  Type /help for help
>>>>>
>>>>> -> System.out.println("Test");
>>>>> Exception in thread "main" java.lang.NullPointerException
>>>>> at
>>>>> jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79) 
>>>>>
>>>>> at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
>>>>> at 
>>>>> jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
>>>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
>>>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
>>>>> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)
>>>>>
>>>>> Any ideas on how I can fix this? I've looked at the recent checkins
>>>>> in hg,
>>>>> but couldn't find anything related....?
>>>>
>>>>
>>>
>


From robert.field at oracle.com  Tue Jun 23 18:46:27 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 23 Jun 2015 18:46:27 +0000
Subject: hg: kulla/dev/langtools: Reenable debugging support. Exit gracefully
	(no NPEs) on JDI start-up failure.
Message-ID: <201506231846.t5NIkRUH010587@aojmv0008.oracle.com>

Changeset: cc9ad7d35093
Author:    rfield
Date:      2015-06-23 11:46 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/cc9ad7d35093

Reenable debugging support.  Exit gracefully (no NPEs) on JDI start-up failure.

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JDIExecution.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellFactory.java
! test/jdk/jshell/StopExecutionTest.java


From robert.field at oracle.com  Tue Jun 23 20:29:18 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 23 Jun 2015 20:29:18 +0000
Subject: hg: kulla/dev/langtools: fail fast on JDI start-up failure
Message-ID: <201506232029.t5NKTIGZ000901@aojmv0008.oracle.com>

Changeset: ae2548e72e2b
Author:    rfield
Date:      2015-06-23 13:29 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/ae2548e72e2b

fail fast on JDI start-up failure

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/VMConnection.java
! test/jdk/jshell/StopExecutionTest.java


From robert.field at oracle.com  Tue Jun 23 20:43:45 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 23 Jun 2015 20:43:45 +0000
Subject: hg: kulla/dev/langtools: Streamification
Message-ID: <201506232043.t5NKhjRG003340@aojmv0008.oracle.com>

Changeset: 06f3585a609b
Author:    rfield
Date:      2015-06-23 13:43 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/06f3585a609b

Streamification
Contributed-by: brian.goetz at oracle.com

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyMap.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/MaskCommentsAndModifiers.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetMaps.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/TaskFactory.java


From sadhak001 at gmail.com  Tue Jun 23 20:57:41 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Tue, 23 Jun 2015 21:57:41 +0100
Subject: How to build kulla
In-Reply-To: <558721CD.7040105@oracle.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>
	<CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>
	<558721CD.7040105@oracle.com>
Message-ID: <CAGHtMWkvg_w0Ftt77wfbytQbcmXjnXtCBEeGbBWbnxCeB4p2Lw@mail.gmail.com>

Hi Robert,

No worries, we have a mvn pom.xml file which already does that = produces a
JAR, see
http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/en/openjdk-projects/kulla-pom-xml.html
.

It also powers our Adopt OpenJDK Cloudbees build farm for Kulla -
https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/

I'll add this as part of our regular OpenJDK9 build and that way wont need
to build an extra instance.

Cheers,
Mani

On Sun, Jun 21, 2015 at 9:42 PM, Robert Field <robert.field at oracle.com>
wrote:

>
> On 06/21/15 12:06, Mani Sarkar wrote:
>
> Hi Martijn, Robert,
>
>  This is good news, I should get my head around this soon and have
> something in place using your suggestions.
>
>
> Wonderful!
>
>
>  @Robert - we still like to extract the classes and produce a .jar file
> so that others can download it from our CI servers, does the mechanism to
> do that remains the same. Or are you also saying that the make clean images
> creates a .jar file in the build folder alongside the images folder (JDK
> and JRE).
>
>
> make images does not produce this JAR.
>
> The mechanism would not be the same because instead of using an external
> jline you would bundle up both the jshell and jline files from the make
> images.  The script compile.sh should provide good info about which files
> are needed, but it does so from the source perspective, I'd think you would
> just want to grab "make images" class files and stuff 'em in a JAR.  If
> that doesn't fall in place for you, I could take a look tomorrow.  Let us
> know how we can help.
>
> Thanks!
> Robert
>
>
>
>
>  Cheers.
> Mani
>
> On Sun, Jun 21, 2015 at 7:44 PM, Martijn Verburg <martijnverburg at gmail.com
> > wrote:
>
>> Hi Robert,
>>
>>  We should be able to help.  I'm a little out of action at present, but
>> hopefully Mani sees this and will get the build up and running.
>>
>>  Cheers,
>> Martijn
>>
>> On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:
>>
>>>   Yep.
>>>
>>> Executed with: jshell
>>>
>>> -R
>>>
>>> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>>  Does this mean for the kulla-dev forest I could go:
>>>>
>>>>  hg clone <url for kulla-dev>
>>>> ./get_source.sh
>>>> make clean images
>>>>
>>>>  And the REPL will be available?
>>>>
>>>>
>>>>
>>>>  Cheers,
>>>> Martijn
>>>>
>>>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com> wrote:
>>>>
>>>>>  Dear Mani, Martijn,
>>>>>
>>>>> Thank you for this work.
>>>>>
>>>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>>>> repo.  This version of jline has been made more platform independent (no
>>>>> longer requiring the external native libraries).  JShell now uses this.
>>>>>
>>>>> As a result the unit of a Kulla/JShell build is now a full JDK build.
>>>>> Would it be possible to do full Kulla JDK builds now?
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>>
>


-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From robert.field at oracle.com  Tue Jun 23 21:43:55 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 23 Jun 2015 21:43:55 +0000
Subject: hg: kulla/dev/langtools: Rename Key.Kind enums CLASS, METHOD,
	VARIABLE to TYPE_DECL, METHOD_DECL,
	VARIABLE_DECL.  And rename ClassKey, MethodKey,
	VariableKeu to TypeDeclKey, MethodDeclKey, VariableDeclKey.
Message-ID: <201506232143.t5NLhtC9018068@aojmv0008.oracle.com>

Changeset: 442b97a1176a
Author:    rfield
Date:      2015-06-23 14:43 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/442b97a1176a

Rename Key.Kind enums CLASS, METHOD, VARIABLE to TYPE_DECL, METHOD_DECL, VARIABLE_DECL.  And rename ClassKey, MethodKey, VariableKeu to TypeDeclKey, MethodDeclKey, VariableDeclKey.

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JDIExecution.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyMap.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/UnresolvedExceptionImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/Key.java
! src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
! src/jdk.jshell/share/classes/jdk/jshell/UnresolvedException.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/IllegalArgumentExceptionTest.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/RejectedFailedTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/TypeNameTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Wed Jun 24 01:16:29 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 24 Jun 2015 01:16:29 +0000
Subject: hg: kulla/dev/langtools: partial (SubKind) 8129093: JShell API:
	flesh-out, update,
	and properly format the API javadocs. And assorted clean-up including
	residual renaming.
Message-ID: <201506240116.t5O1GTBk029035@aojmv0008.oracle.com>

Changeset: 60a20dad6ed0
Author:    rfield
Date:      2015-06-23 18:16 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/60a20dad6ed0

partial (SubKind) 8129093: JShell API: flesh-out, update, and properly format the API javadocs.  And assorted clean-up including residual renaming.

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/Key.java
! src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
! test/jdk/jshell/JShellStateClosedExceptionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/ReplaceTest.java


From sadhak001 at gmail.com  Wed Jun 24 04:46:28 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Wed, 24 Jun 2015 05:46:28 +0100
Subject: Urgent: Can't get REPL to work anymore (for a live demo!)
Message-ID: <CAGHtMWkPGJSzFEvSDOyx5maHm50yOp-T565MGsywcrcXEKNq_w@mail.gmail.com>

Hi Roy,

Have you had a look at this ?

https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/lastSuccessfulBuild/artifact/
 (just bookmark it, we have archives of working versions, for future events)

We build one at every change. When you run the 0.610 version you get the
below:

*$ java -jar kulla-0.610-20150623005842.jar*

|  Welcome to JShell -- Version 0.610
|  Type /help for help

->

I hope by now your issue is resolved.

Cheers,
Mani

>
> ------------------------------
>
> Message: 8
> Date: Tue, 23 Jun 2015 09:05:18 -0700
> From: Robert Field <robert.field at oracle.com>
> To: Brian Goetz <brian.goetz at oracle.com>,       Roy van Rijn
>         <roy.van.rijn at gmail.com>, kulla-dev at openjdk.java.net
> Subject: Re: Urgent: Can't get REPL to work anymore (for a live demo!)
> Message-ID: <558983BE.8060900 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Yep, from the failure it looks likely to be related to socket or memory
> issues, so I asked him to try a reboot while I dive deeper.
>
> What is null is the output stream that gets set during opening the
> socket.  But if that fails it should throw an internal error and die,
> looking...
>
> -Robert
>
> On 06/23/15 08:58, Brian Goetz wrote:
> > I've seen a similar behavior on Mac -- when my network settings are
> > borked up due to running a VPN client.  Something keeps the JDI
> > connection from being made, and then it falls into an NPE later in the
> > program after something times out and returns null.
> >
> > On 6/23/2015 11:44 AM, Robert Field wrote:
> >> I can't reproduce.  I will keep looking.
> >>
> >> Just to be clear, is this what you did for clean install?
> >>
> >> hg clone  http://hg.openjdk.java.net/kulla/dev; cd dev; bash
> >> ./get_source.sh
> >> bash ./configure
> >> make images
> >>
> >> ???
> >> If so, can you try running with "jshell" command instead of script?
> >>
> >> -Robert
> >>
> >>
> >> On 06/23/15 08:33, Robert Field wrote:
> >>> Will look now!
> >>>
> >>>
> >>>
> >>>
> >>> On June 23, 2015 8:27:54 AM Roy van Rijn <roy.van.rijn at gmail.com>
> >>> wrote:
> >>>
> >>>> Tomorrow I've offered to do some live coding at a conference and show
> >>>> the
> >>>> new REPL.
> >>>> But when I did a clean install this afternoon as a test I suddenly
> >>>> got a
> >>>> REPL that didn't work. So panic is starting to come in...!
> >>>>
> >>>> This is what I now get:
> >>>>
> >>>> roy:repl royvanrijn$ ./scripts/run.sh
> >>>> |  Unexpected exception reading start-up:
> >>>> java.lang.NullPointerException
> >>>>
> >>>> |  Welcome to JShell -- Version 0.610
> >>>> |  Type /help for help
> >>>>
> >>>> -> System.out.println("Test");
> >>>> Exception in thread "main" java.lang.NullPointerException
> >>>> at
> >>>>
> jdk.internal.jshell.impl.JDIExecution.commandExit(JDIExecution.java:79)
> >>>>
> >>>> at jdk.internal.jshell.impl.JShellImpl.close(JShellImpl.java:139)
> >>>> at jdk.internal.jshell.tool.JShellTool.closeState(JShellTool.java:351)
> >>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:222)
> >>>> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:198)
> >>>> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:188)
> >>>>
> >>>> Any ideas on how I can fix this? I've looked at the recent checkins
> >>>> in hg,
> >>>> but couldn't find anything related....?
> >>>
> >>>
> >>
>
>

-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From sadhak001 at gmail.com  Wed Jun 24 04:51:44 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Wed, 24 Jun 2015 05:51:44 +0100
Subject: How to build kulla
In-Reply-To: <CAGHtMWkvg_w0Ftt77wfbytQbcmXjnXtCBEeGbBWbnxCeB4p2Lw@mail.gmail.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<552CD664.5010704@oracle.com>
	<CAP7YuARqfgE1FP+U=8T0222f2Jj99q5CdiOscUg-LMxAsN9+Sw@mail.gmail.com>
	<CAGHtMWm8z8V=RL6H-n7CVRtLb5gXNxS6mn5bD4Bj5mEWr1bGjg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>
	<CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>
	<558721CD.7040105@oracle.com>
	<CAGHtMWkvg_w0Ftt77wfbytQbcmXjnXtCBEeGbBWbnxCeB4p2Lw@mail.gmail.com>
Message-ID: <CAGHtMWnjTS9z4ZzYrmggQR_Mvf=UftjW=Y7=NmmVkBRAqFNHgg@mail.gmail.com>

Hi Robert,

On that note, would something like this maven script a good contribution to
the kulla project. It'll helps create a ~600KB portable .jar file to run
and play with and only needs a JDK9 runtime for it to work.

Cheers,
Mani

On Tue, Jun 23, 2015 at 9:57 PM, Mani Sarkar <sadhak001 at gmail.com> wrote:

> Hi Robert,
>
> No worries, we have a mvn pom.xml file which already does that = produces
> a JAR, see
> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/en/openjdk-projects/kulla-pom-xml.html
> .
>
> It also powers our Adopt OpenJDK Cloudbees build farm for Kulla -
> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/
>
> I'll add this as part of our regular OpenJDK9 build and that way wont need
> to build an extra instance.
>
> Cheers,
> Mani
>
> On Sun, Jun 21, 2015 at 9:42 PM, Robert Field <robert.field at oracle.com>
> wrote:
>
>>
>> On 06/21/15 12:06, Mani Sarkar wrote:
>>
>> Hi Martijn, Robert,
>>
>>  This is good news, I should get my head around this soon and have
>> something in place using your suggestions.
>>
>>
>> Wonderful!
>>
>>
>>  @Robert - we still like to extract the classes and produce a .jar file
>> so that others can download it from our CI servers, does the mechanism to
>> do that remains the same. Or are you also saying that the make clean images
>> creates a .jar file in the build folder alongside the images folder (JDK
>> and JRE).
>>
>>
>> make images does not produce this JAR.
>>
>> The mechanism would not be the same because instead of using an external
>> jline you would bundle up both the jshell and jline files from the make
>> images.  The script compile.sh should provide good info about which files
>> are needed, but it does so from the source perspective, I'd think you would
>> just want to grab "make images" class files and stuff 'em in a JAR.  If
>> that doesn't fall in place for you, I could take a look tomorrow.  Let us
>> know how we can help.
>>
>> Thanks!
>> Robert
>>
>>
>>
>>
>>  Cheers.
>> Mani
>>
>> On Sun, Jun 21, 2015 at 7:44 PM, Martijn Verburg <
>> martijnverburg at gmail.com> wrote:
>>
>>> Hi Robert,
>>>
>>>  We should be able to help.  I'm a little out of action at present, but
>>> hopefully Mani sees this and will get the build up and running.
>>>
>>>  Cheers,
>>> Martijn
>>>
>>> On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:
>>>
>>>>   Yep.
>>>>
>>>> Executed with: jshell
>>>>
>>>> -R
>>>>
>>>> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>>  Does this mean for the kulla-dev forest I could go:
>>>>>
>>>>>  hg clone <url for kulla-dev>
>>>>> ./get_source.sh
>>>>> make clean images
>>>>>
>>>>>  And the REPL will be available?
>>>>>
>>>>>
>>>>>
>>>>>  Cheers,
>>>>> Martijn
>>>>>
>>>>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com>
>>>>> wrote:
>>>>>
>>>>>>  Dear Mani, Martijn,
>>>>>>
>>>>>> Thank you for this work.
>>>>>>
>>>>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>>>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>>>>> repo.  This version of jline has been made more platform independent (no
>>>>>> longer requiring the external native libraries).  JShell now uses this.
>>>>>>
>>>>>> As a result the unit of a Kulla/JShell build is now a full JDK
>>>>>> build.  Would it be possible to do full Kulla JDK builds now?
>>>>>>
>>>>>> Thanks,
>>>>>> Robert
>>>>>>
>>>>>>
>>
>
>
> --
> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> <https://bitbucket.org/neomatrix369>* * |  **Github
> <https://github.com/neomatrix369>* * |  **LinkedIn
> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
>
> *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>



-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From dalibor.topic at oracle.com  Wed Jun 24 11:49:01 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 24 Jun 2015 13:49:01 +0200
Subject: How to build kulla
In-Reply-To: <CAGHtMWnjTS9z4ZzYrmggQR_Mvf=UftjW=Y7=NmmVkBRAqFNHgg@mail.gmail.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>	<552EC6F8.4050109@oracle.com>	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>	<5585FA73.4020108@oracle.com>	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>	<CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>	<CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>	<558721CD.7040105@oracle.com>	<CAGHtMWkvg_w0Ftt77wfbytQbcmXjnXtCBEeGbBWbnxCeB4p2Lw@mail.gmail.com>
	<CAGHtMWnjTS9z4ZzYrmggQR_Mvf=UftjW=Y7=NmmVkBRAqFNHgg@mail.gmail.com>
Message-ID: <558A992D.1090500@oracle.com>

Afaict, most of the authors listed at 
http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/ don't 
have an OCA on file, fwiw.

cheers,
dalibor topic

On 24.06.2015 06:51, Mani Sarkar wrote:
> Hi Robert,
>
> On that note, would something like this maven script a good contribution to
> the kulla project. It'll helps create a ~600KB portable .jar file to run
> and play with and only needs a JDK9 runtime for it to work.
>
> Cheers,
> Mani
>
> On Tue, Jun 23, 2015 at 9:57 PM, Mani Sarkar <sadhak001 at gmail.com> wrote:
>
>> Hi Robert,
>>
>> No worries, we have a mvn pom.xml file which already does that = produces
>> a JAR, see
>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/en/openjdk-projects/kulla-pom-xml.html
>> .
>>
>> It also powers our Adopt OpenJDK Cloudbees build farm for Kulla -
>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/
>>
>> I'll add this as part of our regular OpenJDK9 build and that way wont need
>> to build an extra instance.
>>
>> Cheers,
>> Mani
>>
>> On Sun, Jun 21, 2015 at 9:42 PM, Robert Field <robert.field at oracle.com>
>> wrote:
>>
>>>
>>> On 06/21/15 12:06, Mani Sarkar wrote:
>>>
>>> Hi Martijn, Robert,
>>>
>>>   This is good news, I should get my head around this soon and have
>>> something in place using your suggestions.
>>>
>>>
>>> Wonderful!
>>>
>>>
>>>   @Robert - we still like to extract the classes and produce a .jar file
>>> so that others can download it from our CI servers, does the mechanism to
>>> do that remains the same. Or are you also saying that the make clean images
>>> creates a .jar file in the build folder alongside the images folder (JDK
>>> and JRE).
>>>
>>>
>>> make images does not produce this JAR.
>>>
>>> The mechanism would not be the same because instead of using an external
>>> jline you would bundle up both the jshell and jline files from the make
>>> images.  The script compile.sh should provide good info about which files
>>> are needed, but it does so from the source perspective, I'd think you would
>>> just want to grab "make images" class files and stuff 'em in a JAR.  If
>>> that doesn't fall in place for you, I could take a look tomorrow.  Let us
>>> know how we can help.
>>>
>>> Thanks!
>>> Robert
>>>
>>>
>>>
>>>
>>>   Cheers.
>>> Mani
>>>
>>> On Sun, Jun 21, 2015 at 7:44 PM, Martijn Verburg <
>>> martijnverburg at gmail.com> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>>   We should be able to help.  I'm a little out of action at present, but
>>>> hopefully Mani sees this and will get the build up and running.
>>>>
>>>>   Cheers,
>>>> Martijn
>>>>
>>>> On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:
>>>>
>>>>>    Yep.
>>>>>
>>>>> Executed with: jshell
>>>>>
>>>>> -R
>>>>>
>>>>> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Robert,
>>>>>>
>>>>>>   Does this mean for the kulla-dev forest I could go:
>>>>>>
>>>>>>   hg clone <url for kulla-dev>
>>>>>> ./get_source.sh
>>>>>> make clean images
>>>>>>
>>>>>>   And the REPL will be available?
>>>>>>
>>>>>>
>>>>>>
>>>>>>   Cheers,
>>>>>> Martijn
>>>>>>
>>>>>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>>   Dear Mani, Martijn,
>>>>>>>
>>>>>>> Thank you for this work.
>>>>>>>
>>>>>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>>>>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>>>>>> repo.  This version of jline has been made more platform independent (no
>>>>>>> longer requiring the external native libraries).  JShell now uses this.
>>>>>>>
>>>>>>> As a result the unit of a Kulla/JShell build is now a full JDK
>>>>>>> build.  Would it be possible to do full Kulla JDK builds now?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>
>>
>>
>> --
>> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
>> (@adoptopenjdk & @adoptajsr programs)
>> *Meet-a-Project - *MutabilityDetector
>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>> <https://bitbucket.org/neomatrix369>* * |  **Github
>> <https://github.com/neomatrix369>* * |  **LinkedIn
>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>> *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
>>
>> *Don't chase success, rather aim for "Excellence", and success will come
>> chasing after you!*
>>
>
>
>

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From robert.field at oracle.com  Wed Jun 24 21:10:56 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 24 Jun 2015 21:10:56 +0000
Subject: hg: kulla/dev/langtools: partial (SourceCodeAnalysis, CompletionInfo, 
	Completeness) 8129093: JShell API: flesh-out, update,
	and properly format the API javadocs. And assorted clean-up including
	residual renaming.
Message-ID: <201506242110.t5OLAuOJ023305@aojmv0008.oracle.com>

Changeset: be67599bbc7f
Author:    rfield
Date:      2015-06-24 14:10 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/be67599bbc7f

partial (SourceCodeAnalysis, CompletionInfo, Completeness) 8129093: JShell API: flesh-out, update, and properly format the API javadocs.  And assorted clean-up including residual renaming.

! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java


From robert.field at oracle.com  Wed Jun 24 22:58:06 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 24 Jun 2015 22:58:06 +0000
Subject: hg: kulla/dev/langtools: partial (UnresolvedException) 8129093:
	JShell API: flesh-out, update, and properly format the API javadocs.
Message-ID: <201506242258.t5OMw6XN018480@aojmv0008.oracle.com>

Changeset: 8b850dd19f03
Author:    rfield
Date:      2015-06-24 15:57 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/8b850dd19f03

partial (UnresolvedException) 8129093: JShell API: flesh-out, update, and properly format the API javadocs.

! src/jdk.jshell/share/classes/jdk/jshell/UnresolvedException.java


From robert.field at oracle.com  Wed Jun 24 23:47:49 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 24 Jun 2015 23:47:49 +0000
Subject: hg: kulla/dev/langtools: Pull up SubKind as a member of Key
Message-ID: <201506242347.t5ONln5X026892@aojmv0008.oracle.com>

Changeset: 7e31abb6cb13
Author:    rfield
Date:      2015-06-24 16:47 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/7e31abb6cb13

Pull up SubKind as a member of Key

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/Key.java
- src/jdk.jshell/share/classes/jdk/jshell/SubKind.java
! test/jdk/jshell/ClassesTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Thu Jun 25 15:02:21 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 25 Jun 2015 15:02:21 +0000
Subject: hg: kulla/dev/langtools: 8129543: JShell API: Change JShell and
	SourceCodeAnalysis to abstract classes
Message-ID: <201506251502.t5PF2MM5016354@aojmv0008.oracle.com>

Changeset: ebd3911d497d
Author:    rfield
Date:      2015-06-25 08:02 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/ebd3911d497d

8129543: JShell API: Change JShell and SourceCodeAnalysis to abstract classes

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! src/jdk.jshell/share/classes/jdk/jshell/JShell.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java


From robert.field at oracle.com  Thu Jun 25 16:30:52 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 25 Jun 2015 16:30:52 +0000
Subject: hg: kulla/dev/langtools: 8129541: JShell API: make all returned lists
	unmodifiable
Message-ID: <201506251630.t5PGUqbb013272@aojmv0008.oracle.com>

Changeset: 464df4ed2626
Author:    rfield
Date:      2015-06-25 09:30 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/464df4ed2626

8129541: JShell API: make all returned lists unmodifiable

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! test/jdk/jshell/KullaTesting.java


From jan.lahoda at oracle.com  Thu Jun 25 17:38:30 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Thu, 25 Jun 2015 17:38:30 +0000
Subject: hg: kulla/dev/langtools: Adding rudimentary javadoc to the completion
	API
Message-ID: <201506251738.t5PHcUOY005362@aojmv0008.oracle.com>

Changeset: c0c4a842c90c
Author:    jlahoda
Date:      2015-06-25 19:38 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/c0c4a842c90c

Adding rudimentary javadoc to the completion API

! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java


From robert.field at oracle.com  Thu Jun 25 18:05:18 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 25 Jun 2015 18:05:18 +0000
Subject: hg: kulla/dev/langtools: 8080762: JShell tool: cannot edit
	declaration from the start-up definitions
Message-ID: <201506251805.t5PI5I1T013563@aojmv0008.oracle.com>

Changeset: 74610d538663
Author:    rfield
Date:      2015-06-25 11:05 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/74610d538663

8080762: JShell tool: cannot edit declaration from the start-up definitions

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java


From robert.field at oracle.com  Thu Jun 25 18:57:27 2015
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 25 Jun 2015 18:57:27 +0000
Subject: hg: kulla/dev/langtools: 8129093: JShell API: flesh-out, update,
	and properly format the API javadocs. The final commit for this
	issue. Includes docs clean-up on Suggestion and related.
	Includes removal of unused Suggestion.description. Includes
	rename of CompletionType to SuggestionKind,
	Suggestion.completion to continuation Suggestion.completionType to
	suggestionKind.
Message-ID: <201506251857.t5PIvRkd028852@aojmv0008.oracle.com>

Changeset: f0e1cdcb14ae
Author:    rfield
Date:      2015-06-25 11:57 -0700
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/f0e1cdcb14ae

8129093: JShell API: flesh-out, update, and properly format the API javadocs.  The final commit for this issue.  Includes docs clean-up on Suggestion and related.  Includes removal of unused Suggestion.description.  Includes rename of CompletionType to SuggestionKind, Suggestion.completion to continuation Suggestion.completionType to suggestionKind.

! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SourceCodeAnalysisImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
! test/jdk/jshell/CommandCompletionTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/ReplToolTesting.java


From robert.field at oracle.com  Thu Jun 25 19:50:11 2015
From: robert.field at oracle.com (Robert Field)
Date: Thu, 25 Jun 2015 12:50:11 -0700
Subject: Kulla: Please review JShell API
Message-ID: <558C5B73.7020708@oracle.com>

Please review the API.  The javadocs can be found here:

     http://cr.openjdk.java.net/~rfield/doc

Sources (as always) are here:

     http://hg.openjdk.java.net/kulla/dev

All comments welcome.

Thanks,
Robert


From sadhak001 at gmail.com  Thu Jun 25 20:21:10 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Thu, 25 Jun 2015 21:21:10 +0100
Subject: How to build kulla (dalibor topic)
Message-ID: <CAGHtMWmWozNwtDQK8+W0sPG5G9RFv_xZizRbCQyaxp5p2SaHMQ@mail.gmail.com>

Hi Dalibor,

If need be we can request the respective authors to get an OCA signed. If
its about the maven script, its originally written by me and I do have an
OCA.

Cheers,
Mani

>
> Message: 2
> Date: Wed, 24 Jun 2015 13:49:01 +0200
> From: dalibor topic <dalibor.topic at oracle.com>
> To: kulla-dev at openjdk.java.net
> Subject: Re: How to build kulla
> Message-ID: <558A992D.1090500 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Afaict, most of the authors listed at
> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/ don't
> have an OCA on file, fwiw.
>
> cheers,
> dalibor topic
>

-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From jan.lahoda at oracle.com  Fri Jun 26 10:04:55 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Fri, 26 Jun 2015 10:04:55 +0000
Subject: hg: kulla/dev/langtools: 8129941: JShell tool: IllegalStateException
	is thrown for commands '/n' and '/-n'
Message-ID: <201506261004.t5QA4tUP027232@aojmv0008.oracle.com>

Changeset: b2e07ae450ed
Author:    jlahoda
Date:      2015-06-26 12:04 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/b2e07ae450ed

8129941: JShell tool: IllegalStateException is thrown for commands '/n' and '/-n'
Summary: Mark the /n and /-n as help-only commands.

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java


From bitterfoxc at gmail.com  Fri Jun 26 11:33:06 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Fri, 26 Jun 2015 20:33:06 +0900
Subject: RFR 8129935: JShell Tool: Variable decl which is for the variable of
	the type of multi-byte character shows the unicode string as the type
Message-ID: <CAHjBcHNxOztQbAZKy0hyzkR1HF6mAmQD_RArYkoNzvCQtyZQYw@mail.gmail.com>

Hi Robert,
Please review this patch:

bugs:
https://bugs.openjdk.java.net/browse/JDK-8129935

webrev:
http://cr.openjdk.java.net/~shinyafox/kulla/8129935/webrev.00/

Regards,
shinyafox(Shinya Yoshida)

From dalibor.topic at oracle.com  Fri Jun 26 15:57:11 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 26 Jun 2015 17:57:11 +0200
Subject: How to build kulla (dalibor topic)
In-Reply-To: <CAGHtMWmWozNwtDQK8+W0sPG5G9RFv_xZizRbCQyaxp5p2SaHMQ@mail.gmail.com>
References: <CAGHtMWmWozNwtDQK8+W0sPG5G9RFv_xZizRbCQyaxp5p2SaHMQ@mail.gmail.com>
Message-ID: <558D7657.2030805@oracle.com>

It's not my call whether a specific kind of a maven script is useful to 
this Project or not. But in general, if there are multiple authors to a 
proposed contribution, they all need to be covered under an OCA.

cheers,
dalibor topic

On 25.06.2015 22:21, Mani Sarkar wrote:
> Hi Dalibor,
>
> If need be we can request the respective authors to get an OCA signed. If
> its about the maven script, its originally written by me and I do have an
> OCA.
>
> Cheers,
> Mani
>
>>
>> Message: 2
>> Date: Wed, 24 Jun 2015 13:49:01 +0200
>> From: dalibor topic <dalibor.topic at oracle.com>
>> To: kulla-dev at openjdk.java.net
>> Subject: Re: How to build kulla
>> Message-ID: <558A992D.1090500 at oracle.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Afaict, most of the authors listed at
>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/ don't
>> have an OCA on file, fwiw.
>>
>> cheers,
>> dalibor topic
>>
>

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From brian.goetz at oracle.com  Fri Jun 26 16:37:52 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 26 Jun 2015 12:37:52 -0400
Subject: Default kulla messages
In-Reply-To: <558880B8.9080501@oracle.com>
References: <558880B8.9080501@oracle.com>
Message-ID: <558D7FE0.3000407@oracle.com>

I've gotten a few private responses on this so let me summarize them.

There's a range of opinions on whether the default behavior should lean 
towards "onboarding new users".  We've faced this decision before in 
other contexts, and our default orientation is that we should design for 
the longer-term steady-state, and avoid over-rotating towards 
highlighting what is new -- since new is a temporary state.  In other 
words, build the UX so that it serves the intended use cases, not 
necessarily the "teach people to use the REPL case."  (There are other 
means of educating new users.)

In surveying a number of REPLs, the common theme is that their output is 
terse.  In some cases, its because there's less information to display 
(some languages don't have types, so they don't display those), but even 
in the Scala case, where there's plenty of type information, the REPL UX 
is "just the facts."  I think we would need a good reason to buck this 
trend.

Some pointed out that the user can change the verbosity level.  Which is 
true -- and a great feature -- but let's admit the reality that 99% of 
users never will; they'll just type 'jshell'.  So the default UX needs 
to serve the broadest range of users.

There's several categories of output that the REPL might report.  Let's 
enumerate them.

1.  Expression results.  (If the input was an expression, we probably 
always want to print this; if its not an expression, there's nothing to 
print.)

2.  Text sent to System.{out,err}.

3.  Diagnostics either from compiling the input or from executing a REPL 
command.

4.  Runtime exceptions produced during execution.

5.  Side-effects on the REPL state (vars/methods/classes 
declared/invalidated/dropped/changed state.)

Some of these are mutually exclusive; if there's a compilation error, 
there'll be no evaluation.

Here's what I am proposing for the default scheme:

(3) is printed first -- and we stop here (unless the diagnostic is 
merely a warning)
(2) is printed as it is generated, with no decoration
If the input was an expression, (1) is printed, prefixed by something 
like "=> "
If an exception occurred, (4) is printed
(5) is printed, parenthetically.

For (5), there are sub-categories:
  a) a new temporary variable was created
  b) a new variable was created (var declaration)
  c) a new method/class was created
  d) a variable/class/method was invalidated
  e) a variable changed its value (assignment to existing var)

By default, I'm suggesting we should print something for (a) and (c), 
and maybe (b) but not for the others.

Key to this is: other schemes can change the verbosity of individual 
elements ("created $1" vs "created temporary variable $1 of type int") 
or whether elements are printed at all, but should not change the 
overall structure.

Some examples:

repl> 1 + 1
=> 2
(declared temporary variable $1 of type int)

repl> int x = 3
(declared variable x of type int)  // maybe

repl> x + 1
=> 4
(declared temporary variable $2 of type int)

repl> if (x == 3) x = 4;
// statement -- no result, no structural side-effects

repl> int m() { return 43; }
(declared method m)

repl> m()
=> 43
(declared temporary variable $3 of type int)

repl> /drop m
(dropped method m)

repl> /drop m
error: cannot drop m, does not exist

repl> $1/0
java.lang.ArithmeticException: divide by zero
... stack trace ...

repl> System.out.println("Hello World")
Hello World


Some felt that we should print type and value for every assignment. 
But, let's not forget that the user can always ask for these if they 
want, just by evaluating the variable:

repl> x = f(...)

repl> x
=> Foo[blah, blah ]

So I think we should err on the side of *not* printing values that are 
not the result of evaluating a top-level expression.




On 6/22/2015 5:40 PM, Brian Goetz wrote:
> The messages produced by JShell during the course of
> evaluation/declaration have been in a placeholder state for a while, and
> its probably time to paint the bikeshed of what the default messages
> should look like (there are multiple message schemes, which can crank up
> and down the verbosity, but the default set is the most important.)
>
> Here's what JShell prints now for an expression and a method declaration:
>
> -> 1 + 1
> |  Expression value is: 2
> |    assigned to temporary variable $1 of type int
>
> -> void foo() { }
> |  Added method foo()
>
> These are all useful bits of information:
>   - the result of the expression, if any
>   - side-effects on the REPL state
>     - temporary name and type, for expressions
>     - var/method/class name and type, for declarations
>
> However, plenty of people have commented that these messages are "kind
> of verbose".
>
> The Scala REPL output contains all this information too, but more
> compactly:
>
> scala> 1 + 1
> res1: Int = 2
>
> scala> def m() { }
> m: ()Unit
>
> The Ruby IRB output is more taciturn:
>
> irb(main):001:0> 1 + 1
> => 2
> irb(main):002:0> def m()
> irb(main):003:1>     puts "Hello"
> irb(main):004:1> end
> => nil
>
> The Perl re.pl even more so:
>
> $ 1 + 1
> 2
> $ sub m {
>  >     return 1;
>  > }
> (empty line)
>  >
>
>
> While we could gather more examples, I think there's a pattern emerging:
> expression evaluation should put the result front-and-center.
>
> Here are some possible options for the evaluation of 1+1 in jshell:
>
> --
> 2 (assigned to temporary $1)
> --
> 2 (assigned to temporary $1 : int)
> --
> $1 (int): 2
> --
> => 2
> (assigned to temporary $1 : int)
> --
> int: 2
> (assigned to temporary $1 of type int)
>
> There are obviously many more variations.
>
> I propose using, as the default level:
>
> => expression value
>
> to indicate the result of an expression, with statements producing no
> output, coupled with a convention to put all side-effect-on-REPL-state
> information in parentheses on its own line:
>
> repl> 1 + 1
> => 2
> (assigned to temporary $1 of type int)
>
> repl> void m() { }
> (defined method m())
>
> repl> /drop m
> (dropped method m())
>
> repl> int x = 3
> (declared variable x of type int)
>
> repl> x = 4
> (no output)
>
>
> I think this scheme captures the essential information without too much
> noise (users can select a higher verbosity level if they want.)
>

From paul.sandoz at oracle.com  Fri Jun 26 12:07:59 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Jun 2015 14:07:59 +0200
Subject: Kulla: Please review JShell API
In-Reply-To: <558C5B73.7020708@oracle.com>
References: <558C5B73.7020708@oracle.com>
Message-ID: <F03F11F9-535C-468C-B9D2-C74176C6B845@oracle.com>


On Jun 25, 2015, at 9:50 PM, Robert Field <robert.field at oracle.com> wrote:

> Please review the API.  The javadocs can be found here:
> 
>    http://cr.openjdk.java.net/~rfield/doc
> 
> Sources (as always) are here:
> 
>    http://hg.openjdk.java.net/kulla/dev
> 
> All comments welcome.
> 

Fun fact: one can test drive the REPL in the REPL, "REPL-is-Eval-Print-Loop" :-)

kulla-dev $ ./build/macosx-x86_64-normal-server-release/images/jdk/bin/jshell
|  Welcome to JShell -- Version 0.610
|  Type /help for help

-> import jdk.jshell.*

-> JShell js = JShell.create(System.in, System.out, System.err);
|  Added variable js of type JShell with initial value jdk.internal.jshell.impl.JShellImpl at 6d00a15d

-> js.eval("Integer.valueOf(1)");
|  Expression value is: [jdk.jshell.KeyStatusEvent at 710f4dc7]
|    assigned to temporary variable $1 of type List<KeyStatusEvent>

-> $1.get(0)
|  Expression value is: jdk.jshell.KeyStatusEvent at 710f4dc7
|    assigned to temporary variable $2 of type KeyStatusEvent

-> $2.value
|  Expression value is: "1"
|    assigned to temporary variable $3 of type String


I have started playing with it. So far it feels like a really solid piece of engineering. The jshell tool has some nice polish with history and auto-completion. Great stuff!

Paul.

From paul.sandoz at oracle.com  Fri Jun 26 17:51:26 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Jun 2015 19:51:26 +0200
Subject: Default kulla messages
In-Reply-To: <558D7FE0.3000407@oracle.com>
References: <558880B8.9080501@oracle.com> <558D7FE0.3000407@oracle.com>
Message-ID: <AEB0B0DA-AB30-47D7-839C-C471CD1FE2E2@oracle.com>

I think this sets the right precedence, aim towards what we think the steady state should be, with the options for more verbosity if need be for new users.

The degree of output hits a good balance.

I am tempted to suggest an even more terse approach, such as:

-> int x = 0
| int x = 0

-> x    // <- this is not the current behaviour in the current REPL
| int $1 = 0

-> x + 1
| int $2 = 1

-> int y = x + 1
| int y = 1

-> int m() { return 1; }
| int m()

-> m()
| int $3 = 1

-> class A { void m() {} }
| class A

-> new A()
| A $4 = A at 6842775d

-> enum E { ALPHA, BETA; }
| enum E

-> java.util.stream.IntStream.range(0, 100).mapToObj(Integer::toString).collect(java.util.stream.Collectors.toList())
| List<String> $5 = [0, 1, 2, 3, 4, 5, 6, 7]

It might be a little too terse, but i like the way i can observe the variable type, name, and value on one line. I can easily infer that the REPL created a new variable for me.

Either way we might need smarter toString output if the resulting string length is too large .

Paul.

On Jun 26, 2015, at 6:37 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> I've gotten a few private responses on this so let me summarize them.
> 
> There's a range of opinions on whether the default behavior should lean towards "onboarding new users".  We've faced this decision before in other contexts, and our default orientation is that we should design for the longer-term steady-state, and avoid over-rotating towards highlighting what is new -- since new is a temporary state.  In other words, build the UX so that it serves the intended use cases, not necessarily the "teach people to use the REPL case."  (There are other means of educating new users.)
> 
> In surveying a number of REPLs, the common theme is that their output is terse.  In some cases, its because there's less information to display (some languages don't have types, so they don't display those), but even in the Scala case, where there's plenty of type information, the REPL UX is "just the facts."  I think we would need a good reason to buck this trend.
> 
> Some pointed out that the user can change the verbosity level.  Which is true -- and a great feature -- but let's admit the reality that 99% of users never will; they'll just type 'jshell'.  So the default UX needs to serve the broadest range of users.
> 
> There's several categories of output that the REPL might report.  Let's enumerate them.
> 
> 1.  Expression results.  (If the input was an expression, we probably always want to print this; if its not an expression, there's nothing to print.)
> 
> 2.  Text sent to System.{out,err}.
> 
> 3.  Diagnostics either from compiling the input or from executing a REPL command.
> 
> 4.  Runtime exceptions produced during execution.
> 
> 5.  Side-effects on the REPL state (vars/methods/classes declared/invalidated/dropped/changed state.)
> 
> Some of these are mutually exclusive; if there's a compilation error, there'll be no evaluation.
> 
> Here's what I am proposing for the default scheme:
> 
> (3) is printed first -- and we stop here (unless the diagnostic is merely a warning)
> (2) is printed as it is generated, with no decoration
> If the input was an expression, (1) is printed, prefixed by something like "=> "
> If an exception occurred, (4) is printed
> (5) is printed, parenthetically.
> 
> For (5), there are sub-categories:
> a) a new temporary variable was created
> b) a new variable was created (var declaration)
> c) a new method/class was created
> d) a variable/class/method was invalidated
> e) a variable changed its value (assignment to existing var)
> 
> By default, I'm suggesting we should print something for (a) and (c), and maybe (b) but not for the others.
> 
> Key to this is: other schemes can change the verbosity of individual elements ("created $1" vs "created temporary variable $1 of type int") or whether elements are printed at all, but should not change the overall structure.
> 
> Some examples:
> 
> repl> 1 + 1
> => 2
> (declared temporary variable $1 of type int)
> 
> repl> int x = 3
> (declared variable x of type int)  // maybe
> 
> repl> x + 1
> => 4
> (declared temporary variable $2 of type int)
> 
> repl> if (x == 3) x = 4;
> // statement -- no result, no structural side-effects
> 
> repl> int m() { return 43; }
> (declared method m)
> 
> repl> m()
> => 43
> (declared temporary variable $3 of type int)
> 
> repl> /drop m
> (dropped method m)
> 
> repl> /drop m
> error: cannot drop m, does not exist
> 
> repl> $1/0
> java.lang.ArithmeticException: divide by zero
> ... stack trace ...
> 
> repl> System.out.println("Hello World")
> Hello World
> 
> 
> Some felt that we should print type and value for every assignment. But, let's not forget that the user can always ask for these if they want, just by evaluating the variable:
> 
> repl> x = f(...)
> 
> repl> x
> => Foo[blah, blah ]
> 
> So I think we should err on the side of *not* printing values that are not the result of evaluating a top-level expression.
> 
> 
> 
> 
> On 6/22/2015 5:40 PM, Brian Goetz wrote:
>> The messages produced by JShell during the course of
>> evaluation/declaration have been in a placeholder state for a while, and
>> its probably time to paint the bikeshed of what the default messages
>> should look like (there are multiple message schemes, which can crank up
>> and down the verbosity, but the default set is the most important.)
>> 
>> Here's what JShell prints now for an expression and a method declaration:
>> 
>> -> 1 + 1
>> |  Expression value is: 2
>> |    assigned to temporary variable $1 of type int
>> 
>> -> void foo() { }
>> |  Added method foo()
>> 
>> These are all useful bits of information:
>>  - the result of the expression, if any
>>  - side-effects on the REPL state
>>    - temporary name and type, for expressions
>>    - var/method/class name and type, for declarations
>> 
>> However, plenty of people have commented that these messages are "kind
>> of verbose".
>> 
>> The Scala REPL output contains all this information too, but more
>> compactly:
>> 
>> scala> 1 + 1
>> res1: Int = 2
>> 
>> scala> def m() { }
>> m: ()Unit
>> 
>> The Ruby IRB output is more taciturn:
>> 
>> irb(main):001:0> 1 + 1
>> => 2
>> irb(main):002:0> def m()
>> irb(main):003:1>     puts "Hello"
>> irb(main):004:1> end
>> => nil
>> 
>> The Perl re.pl even more so:
>> 
>> $ 1 + 1
>> 2
>> $ sub m {
>> >     return 1;
>> > }
>> (empty line)
>> >
>> 
>> 
>> While we could gather more examples, I think there's a pattern emerging:
>> expression evaluation should put the result front-and-center.
>> 
>> Here are some possible options for the evaluation of 1+1 in jshell:
>> 
>> --
>> 2 (assigned to temporary $1)
>> --
>> 2 (assigned to temporary $1 : int)
>> --
>> $1 (int): 2
>> --
>> => 2
>> (assigned to temporary $1 : int)
>> --
>> int: 2
>> (assigned to temporary $1 of type int)
>> 
>> There are obviously many more variations.
>> 
>> I propose using, as the default level:
>> 
>> => expression value
>> 
>> to indicate the result of an expression, with statements producing no
>> output, coupled with a convention to put all side-effect-on-REPL-state
>> information in parentheses on its own line:
>> 
>> repl> 1 + 1
>> => 2
>> (assigned to temporary $1 of type int)
>> 
>> repl> void m() { }
>> (defined method m())
>> 
>> repl> /drop m
>> (dropped method m())
>> 
>> repl> int x = 3
>> (declared variable x of type int)
>> 
>> repl> x = 4
>> (no output)
>> 
>> 
>> I think this scheme captures the essential information without too much
>> noise (users can select a higher verbosity level if they want.)
>> 


From sadhak001 at gmail.com  Fri Jun 26 20:25:02 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Fri, 26 Jun 2015 21:25:02 +0100
Subject: How to build kulla (dalibor topic)
In-Reply-To: <CAGHtMWmWozNwtDQK8+W0sPG5G9RFv_xZizRbCQyaxp5p2SaHMQ@mail.gmail.com>
References: <CAGHtMWmWozNwtDQK8+W0sPG5G9RFv_xZizRbCQyaxp5p2SaHMQ@mail.gmail.com>
Message-ID: <CAGHtMWknH5+_nhPPB+_9GBkA+NoJKet+Vw7KOffxdsxahQ0P=g@mail.gmail.com>

Thanks for the heads up Dalibor. Will keep in mind for the next time.

I'll leave it to you and the rest of the community to decide if this script
is a good edition or not.

Cheers,
Mani

On Thu, Jun 25, 2015 at 9:21 PM, Mani Sarkar <sadhak001 at gmail.com> wrote:

> Hi Dalibor,
>
> If need be we can request the respective authors to get an OCA signed. If
> its about the maven script, its originally written by me and I do have an
> OCA.
>
> Cheers,
> Mani
>
>>
>> Message: 2
>> Date: Wed, 24 Jun 2015 13:49:01 +0200
>> From: dalibor topic <dalibor.topic at oracle.com>
>> To: kulla-dev at openjdk.java.net
>> Subject: Re: How to build kulla
>> Message-ID: <558A992D.1090500 at oracle.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Afaict, most of the authors listed at
>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/ don't
>> have an OCA on file, fwiw.
>>
>> cheers,
>> dalibor topic
>>
>
> --
> @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> <https://bitbucket.org/neomatrix369>* * |  **Github
> <https://github.com/neomatrix369>* * |  **LinkedIn
> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
>
> *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>



-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From sadhak001 at gmail.com  Sat Jun 27 10:23:11 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Sat, 27 Jun 2015 11:23:11 +0100
Subject: How to build kulla
In-Reply-To: <558A417E.8080906@oracle.com>
References: <CAGHtMW=FN02UX=oGhe-0piLPGubEmvY2ZsExqpk5RyFMZAEbAg@mail.gmail.com>
	<CAGHtMWnfL1kQNgNXW1G0qvO6jUmxgEDYiDZoiEY867R4VzWFSg@mail.gmail.com>
	<CAGHtMW=gbiqH6vzUfUTGHSvBSnhhwWrqgwFaMCxgU+xbnbV5uA@mail.gmail.com>
	<CAP7YuARfK3S6QTKKSWX1cSRvt7TgjRfpdQfbxusZDFVUPY8n1w@mail.gmail.com>
	<552EC6F8.4050109@oracle.com>
	<CAGHtMWkPTE6ZDae2VkL1+pwDguMLxuRUz65Csc2m1GJrayd8SQ@mail.gmail.com>
	<14cd76b4228.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAGHtMWk4GcbSsiZcV3OBd2ZkpxZjCuMviyk0HGPRA3xwXgoE-g@mail.gmail.com>
	<5585FA73.4020108@oracle.com>
	<CAP7YuASyQW5+fUX7Yt7xROtGYs2RNwDn+gFA4wHf8t3T2D=BfA@mail.gmail.com>
	<14e17598e70.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<CAP7YuARpd+=J0en5kfz6L5rsg=ftpTzurQF+SQdnYkComv0Xkw@mail.gmail.com>
	<CAGHtMWm52yWYHOqqypePof0sey1w5431YVyfx9ujtU2WwjO=3w@mail.gmail.com>
	<558721CD.7040105@oracle.com>
	<CAGHtMWkvg_w0Ftt77wfbytQbcmXjnXtCBEeGbBWbnxCeB4p2Lw@mail.gmail.com>
	<CAGHtMWnjTS9z4ZzYrmggQR_Mvf=UftjW=Y7=NmmVkBRAqFNHgg@mail.gmail.com>
	<558A417E.8080906@oracle.com>
Message-ID: <CAGHtMWkWpTBiKU2J2V5iO+=V_yvMrHYG-DMFCfwHF5nu4YztPw@mail.gmail.com>

Hi Robert,

For now we can keep it as a separate file people can download and place it
in the respective folder to run and generate the .jar file.

Maybe a make file equivalent of it that creates a jar is an option.

As far as JShell is concerned, I dont think we need to do anything with
regards to our build on CloudBees, I will soon be merging the two builds
jobs to produce a kulla.jar once the openjdk9 build is complete.

More on this later.

Cheers,
Mani

On Wed, Jun 24, 2015 at 6:34 AM, Robert Field <robert.field at oracle.com>
wrote:

>  Hi Mani,
>
> I'm open to what others think, but my first thinking is that as we move
> towards integrating Kulla into JDK9 we will need to move towards removing
> all the JShell specific build stuff.
>
> It is a great resource to have.  And I'll make use of it or its products.
> I don't know how it would fit into a generic JDK9 world.
>
> Thanks,
> Robert
>
>
>
> On 06/23/15 21:51, Mani Sarkar wrote:
>
> Hi Robert,
>
>  On that note, would something like this maven script a good contribution
> to the kulla project. It'll helps create a ~600KB portable .jar file to run
> and play with and only needs a JDK9 runtime for it to work.
>
>  Cheers,
> Mani
>
> On Tue, Jun 23, 2015 at 9:57 PM, Mani Sarkar <sadhak001 at gmail.com> wrote:
>
>> Hi Robert,
>>
>>  No worries, we have a mvn pom.xml file which already does that =
>> produces a JAR, see
>> http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/en/openjdk-projects/kulla-pom-xml.html
>> .
>>
>>  It also powers our Adopt OpenJDK Cloudbees build farm for Kulla -
>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/langtools-1.9-linux-x86_64-kulla-dev/
>>
>>  I'll add this as part of our regular OpenJDK9 build and that way wont
>> need to build an extra instance.
>>
>>  Cheers,
>> Mani
>>
>> On Sun, Jun 21, 2015 at 9:42 PM, Robert Field <robert.field at oracle.com>
>> wrote:
>>
>>>
>>> On 06/21/15 12:06, Mani Sarkar wrote:
>>>
>>> Hi Martijn, Robert,
>>>
>>>  This is good news, I should get my head around this soon and have
>>> something in place using your suggestions.
>>>
>>>
>>>  Wonderful!
>>>
>>>
>>>  @Robert - we still like to extract the classes and produce a .jar file
>>> so that others can download it from our CI servers, does the mechanism to
>>> do that remains the same. Or are you also saying that the make clean images
>>> creates a .jar file in the build folder alongside the images folder (JDK
>>> and JRE).
>>>
>>>
>>>  make images does not produce this JAR.
>>>
>>> The mechanism would not be the same because instead of using an external
>>> jline you would bundle up both the jshell and jline files from the make
>>> images.  The script compile.sh should provide good info about which files
>>> are needed, but it does so from the source perspective, I'd think you would
>>> just want to grab "make images" class files and stuff 'em in a JAR.  If
>>> that doesn't fall in place for you, I could take a look tomorrow.  Let us
>>> know how we can help.
>>>
>>> Thanks!
>>> Robert
>>>
>>>
>>>
>>>
>>>  Cheers.
>>> Mani
>>>
>>> On Sun, Jun 21, 2015 at 7:44 PM, Martijn Verburg <
>>> martijnverburg at gmail.com> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>>  We should be able to help.  I'm a little out of action at present,
>>>> but hopefully Mani sees this and will get the build up and running.
>>>>
>>>>  Cheers,
>>>> Martijn
>>>>
>>>> On 21 June 2015 at 19:20, Robert Field <robert.field at oracle.com> wrote:
>>>>
>>>>>   Yep.
>>>>>
>>>>> Executed with: jshell
>>>>>
>>>>> -R
>>>>>
>>>>> On June 21, 2015 10:48:30 AM Martijn Verburg <martijnverburg at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Robert,
>>>>>>
>>>>>>  Does this mean for the kulla-dev forest I could go:
>>>>>>
>>>>>>  hg clone <url for kulla-dev>
>>>>>> ./get_source.sh
>>>>>> make clean images
>>>>>>
>>>>>>  And the REPL will be available?
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Cheers,
>>>>>> Martijn
>>>>>>
>>>>>> On 21 June 2015 at 00:42, Robert Field <robert.field at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>>  Dear Mani, Martijn,
>>>>>>>
>>>>>>> Thank you for this work.
>>>>>>>
>>>>>>> Kulla (aka JShell) has moved quite a ways now towards being ready to
>>>>>>> merge into JDK9.  Jline is now integrated into the jdk side of the Kulla
>>>>>>> repo.  This version of jline has been made more platform independent (no
>>>>>>> longer requiring the external native libraries).  JShell now uses this.
>>>>>>>
>>>>>>> As a result the unit of a Kulla/JShell build is now a full JDK
>>>>>>> build.  Would it be possible to do full Kulla JDK builds now?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>
>>
>>
>>   --
>>   @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
>> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
>> (@adoptopenjdk & @adoptajsr programs)
>> *Meet-a-Project - *MutabilityDetector
>> <https://github.com/MutabilityDetector>*  |  **Bitbucket
>> <https://bitbucket.org/neomatrix369>* * |  **Github
>> <https://github.com/neomatrix369>* * |  **LinkedIn
>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
>>  *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
>>
>>  *Don't chase success, rather aim for "Excellence", and success will
>> come chasing after you!*
>>
>
>
>
>  --
>   @theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
> <http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <https://github.com/MutabilityDetector>*  |  **Bitbucket
> <https://bitbucket.org/neomatrix369>* * |  **Github
> <https://github.com/neomatrix369>* * |  **LinkedIn
> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/
>
>  *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>
>
>


-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

From bitterfoxc at gmail.com  Sun Jun 28 05:11:08 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Sun, 28 Jun 2015 14:11:08 +0900
Subject: Feedback for the command syntax and the behavior of the temporary
	variable
Message-ID: <CAHjBcHOU+DqopZ1mNMardz6dk5b3iZy6bAEOEGNtN9=OkJOX-Q@mail.gmail.com>

Hi REPL team,
A Japanese developer, @mike_neck, has two opinions(feedback) for our REPL.
You can see the opinion in his blog:
http://mike-neck.hatenadiary.com/entry/2015/06/26/161747
English translation is here:
https://translate.google.co.jp/translate?hl=ja&sl=ja&tl=en&u=http%3A%2F%2Fmike-neck.hatenadiary.com%2Fentry%2F2015%2F06%2F26%2F161747

1. Opinion for the command syntax
The commands of the many REPL such as scala, groovysh or ghci start with
":".
So he felt the prefix of jshell's commands is confusing.
And he suggest the prefix of jshell's commands will be the same as other
REPL.

2. Opinion for the behavior of the temporary variable.
His opinion is "Currently the temporary variable can be re-assigned, but it
doesn't make sense. It should be final.":

-> 0
|  Expression value is: 0
|    assigned to temporary variable $1 of type int

-> $1 = 10
|  Variable $1 has been assigned the value 10

What do you think?

Regards,
shinyafox(Shinya Yoshida)

From paul.sandoz at oracle.com  Mon Jun 29 07:49:10 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 29 Jun 2015 09:49:10 +0200
Subject: Feedback for the command syntax and the behavior of the temporary
	variable
In-Reply-To: <CAHjBcHOU+DqopZ1mNMardz6dk5b3iZy6bAEOEGNtN9=OkJOX-Q@mail.gmail.com>
References: <CAHjBcHOU+DqopZ1mNMardz6dk5b3iZy6bAEOEGNtN9=OkJOX-Q@mail.gmail.com>
Message-ID: <542C5642-34E5-4F00-8D0D-49DC9EB5F174@oracle.com>

On Jun 28, 2015, at 7:11 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> 2. Opinion for the behavior of the temporary variable.
> His opinion is "Currently the temporary variable can be re-assigned, but it
> doesn't make sense. It should be final.":
> 
> -> 0
> |  Expression value is: 0
> |    assigned to temporary variable $1 of type int
> 
> -> $1 = 10
> |  Variable $1 has been assigned the value 10
> 

I was wondering about that too. So far i have persuaded myself this behaviour is ok since it is not possible to have explicit `final` variables:

  -> final int i = 0
  |  Warning:
  |  Modifier 'final' not permitted in top-level declarations, ignored
  |  final int i = 0;
  |  ^---^
  |  Added variable i of type int with initial value 0


I noticed another potential inconsistency:

  -> "foo"
  |  Expression value is: "foo"
  |    assigned to temporary variable $1 of type String

  -> int x = 1
  |  Added variable x of type int with initial value 1

  -> x
  |  Variable x of type int has value 1

I was expecting x to be assigned to a temporary variable.

Separately, it may not be that hard to support the following gIven the support for assigning the value of an expression to a temporary variable:

  > x = 1
  |  Added variable x of type int with initial value 1

Paul.

From roy.van.rijn at gmail.com  Mon Jun 29 10:23:14 2015
From: roy.van.rijn at gmail.com (Roy van Rijn)
Date: Mon, 29 Jun 2015 12:23:14 +0200
Subject: Issues regarding imports
Message-ID: <CAMJwwmtVK0pRsKe_cR7NuM6b+FK1v6JNe92UhX0=5oNWsM3GHA@mail.gmail.com>

Hey all,

After exploring the JShell a little more I've found one annoyance and
one possible improvement.

If you have an illegal import you'll get an error message. There is
already an issue in the JBS about the formatting of this error
(JDK-8129418), but the thing that bugs me is the following:

==================
-> import unknown.*
| Error:
| package unknown does not exist
| import unknown.*;
| ^

-> System.out.println("Test");
| Error:
| package unknown does not exist
| import unknown.*;
| ^
Test
==================

It keeps repeating the unknown import for each consecutive call. This
looks like a bug to me.

One thing I was wondering about, now that we have code completion,
would it be possible to have automatic imports as well? If I mention a
class that is currently unknown, maybe it could prompt possible
imports? Most of the time there are just a few implementations anyway.
Here is how it *could* work in the JShell:

==================
-> Predicate<Integer> isEven = n -> n%2==0;
Class Predicate not found, did you mean:
1) java.util.function.Predicate
2) javax.sql.rowset.Predicate
3) javax.persistence.criteria.Predicate

1

Class java.util.function.Predicate added as import.
->
==================

Just a suggestion, any thoughts?

Roy

From andrei.eremeev at oracle.com  Mon Jun 29 13:59:43 2015
From: andrei.eremeev at oracle.com (andrei.eremeev at oracle.com)
Date: Mon, 29 Jun 2015 13:59:43 +0000
Subject: hg: kulla/dev/langtools: 8129631: JShell test: Add tests for Key.Kind
Message-ID: <201506291359.t5TDxhVw015666@aojmv0008.oracle.com>

Changeset: 656231599b12
Author:    aeremeev
Date:      2015-06-29 16:58 +0300
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/656231599b12

8129631: JShell test: Add tests for Key.Kind

! test/jdk/jshell/CommandCompletionTest.java
! test/jdk/jshell/CompletenessStressTest.java
! test/jdk/jshell/CompletenessTest.java
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/CustomEditor.java
! test/jdk/jshell/DropTest.java
! test/jdk/jshell/EditorPadTest.java
! test/jdk/jshell/ExceptionsTest.java
! test/jdk/jshell/IOTest.java
! test/jdk/jshell/IgnoreTest.java
! test/jdk/jshell/KullaCompletenessStressTest.java
! test/jdk/jshell/KullaTesting.java
! test/jdk/jshell/MethodsTest.java
! test/jdk/jshell/RejectedFailedTest.java
! test/jdk/jshell/ReplToolTesting.java
! test/jdk/jshell/ReplaceTest.java
! test/jdk/jshell/ShutdownTest.java
! test/jdk/jshell/SimpleRegressionTest.java
! test/jdk/jshell/SnippetTest.java
! test/jdk/jshell/StopExecutionTest.java
! test/jdk/jshell/ToolBasicTest.java
! test/jdk/jshell/VariablesTest.java


From robert.field at oracle.com  Mon Jun 29 15:35:32 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 29 Jun 2015 08:35:32 -0700
Subject: Feedback for the command syntax and the behavior of the temporary
	variable
In-Reply-To: <542C5642-34E5-4F00-8D0D-49DC9EB5F174@oracle.com>
References: <CAHjBcHOU+DqopZ1mNMardz6dk5b3iZy6bAEOEGNtN9=OkJOX-Q@mail.gmail.com>
	<542C5642-34E5-4F00-8D0D-49DC9EB5F174@oracle.com>
Message-ID: <14e3ff57dd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

My perspective is that the temp variables are scratch convenience 
variables, if users want to change them then it is there choice. I can 
easily see why a user might want to, for example, the user writes a method 
referencing a temp variables then realizes they want the temp to have a 
different value. In general, I am resistant to slapping the user's hand for 
what they choose to do unless there is a compelling reason.

Why don't variable reference and assignment expressions generate a temp 
variables:

   x

   x = 1

Because they already have a variable referring to the value.  Adding a temp 
variables would be visual and conceptual noise.  Much the same reason that:

   int x = 1

does not generate a temp variables.

-Robert




On June 29, 2015 12:49:31 AM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Jun 28, 2015, at 7:11 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> > 2. Opinion for the behavior of the temporary variable.
> > His opinion is "Currently the temporary variable can be re-assigned, but it
> > doesn't make sense. It should be final.":
> >
> > -> 0
> > |  Expression value is: 0
> > |    assigned to temporary variable $1 of type int
> >
> > -> $1 = 10
> > |  Variable $1 has been assigned the value 10
> >
>
> I was wondering about that too. So far i have persuaded myself this 
> behaviour is ok since it is not possible to have explicit `final` variables:
>
>   -> final int i = 0
>   |  Warning:
>   |  Modifier 'final' not permitted in top-level declarations, ignored
>   |  final int i = 0;
>   |  ^---^
>   |  Added variable i of type int with initial value 0
>
>
> I noticed another potential inconsistency:
>
>   -> "foo"
>   |  Expression value is: "foo"
>   |    assigned to temporary variable $1 of type String
>
>   -> int x = 1
>   |  Added variable x of type int with initial value 1
>
>   -> x
>   |  Variable x of type int has value 1
>
> I was expecting x to be assigned to a temporary variable.
>
> Separately, it may not be that hard to support the following gIven the 
> support for assigning the value of an expression to a temporary variable:
>
>   > x = 1
>   |  Added variable x of type int with initial value 1
>
> Paul.



From bitterfoxc at gmail.com  Mon Jun 29 16:57:36 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 30 Jun 2015 01:57:36 +0900
Subject: hg: kulla/dev/langtools: Streamification
In-Reply-To: <201506232043.t5NKhjRG003340@aojmv0008.oracle.com>
References: <201506232043.t5NKhjRG003340@aojmv0008.oracle.com>
Message-ID: <CAHjBcHPPnbCgqvyT_KZvtphOoJWnLDWXshQJe9LwBkS-y34_UA@mail.gmail.com>

Hi Robert and Brian,
I have the streamified code for SourceCodeAnalysisImpl.
Could you review this?

webrev:
http://cr.openjdk.java.net/~shinyafox/kulla/streamification.00/webrev.00/

Regards,
shinyafox(Shinya Yoshida)


2015-06-24 5:43 GMT+09:00 <robert.field at oracle.com>:

> Changeset: 06f3585a609b
> Author:    rfield
> Date:      2015-06-23 13:43 -0700
> URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/06f3585a609b
>
> Streamification
> Contributed-by: brian.goetz at oracle.com
>
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyMap.java
> !
> src/jdk.jshell/share/classes/jdk/internal/jshell/impl/MaskCommentsAndModifiers.java
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetMaps.java
> ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/TaskFactory.java
>
>

From brian.goetz at oracle.com  Mon Jun 29 17:43:28 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Jun 2015 13:43:28 -0400
Subject: UI review: jshell commands
Message-ID: <559183C0.3040200@oracle.com>

Going over the / commands in jshell.

1.  Are we sure /help is complete?  I have not been able to determine it 
is not, but we should review that it is (ideally, deriving the /help 
text and the / command parsing from the same data structures.)

2.  I recommend we drop the one-letter shortcuts, for several reasons:

  - Such tricks always cause evolution problems.  One day, we'll add a 
new command whose first letter conflicts with that of an existing 
command, and which arguably has a superior claim to that short form.

  - Tab-completion works against / commands.  So users looking to save 
keystrokes can use tab completion; the one-letter version now saves only 
the tab keystroke.

  - The commands are not that frequently typed, compared to evaluating 
expressions.  So the extra keystroke savings (especially given tab 
completion) are not worth it.

In short, I don't think they pull their weight.

3.  I don't think we ever came to consensus on /edit.  Right now, the 
popup editor says "experimental"; did we declare success or failure on 
this experiment?  I thought we were leaning towards dropping it.

4.  The /list behavior is a little confusing until you understand it. 
Perhaps the display should include a one-line header to the effect of "n 
implicit entries, type /list all to see", so that users won't be 
confused as to why the first entry is 9 and not 1.

5.  /drop name.  For most droppable things, "name" is a nice shortcut, 
and the interactive message we get when a method is overloaded is a fine 
compromise (rather than making the syntax more complicated.)  But, it 
may not be obvious the first time that the user is supposed to type 
"/drop 12" when presented with a list of candidate IDs.  The 
disambiguation text could guide the user to this a little better.

6.  /drop import.  I am not sure how to drop an import, but there needs 
to be a way to do this (otherwise, a mistaken import taints the 
session.)  I tried /drop id with the import id, and didn't get an error 
message, but it didn't have the effect of dropping the import, either.

7.  /open.  If I enter some expressions (e.g., 1+1), /save it, and then 
/open that, I don't see the expressions being printed as they are being 
re-evaluated.  I realize that /open is mostly for pulling in canned 
declarations, but I found the lack of printing out any notifications 
confusing.

8.  /methods.  I was a little surprised that I didn't get the sources 
for methods I'd typed in.  Perhaps an option on /methods to get the 
source too?  Ditto for classes.  (Also, /classes lists the names but not 
the generic type variables, which is part of the signature -- so I get 
signatures for methods but not for classes.)

9.  /reset.  Should mention that it re-reads the startup file, so the 
state is reset to the as-started state, not the "empty" state.

10.  /prompt.  If we're going to support customization of the prompt, 
then we should allow the user to select a prompt with "/prompt repl> "

11.  /classpath.  No way to *list* the class path or to *remove* an 
entry from the class path.

12.  I like the /n, /-n, and /! commands.  We had discussed aligning the 
temporary variable numbers with snippet id's, so an expression snippet 
whose id is 33 would assign to temporary $33.  The only weirdness with 
this is that people would be initially confused that the first temporary 
var is $9 and not $1, since we treat the startup commands as if they 
were input by the user.



From jan.lahoda at oracle.com  Mon Jun 29 18:18:44 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 29 Jun 2015 20:18:44 +0200
Subject: UI review: jshell commands
In-Reply-To: <559183C0.3040200@oracle.com>
References: <559183C0.3040200@oracle.com>
Message-ID: <55918C04.5060003@oracle.com>

On 29.6.2015 19:43, Brian Goetz wrote:
> Going over the / commands in jshell.
>
> 1.  Are we sure /help is complete?  I have not been able to determine it
> is not, but we should review that it is (ideally, deriving the /help
> text and the / command parsing from the same data structures.)

The commands are stored in JShellTool.commands map, and all of 
processing, help and completion use that map. So these should be 
consistent. One exception is the /<n> and /-<n> commands - these are 
processed separately (but still have an entry in the commands map, to 
get help). Another exception is the /debug command which is hidden from 
help and completion. For all other commands, all the features should be 
using the commands map.

Jan

>
> 2.  I recommend we drop the one-letter shortcuts, for several reasons:
>
>   - Such tricks always cause evolution problems.  One day, we'll add a
> new command whose first letter conflicts with that of an existing
> command, and which arguably has a superior claim to that short form.
>
>   - Tab-completion works against / commands.  So users looking to save
> keystrokes can use tab completion; the one-letter version now saves only
> the tab keystroke.
>
>   - The commands are not that frequently typed, compared to evaluating
> expressions.  So the extra keystroke savings (especially given tab
> completion) are not worth it.
>
> In short, I don't think they pull their weight.
>
> 3.  I don't think we ever came to consensus on /edit.  Right now, the
> popup editor says "experimental"; did we declare success or failure on
> this experiment?  I thought we were leaning towards dropping it.
>
> 4.  The /list behavior is a little confusing until you understand it.
> Perhaps the display should include a one-line header to the effect of "n
> implicit entries, type /list all to see", so that users won't be
> confused as to why the first entry is 9 and not 1.
>
> 5.  /drop name.  For most droppable things, "name" is a nice shortcut,
> and the interactive message we get when a method is overloaded is a fine
> compromise (rather than making the syntax more complicated.)  But, it
> may not be obvious the first time that the user is supposed to type
> "/drop 12" when presented with a list of candidate IDs.  The
> disambiguation text could guide the user to this a little better.
>
> 6.  /drop import.  I am not sure how to drop an import, but there needs
> to be a way to do this (otherwise, a mistaken import taints the
> session.)  I tried /drop id with the import id, and didn't get an error
> message, but it didn't have the effect of dropping the import, either.
>
> 7.  /open.  If I enter some expressions (e.g., 1+1), /save it, and then
> /open that, I don't see the expressions being printed as they are being
> re-evaluated.  I realize that /open is mostly for pulling in canned
> declarations, but I found the lack of printing out any notifications
> confusing.
>
> 8.  /methods.  I was a little surprised that I didn't get the sources
> for methods I'd typed in.  Perhaps an option on /methods to get the
> source too?  Ditto for classes.  (Also, /classes lists the names but not
> the generic type variables, which is part of the signature -- so I get
> signatures for methods but not for classes.)
>
> 9.  /reset.  Should mention that it re-reads the startup file, so the
> state is reset to the as-started state, not the "empty" state.
>
> 10.  /prompt.  If we're going to support customization of the prompt,
> then we should allow the user to select a prompt with "/prompt repl> "
>
> 11.  /classpath.  No way to *list* the class path or to *remove* an
> entry from the class path.
>
> 12.  I like the /n, /-n, and /! commands.  We had discussed aligning the
> temporary variable numbers with snippet id's, so an expression snippet
> whose id is 33 would assign to temporary $33.  The only weirdness with
> this is that people would be initially confused that the first temporary
> var is $9 and not $1, since we treat the startup commands as if they
> were input by the user.
>
>

From robert.field at oracle.com  Mon Jun 29 18:40:29 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 29 Jun 2015 11:40:29 -0700
Subject: UI review: jshell commands
In-Reply-To: <559183C0.3040200@oracle.com>
References: <559183C0.3040200@oracle.com>
Message-ID: <32B614C3-72BA-490F-B2E5-94E32D3AB401@oracle.com>


> On Jun 29, 2015, at 10:43 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Going over the / commands in jshell.
> 
> 1.  Are we sure /help is complete?  I have not been able to determine it is not, but we should review that it is (ideally, deriving the /help text and the / command parsing from the same data structures.)

That is exactly how it works ? Jan designed a very nice mechanism that is used for this.  

> 
> 2.  I recommend we drop the one-letter shortcuts, for several reasons:
> 
> - Such tricks always cause evolution problems.  One day, we'll add a new command whose first letter conflicts with that of an existing command, and which arguably has a superior claim to that short form.
> 
> - Tab-completion works against / commands.  So users looking to save keystrokes can use tab completion; the one-letter version now saves only the tab keystroke.
> 
> - The commands are not that frequently typed, compared to evaluating expressions.  So the extra keystroke savings (especially given tab completion) are not worth it.
> 
> In short, I don't think they pull their weight.

Makes sense
And I use the shortcuts ? well, a few of them.
Would love other?s thoughts.

> 
> 3.  I don't think we ever came to consensus on /edit.  Right now, the popup editor says "experimental"; did we declare success or failure on this experiment?  I thought we were leaning towards dropping it.

Right, no closure on the default simple window.
Other?s thoughts?

> 
> 4.  The /list behavior is a little confusing until you understand it. Perhaps the display should include a one-line header to the effect of "n implicit entries, type /list all to see", so that users won't be confused as to why the first entry is 9 and not 1.

We could, but that seems noisy ? though I guess it would only be in default feedback mode (but the thinking is that is where most people will live).  
I?ve been thinking that the welcome message, instead of advertising /help, would suggest a /intro ? which would give a pocket intro including discussing /help, would talk about anything surprising, like this, and describe setting feedback mode, and how to save start-up definitions/commands.

> 
> 5.  /drop name.  For most droppable things, "name" is a nice shortcut, and the interactive message we get when a method is overloaded is a fine compromise (rather than making the syntax more complicated.)  But, it may not be obvious the first time that the user is supposed to type "/drop 12" when presented with a list of candidate IDs.  The disambiguation text could guide the user to this a little better.

OK

> 
> 6.  /drop import.  I am not sure how to drop an import, but there needs to be a way to do this (otherwise, a mistaken import taints the session.)  I tried /drop id with the import id, and didn't get an error message, but it didn't have the effect of dropping the import, either.

Yep, known bug: JDK-8081431 <https://bugs.openjdk.java.net/browse/JDK-8081431>

> 
> 7.  /open.  If I enter some expressions (e.g., 1+1), /save it, and then /open that, I don't see the expressions being printed as they are being re-evaluated.  I realize that /open is mostly for pulling in canned declarations, but I found the lack of printing out any notifications confusing.

Hmmm, this interacts with the ongoing level of feedback question, but depending on what you are opening this could be very noisy.

> 
> 8.  /methods.  I was a little surprised that I didn't get the sources for methods I'd typed in.  Perhaps an option on /methods to get the source too?  Ditto for classes.  (Also, /classes lists the names but not the generic type variables, which is part of the signature -- so I get signatures for methods but not for classes.)

I saw these as a "what do I have" kind of query not a version of /list.  Maybe "/list methods" 
???

> 
> 9.  /reset.  Should mention that it re-reads the startup file, so the state is reset to the as-started state, not the "empty" state.

OK.

> 
> 10.  /prompt.  If we're going to support customization of the prompt, then we should allow the user to select a prompt with "/prompt repl> ?

Fair enough

> 
> 11.  /classpath.  No way to *list* the class path or to *remove* an entry from the class path.

JDK-8129539 <https://bugs.openjdk.java.net/browse/JDK-8129539>

Added a comment that we also need list functionality

> 
> 12.  I like the /n, /-n, and /! commands.  We had discussed aligning the temporary variable numbers with snippet id's, so an expression snippet whose id is 33 would assign to temporary $33.  The only weirdness with this is that people would be initially confused that the first temporary var is $9 and not $1, since we treat the startup commands as if they were input by the user.

I still think that is a good idea.  There are a few other little curly bits:  the user has defined a variable $2 we skip id 2, do we still define variables for snippets with no value, if so, what type?  A snippet matching an existing snippet signature keeps the same Key and thus id, but then it should use the same temp variable and, oops, the type may have changed. ?

-Robert

> 
> 


From brian.goetz at oracle.com  Mon Jun 29 18:48:40 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Jun 2015 14:48:40 -0400
Subject: Issues regarding imports
In-Reply-To: <CAMJwwmtVK0pRsKe_cR7NuM6b+FK1v6JNe92UhX0=5oNWsM3GHA@mail.gmail.com>
References: <CAMJwwmtVK0pRsKe_cR7NuM6b+FK1v6JNe92UhX0=5oNWsM3GHA@mail.gmail.com>
Message-ID: <55919308.7050207@oracle.com>

There definitely needs to be a way to /drop an ill-considered import 
directive; otherwise your session is tainted.

The continued re-processing of a bogus import is probably a bug.

I don't like the idea of a deliberately modal interaction like this (it 
would play havoc, for example, when you pipe in input), but I like the 
idea of the hints.  Maybe it could create some temporary context:

   repl> Predicate<Integer> p;
   | Class Predicate not found, but I have some suggestions:
     Type /accept 1 for java.util.function.Predicate
     Type /accept 2 for javax.sql.rowset.Predicate

   repl>

and then the user could either accept the advice, or move on, but not 
get stuck in a modal interaction that they don't know how to get out of.

On 6/29/2015 6:23 AM, Roy van Rijn wrote:
> Hey all,
>
> After exploring the JShell a little more I've found one annoyance and
> one possible improvement.
>
> If you have an illegal import you'll get an error message. There is
> already an issue in the JBS about the formatting of this error
> (JDK-8129418), but the thing that bugs me is the following:
>
> ==================
> -> import unknown.*
> | Error:
> | package unknown does not exist
> | import unknown.*;
> | ^
>
> -> System.out.println("Test");
> | Error:
> | package unknown does not exist
> | import unknown.*;
> | ^
> Test
> ==================
>
> It keeps repeating the unknown import for each consecutive call. This
> looks like a bug to me.
>
> One thing I was wondering about, now that we have code completion,
> would it be possible to have automatic imports as well? If I mention a
> class that is currently unknown, maybe it could prompt possible
> imports? Most of the time there are just a few implementations anyway.
> Here is how it *could* work in the JShell:
>
> ==================
> -> Predicate<Integer> isEven = n -> n%2==0;
> Class Predicate not found, did you mean:
> 1) java.util.function.Predicate
> 2) javax.sql.rowset.Predicate
> 3) javax.persistence.criteria.Predicate
>
> 1
>
> Class java.util.function.Predicate added as import.
> ->
> ==================
>
> Just a suggestion, any thoughts?
>
> Roy
>

From brian.goetz at oracle.com  Mon Jun 29 18:49:17 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Jun 2015 14:49:17 -0400
Subject: Feedback for the command syntax and the behavior of the temporary
	variable
In-Reply-To: <14e3ff57dd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAHjBcHOU+DqopZ1mNMardz6dk5b3iZy6bAEOEGNtN9=OkJOX-Q@mail.gmail.com>	<542C5642-34E5-4F00-8D0D-49DC9EB5F174@oracle.com>
	<14e3ff57dd0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <5591932D.6090900@oracle.com>

Agreed.

On 6/29/2015 11:35 AM, Robert Field wrote:
> My perspective is that the temp variables are scratch convenience
> variables, if users want to change them then it is there choice. I can
> easily see why a user might want to, for example, the user writes a
> method referencing a temp variables then realizes they want the temp to
> have a different value. In general, I am resistant to slapping the
> user's hand for what they choose to do unless there is a compelling reason.
>
> Why don't variable reference and assignment expressions generate a temp
> variables:
>
>    x
>
>    x = 1
>
> Because they already have a variable referring to the value.  Adding a
> temp variables would be visual and conceptual noise.  Much the same
> reason that:
>
>    int x = 1
>
> does not generate a temp variables.
>
> -Robert
>
>
>
>
> On June 29, 2015 12:49:31 AM Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> On Jun 28, 2015, at 7:11 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>> > 2. Opinion for the behavior of the temporary variable.
>> > His opinion is "Currently the temporary variable can be re-assigned,
>> but it
>> > doesn't make sense. It should be final.":
>> >
>> > -> 0
>> > |  Expression value is: 0
>> > |    assigned to temporary variable $1 of type int
>> >
>> > -> $1 = 10
>> > |  Variable $1 has been assigned the value 10
>> >
>>
>> I was wondering about that too. So far i have persuaded myself this
>> behaviour is ok since it is not possible to have explicit `final`
>> variables:
>>
>>   -> final int i = 0
>>   |  Warning:
>>   |  Modifier 'final' not permitted in top-level declarations, ignored
>>   |  final int i = 0;
>>   |  ^---^
>>   |  Added variable i of type int with initial value 0
>>
>>
>> I noticed another potential inconsistency:
>>
>>   -> "foo"
>>   |  Expression value is: "foo"
>>   |    assigned to temporary variable $1 of type String
>>
>>   -> int x = 1
>>   |  Added variable x of type int with initial value 1
>>
>>   -> x
>>   |  Variable x of type int has value 1
>>
>> I was expecting x to be assigned to a temporary variable.
>>
>> Separately, it may not be that hard to support the following gIven the
>> support for assigning the value of an expression to a temporary variable:
>>
>>   > x = 1
>>   |  Added variable x of type int with initial value 1
>>
>> Paul.
>
>

From brian.goetz at oracle.com  Mon Jun 29 19:04:50 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Jun 2015 15:04:50 -0400
Subject: hg: kulla/dev/langtools: Streamification
In-Reply-To: <CAHjBcHPPnbCgqvyT_KZvtphOoJWnLDWXshQJe9LwBkS-y34_UA@mail.gmail.com>
References: <201506232043.t5NKhjRG003340@aojmv0008.oracle.com>
	<CAHjBcHPPnbCgqvyT_KZvtphOoJWnLDWXshQJe9LwBkS-y34_UA@mail.gmail.com>
Message-ID: <559196D2.6050403@oracle.com>

Reviewed.  +1.


On 6/29/2015 12:57 PM, ShinyaYoshida wrote:
> Hi Robert and Brian,
> I have the streamified code for SourceCodeAnalysisImpl.
> Could you review this?
>
> webrev:
> http://cr.openjdk.java.net/~shinyafox/kulla/streamification.00/webrev.00/
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
> 2015-06-24 5:43 GMT+09:00 <robert.field at oracle.com
> <mailto:robert.field at oracle.com>>:
>
>     Changeset: 06f3585a609b
>     Author:    rfield
>     Date:      2015-06-23 13:43 -0700
>     URL: http://hg.openjdk.java.net/kulla/dev/langtools/rev/06f3585a609b
>
>     Streamification
>     Contributed-by: brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>
>     ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/Eval.java
>     ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/JShellImpl.java
>     ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/KeyMap.java
>     !
>     src/jdk.jshell/share/classes/jdk/internal/jshell/impl/MaskCommentsAndModifiers.java
>     ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/SnippetMaps.java
>     ! src/jdk.jshell/share/classes/jdk/internal/jshell/impl/TaskFactory.java
>
>

From brian.goetz at oracle.com  Mon Jun 29 19:21:27 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Jun 2015 15:21:27 -0400
Subject: UI review: jshell commands
In-Reply-To: <32B614C3-72BA-490F-B2E5-94E32D3AB401@oracle.com>
References: <559183C0.3040200@oracle.com>
	<32B614C3-72BA-490F-B2E5-94E32D3AB401@oracle.com>
Message-ID: <55919AB7.3050708@oracle.com>

>> 4.  The /list behavior is a little confusing until you understand it.
>> Perhaps the display should include a one-line header to the effect of
>> "n implicit entries, type /list all to see", so that users won't be
>> confused as to why the first entry is 9 and not 1.
>
> We could, but that seems noisy ? though I guess it would only be in
> default feedback mode (but the thinking is that is where most people
> will live).

Something like:

repl> /list

     [8 implicit entries, type /list all to see]
     9: int a = 1
     10: int b = 2
     11: a + b

This doesn't seem unreasonably noisy?  Is there a less noisy way to get 
people to realize that there *are* implicit entries?  Or just make /list 
all the default, maybe with some indication they are implicit:

repl> /list

     1: [ import java.util.* ]
     2: [ more implicit entries ]
     ...
     9: int a = 1
     10: int b = 2
     11: a + b

My concern is that I want the user to quickly internalize that a) there 
*is* a startup file, and b) that things read from the startup file are 
handled "as if" the user typed them.  Once you know these things, its 
not surprising, but until you do, it is.  How can we help the user get here?

> I?ve been thinking that the welcome message, instead of advertising
> /help, would suggest a /intro ? which would give a pocket intro
> including discussing /help, would talk about anything surprising, like
> this, and describe setting feedback mode, and how to save start-up
> definitions/commands.

Seems like a good idea.  (Whatever text it displays should also be 
available some other way, such as a "getting started" doc; no point in 
duplicating intro text between the program and the documentation.)

>> 7.  /open.  If I enter some expressions (e.g., 1+1), /save it, and
>> then /open that, I don't see the expressions being printed as they are
>> being re-evaluated.  I realize that /open is mostly for pulling in
>> canned declarations, but I found the lack of printing out any
>> notifications confusing.
>
> Hmmm, this interacts with the ongoing level of feedback question, but
> depending on what you are opening this could be very noisy.

Could be.  I was just a little surprised to see nothing.

>> 12.  I like the /n, /-n, and /! commands.  We had discussed aligning
>> the temporary variable numbers with snippet id's, so an expression
>> snippet whose id is 33 would assign to temporary $33.  The only
>> weirdness with this is that people would be initially confused that
>> the first temporary var is $9 and not $1, since we treat the startup
>> commands as if they were input by the user.

Which is more of the "help them to internalize the model quickly."

> I still think that is a good idea.  There are a few other little curly
> bits:  the user has defined a variable $2 we skip id 2, do we still
> define variables for snippets with no value, if so, what type?  A
> snippet matching an existing snippet signature keeps the same Key and
> thus id, but then it should use the same temp variable and, oops, the
> type may have changed. ?

I think we should only define a temp for a snippet that is a non-void 
expression.  If the user has defined $2, we can step on it; the 
side-effect message could even reflect this:

(overwrote existing variable $2 with new temporary variable of type int)

instead of

(created temporary variable $2 of type int)

It's very much a corner case, and users who are attracted to that corner 
will quickly learn to not define temps whose name matches $nnn.


From john.r.rose at oracle.com  Mon Jun 29 21:37:37 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 29 Jun 2015 14:37:37 -0700
Subject: UI review: jshell commands
In-Reply-To: <55919AB7.3050708@oracle.com>
References: <559183C0.3040200@oracle.com>
	<32B614C3-72BA-490F-B2E5-94E32D3AB401@oracle.com>
	<55919AB7.3050708@oracle.com>
Message-ID: <95BDD3FA-060E-4B97-A2BF-F58F1B6C5C66@oracle.com>

On Jun 29, 2015, at 12:21 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I want the user to quickly internalize that a) there *is* a startup file, and b) that things read from the startup file are handled "as if" the user typed them.

Perhaps I'm missing the point of this "as if" rule, but to me it seems like more of a recurrent pitfall than a help.

Auto-generated names like $1 are not useful when imported from another scope (like a startup file); they are only useful interactively.

If the creator of the startup file wants to export names, it is trivial to edit them in, and easier to ensure that the user will know how to name them interactively:

// startup starts here
int theHostId = getHostId();
// end of startup

1+1;
$1 = 2
theHostid;
$2 = 42

Otherwise, the intermediate results of the startup file should be dropped.  Or at least they should not interfere with the auto-generated names for interactive results.

Two compromises possible on that:

1. If for some reason we must, auto-generate a different set of names for the startup file, starting with $_ (think, "negative") or $0:

1+1;
$1 = 2;
$_1;  // host id from startup, etc.

2. If you buy my argument that auto-generated things are usually useless, have an opt-in argument for those special times when you need auto-numbering of the file.  Replaying a previous interactive input is really a different use case from reusing a common profile.

Such a special time would be replaying scripts, but I can't think of any other.  Perhaps that is envisioned as the default.  In that case, we should be sure that it in the *other default*, when pulling from a startup file like ~/.kullarc, it should be easy to suppress the creation of $N variables.

? John

From brian.goetz at oracle.com  Tue Jun 30 00:02:29 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Jun 2015 20:02:29 -0400
Subject: UI review: jshell commands
In-Reply-To: <95BDD3FA-060E-4B97-A2BF-F58F1B6C5C66@oracle.com>
References: <559183C0.3040200@oracle.com>
	<32B614C3-72BA-490F-B2E5-94E32D3AB401@oracle.com>
	<55919AB7.3050708@oracle.com>
	<95BDD3FA-060E-4B97-A2BF-F58F1B6C5C66@oracle.com>
Message-ID: <5591DC95.4050709@oracle.com>

Now that you have whacked us over the head with "hey, you guys are 
looking in the wrong direction", I tend to agree.  In fact, that the 
elements of /list show up starting with 9 is also weird.

So, how about reflecting this more directly; have the "startup IDs" 
start at something like auto.1 or startup.1, and then flip over to 1 
when we finish with startup.  Then /list would start with 1; /list all 
would look like:

   auto.1: import ...
   auto.2: import
   1: 1 + 1

The only important reason that we even need an ID for the startup 
entries is so we can /drop it.  Having an ID of the form "auto.1" works 
fine for that.  There's no reason ID has to be an int, is there?

> Otherwise, the intermediate results of the startup file should be
> dropped.  Or at least they should not interfere with the auto-generated
> names for interactive results.
>
> Two compromises possible on that:
>
> 1. If for some reason we must, auto-generate a different set of names
> for the startup file, starting with $_ (think, "negative") or $0:
>
> 1+1;
> $1 = 2;
> $_1;  // host id from startup, etc.
>
> 2. If you buy my argument that auto-generated things are usually
> useless, have an opt-in argument for those special times when you need
> auto-numbering of the file.  Replaying a previous interactive input is
> really a different use case from reusing a common profile.
>
> Such a special time would be replaying scripts, but I can't think of any
> other.  Perhaps that is envisioned as the default.  In that case, we
> should be sure that it in the *other default*, when pulling from a
> startup file like ~/.kullarc, it should be easy to suppress the creation
> of $N variables.
>
> ? John

From joe.darcy at oracle.com  Tue Jun 30 00:43:57 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 29 Jun 2015 17:43:57 -0700
Subject: Kulla: Please review JShell API
In-Reply-To: <558C5B73.7020708@oracle.com>
References: <558C5B73.7020708@oracle.com>
Message-ID: <5591E64D.3030004@oracle.com>

Hi Robert,

A few quick comments.

The sources files in the API don't seem to have been compiled with the 
doclint as there seem to be missing javadoc on various methods, etc. 
Please run with

      -Xlint:all -Xdoclint:all/protected

and see what sort of warnings are produced. (Some of the exception types 
might also be missing serialVersionUID fields.)

There doesn't seem to be a package-info.java file for the new package.

Some of the types reference particular sections of "The Java Language 
Specification." In the JDK sources, we use the @jls tag for that 
purpose. There are example uses of the tag in the java.lang package.

The use of fields rather than methods in KeyStatusEvent is not advised.

HTH,

-Joe

On 6/25/2015 12:50 PM, Robert Field wrote:
> Please review the API.  The javadocs can be found here:
>
>     http://cr.openjdk.java.net/~rfield/doc
>
> Sources (as always) are here:
>
>     http://hg.openjdk.java.net/kulla/dev
>
> All comments welcome.
>
> Thanks,
> Robert
>


From jan.lahoda at oracle.com  Tue Jun 30 15:08:22 2015
From: jan.lahoda at oracle.com (jan.lahoda at oracle.com)
Date: Tue, 30 Jun 2015 15:08:22 +0000
Subject: hg: kulla/dev/langtools: 8129944: JShell tool: Ctrl+C should remove
	typed incomplete text
Message-ID: <201506301508.t5UF8N4B019150@aojmv0008.oracle.com>

Changeset: 5e4411bdb04d
Author:    jlahoda
Date:      2015-06-30 17:07 +0200
URL:       http://hg.openjdk.java.net/kulla/dev/langtools/rev/5e4411bdb04d

8129944: JShell tool: Ctrl+C should remove typed incomplete text

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java


From paul.sandoz at oracle.com  Tue Jun 30 16:45:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Jun 2015 18:45:47 +0200
Subject: Initial and partial high-level REPL API review
Message-ID: <C6F875B4-1058-48B8-87E7-3DDB6F2C60EB@oracle.com>

Hi,

I am not diving too much into the current JavaDoc at the moment. Looking more at higher level things and relationships between types. Expect some naive questions :-) In no particular order below...

Paul.


Concurrency
--
It's not clear to me what if any methods on JShell are thread safe, except for JShell.stop. I see certain methods on JShellImpl are marked synchronized, implying there is potentially some concurrent activity.

Can callback notifications occur on a different thread that registered the listener? same for unsubscribing a listener.


Naming
--
It's bike shed time! :-)

When i looked at the JavaDoc i could see many "Key" thingies. I had no idea what they could be at first glance, as it's such a generic name. When dug just a little deeper it became clear they are references to snippets of code. Why not call it CodeSnippet?

  CodeSnippet
  CodeSnippet.Declaration
  CodeSnippet.Erroneous
  CodeSnippet.Import
  etc.

  KeyStatusEvent -> CodeSnippetEvent

There seems no need to add CodeSnippet to the end of each nested sub-type, since one can use the root type as the namespace.

JShell.SubscriptionToken -> JShell.Subscription ?


Interfaces vs. Abstract classes
--

The current design is that one obtains a code snippet or subscription from the shell and then one goes back to the shell to operate on that snippet or subscription.  This means the developer might need to guard against an IllegalArgumentException under two conditions: 1) The snippet or subscription was created by something foreign; or 2) was created by another JShell instance.

For code snippets can their be a hierarchy of abstract classes, each with a package private constructor. AFAICT i think that would currently work. Would this box us in if new code snippets are added in the future?

Particular code snippets can have methods associated with the operations, for example:

  - All code snippets would have the source, status, diagnostics and subKind operations
  - The variable declaration code snippet would have the varValue operation

It would then be marginally easier to operate on snippets in bulk, rather than having to go back to corresponding JShell instance. For example, then one could do:

  JShell js = ..

  Stream< VariableDeclKey > variables = js.keys().stream()
      .filter(k -> k.status().tracksUpdates)
      .filter(k -> k.kind() == Key.Kind.VARIABLE)
      .map(k -> (VariableDeclKey)k);

with no need to refer or capture "js". The stream is entirely self-contained.

The same patterns can apply to a subscription. A subscription could be an abstract class and have the unsubscribe operation.


JShell construction
--

There is one creation method:

  public static JShell create(InputStream in, PrintStream out, PrintStream err)

But i dunno what it does with "in", "out, or "err". If i wanted to write my own jshell tool how would i use this to trigger reading from "in"?

I think this points to the general question of how can i write my own equivalent of jshell using this API?

I am guessing i would use the source code analysis functionality to determine if a code snippet string is complete and when so pass that string to JShell.eval. Correct? If so and if possible concisely it might be useful to have a simple and dumb example in the JavaDoc, which might also be a useful exercise (say at a more advanced hackathon).


JShell use-cases
--

I think the primary use-case so far for this API is to support jshell-like tools. Another good use-case is actual testing without having to open up the box.

There may be other use-cases, more specifically that don't require redefinition. For example, could we implement a Java scripting provider? It seems possible but i think the API is lacking a way to hook up runtime state to a JShell instance. The only way to hook up state is to load up a JShell via evaluations. So it's kind of a closed world mechanism, fine for the jshell tool, but perhaps for other use-cases not so if we deem them important.

It seems a viable use-case to me. For example, take the Jenkins continuous build application/system. It has the ability to to declare Groovy scripts and execute then server-side (i believe this is also the glue for the workflow plugin). Those groovy scripts require some context to the Jenkins instance. How could we hook up the JShell functionality to achieve a similar approach with Java?

Other use-cases might be IDEs. One obvious use-case is to evaluate in place in an editor window. Another use-case might be for evaluating expressions when debugging. I think these will require more input from the IDE vendors/developers.


Code snippets
--

Status events
-

What are the constraints for "previousStatus" and "status". I presume "previousStatus" can be of all Key.Status values, including NONEXISTENT, where as "status" can be anything but NONEXISTENT?

If "isSignatureChange" is true does that mean "key" is an instance of DeclarationKey?

If "isSignatureChange" is true is there a way to obtain the old signature?

Is there any meaningful relationship between the types of causeKey and key?


Kinds and SubKinds:
-

Is there actually a state machine for transitions of sub-kinds a key can undergo? I suspect there might be. Perhaps that is something that could be expressed as a table in the documentation? That might help get the bigger picture.


Evaluation
--

It took me a few iterations to realize the jshell command tool adds ';' where needed (e.g. variable declarations) where as the JShell.eval requires them. AFAICT there were no errors reported, just Status.REJECTED_FAILED.

Lesson learned: one should first analyze with SourceCodeAnalysis.analyzeCompletion to obtain Completeness.COMPLETE_WITH_SEMI.


Source code analysis
--

It's likely SourceCodeAnalysis.analyzeCompletion will need to be called in a loop e.g.:

String expressions = "int x = 1; int y = 2; System.out.printf(\"Output: %s %d%n\", x, y);";

SourceCodeAnalysis sca = js.sourceCodeAnalysis();
for (;;) {
    SourceCodeAnalysis.CompletionInfo ci = sca.analyzeCompletion(expressions);
    if (ci.completeness != SourceCodeAnalysis.Completeness.COMPLETE)
        break;

    String expression = ci.source;
    List<KeyStatusEvent> eval = js.eval(expression);
    eval.forEach(e -> {
       System.out.println(e.key);
        System.out.println(e.value);

    });

    expressions = ci.remaining;
}

I don't have any concrete suggestions at the moment but it feels (gut feeling) this experience could be improved. Need to play with it a little more.

Is there some non-string intermediate form produced from the source code analysis that could be passed to the evaluation for more efficient processing?



From brian.goetz at oracle.com  Tue Jun 30 17:00:44 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 30 Jun 2015 13:00:44 -0400
Subject: Initial and partial high-level REPL API review
In-Reply-To: <C6F875B4-1058-48B8-87E7-3DDB6F2C60EB@oracle.com>
References: <C6F875B4-1058-48B8-87E7-3DDB6F2C60EB@oracle.com>
Message-ID: <5592CB3C.1080303@oracle.com>

> When i looked at the JavaDoc i could see many "Key" thingies. I had no idea what they could be at first glance, as it's such a generic name. When dug just a little deeper it became clear they are references to snippets of code. Why not call it CodeSnippet?
>
>    CodeSnippet

Heh, full circle.  This was originally called Snippet, but the Snippet 
abstraction at the time was a big sprawling monster (and took a lot to 
understand, so calling it Snippet wasn't so helpful either).  The Key 
abstraction was intended to indicate that this is just the immutable 
access point for a code snippet, where most of the state lives behind 
the Repl API.  But, Key is indeed very generic; SnippetKey seems a fair 
compromise as it is more specific and captures it's "remote handle" 
nature.