Bugs

[Jan Lahoda]

Hi Andrei,

Could you please be more specific - what should I do to see the problem with user classes? I tried to add a jar to the classpath using the "-classpath" command line option and using the "/cp" command, and the completion was completing the packages from the jars.

For "new", there was a bug that packages were not listed after new, should be fixed now. Thanks for pointing that out.

Thanks,
    Jan

----- Original Message -----
From: andrei.eremeev at oracle.com
To: jan.lahoda at oracle.com, robert.field at oracle.com, kulla-dev at openjdk.java.net
Sent: Monday, March 16, 2015 1:24:08 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: Bugs

Yes, completion works for imports currently. But what about user defined 
classes in classpath?
Let pkg.A be a user defined class. Completion does not work for both 
import statements and expression statements.

 > import pk|
 > new pk|

Andrei Eremeev

On 03/16/2015 03:16 PM, Jan Lahoda wrote:
> On 15.3.2015 20:29, Robert Field wrote:
>> That seems fine.
>
> Thanks, completion for imports should work better now.
>
> Jan
>
>> It also suggests there might be ways for us to optimize the number of
>> compiler tasks used.
>>
>> Thanks,
>> Robert
>>
>>
>>
>> On March 15, 2015 11:22:13 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>>> On 13.3.2015 19:06, Robert Field wrote:
>>> >
>>> > On 03/13/15 08:22, andrei.eremeev wrote:
>>> >> Hi REPL team,
>>> >>
>>> >> Found bugs:
>>> >>
>>> >> 1. In completion analysis possible packages are not suggested. 
>>> "import
>>> >> java.ut|".
>>> >
>>> > Jan?
>>>
>>> Two problems here (thanks for report!):
>>> -the completion did not complete packages in any context. Should be
>>> fixed now (is a little bit tricky, as it is not easy to get the list of
>>> packages, so completion is listing classes using the JavaFileManager).
>>> -completion misbehaving for imports in some cases (in particular for
>>> import static). To fix this, I'd like to change the way AnalyzeTask 
>>> sets
>>> AnalyzeTask.cut like this:
>>> diff -r c9b090dded9b repl/src/impl/TaskFactory.java
>>> --- a/repl/src/impl/TaskFactory.java    Sun Mar 15 17:10:33 2015 +0100
>>> +++ b/repl/src/impl/TaskFactory.java    Sun Mar 15 19:16:09 2015 +0100
>>> @@ -130,11 +130,9 @@
>>>
>>>           AnalyzeTask(OuterWrap wrap, String... extraOptions) {
>>>               super(wrap, extraOptions);
>>> -            Iterator<? extends Element> eit = analyze().iterator();
>>> -            if (eit.hasNext()) {
>>> -                Element e = eit.next();
>>> -                TreePath cutp = trees().getPath(e);
>>> -                this.cut = cutp.getCompilationUnit();
>>> +            Iterator<? extends CompilationUnitTree> cuts =
>>> analyze().iterator();
>>> +            if (cuts.hasNext()) {
>>> +                this.cut = cuts.next();
>>>                   //proc.debug("AnalyzeTask element=%s cutp=%s
>>> cut=%s\n", e, cutp, cut);
>>>               } else {
>>>                   this.cut = null;
>>> @@ -142,9 +140,11 @@
>>>               }
>>>           }
>>>
>>> -        private Iterable<? extends Element> analyze() {
>>> +        private Iterable<? extends CompilationUnitTree> analyze() {
>>>               try {
>>> -                return task.analyze();
>>> +                Iterable<? extends CompilationUnitTree> cuts =
>>> task.parse();
>>> +                task.analyze();
>>> +                return cuts;
>>>               } catch (Exception ex) {
>>>                   throw new InternalError("Exception during analyze - "
>>> + ex.getMessage(), ex);
>>>               }
>>>
>>> Does this seem OK?
>>>
>>> Thanks,
>>>      Jan
>>>
>>> >
>>> >> 2. A user defined method/variable cannot hide a method/field 
>>> which has
>>> >> been imported. (Maybe, a duplicate)
>>> >> See ReplaceTest#testForwardSingleImportFieldToMethod, ReplaceTest#
>>> >> testForwardSingleImportMethodToMethod
>>> >
>>> > That is a duplicate, but I figured out a way to fix it. So far fixed
>>> > for star imports.  Still need to fix for named imports.
>>> >
>>> > Tests reenabled.
>>> >
>>> >>
>>> >> 3. This may not be a bug. Anyway, eval() returns string in quotes 
>>> for
>>> >> String type.
>>> >
>>> > I sent a query about desired proper behavior here.  Got no responses.
>>> > So, I'm leaving it, for now.
>>> >
>>> > -Robert
>>> >
>>> >>
>>> >> Andrei Eremeev
>>> >
>>
>>