Bugs

[andrei.eremeev]

It looks like completion works for jars, but does not work for directories.
I tried setting classpath by -classpath command line option and /cp 
command shell.

Andrei Eremeev

On 03/16/2015 04:29 PM, Jan Lahoda wrote:
> 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
>>>