Unable to create object named 'io' of type Integer

[eveningsamurai]

I have been trying to create an object of type Integer

Integer io = new Integer(10);
System.out.println(io)

but seem to be running into issues

|   Integer io = new Integer(10);
cannot find symbol
  symbol:   class 

|   Integer io = new Integer(10);
static import only from classes and interfaces

I can do it for the Long wrapper fine
Long lo = new Long(10);

I have tried this in a jshell and that works. I have verified that the jshell is using the jdk
java --list-modules | grep "jdk.jshell" jdk.jshell@10.0.2

[SpencerPark]

Hi @eveningsamurai, thanks for all the details with the issue. Just gave this a try and I can indeed reproduce this but strangely it is related to the name io and not the Integer class.

Renaming the variable to i made everything work fine.

Also very strange is that if you run it a bunch of times it switches between:

cannot find symbol
  symbol:   class $JShell$

and

cannot find symbol
  symbol:   class 
static import only from classes and interfaces

java is another name that looks to be causing this issue.

After the issue occurs it also breaks all the builtins like display and eval which makes me think it causes an internal error that is just destroying the insides

If you wouldn't mind, please keep this open until we can find what the issue is with the name io and hopefully provide a better error message along with keeping the integrity of the shell instance.

[eveningsamurai]

Thanks @SpencerPark for looking into it. I never tried with a differently named variable because never thought that could be an issue :) I will edit the title to reflect the issue

[SpencerPark]

Alright this is really confusing me. Not sure what is so special about io... but I've narrowed things down.

The ijava-jshell-init.jshell script is causing the issue. Very strangely, multiple * imports in the same cell looks to be causing this.

import java.io.*;
int io = 10 // OK

import java.io.*;
import java.math.*;
int io = 10 // BAD first run

import java.io.*;
//----------- new cell
import java.math.*;
int io = 10 // OK

Running a second time seems to fix the issue and it never happens again...

This doesn't happen in jshell and I think it is because we are using the DirectExecutionControl(no execution for these test cases so that's not it...). Still need to debug a bit further to see if IJava's layer on top of it is what broke it or if there is a bug in the jdk implementation but that is for tomorrow :)

Can't reproduce the java variable name issue like I could the other day :/(Can't on 9+181 but can on 10.0.1+10)

Just keeping some notes here to come back to.

[SpencerPark]

Aha! I think I've found it. It is not the execution but still IJava's fault. The startup scripts use some fully qualified names which start in the io and java packages which is part of the issue.

It seems to only be a problem in a snippet that triggers a redeclaration of a signature that both uses the package in a static call in the body of the additional declaration.

Can reproduce this in jshell as well which makes things a bit better:

C:\Users\Spencer>jshell
|  Welcome to JShell -- Version 10.0.1
|  For an introduction type: /help intro

jshell> java.util.List t() {
   ...>     return null;
   ...> }
|  created method t()

jshell> java.util.List t(Object u) {
   ...>     java.util.List.of();
   ...>     return null;
   ...> }
|  created method t(Object)

jshell> Object java = null
|  Error:
|  cannot find symbol
|    symbol:   class
|  Object java = null;
|  ^
|  Error:
|  static import only from classes and interfaces
|  Object java = null;
|  ^
|  created variable java, however, it cannot be referenced until these errors are corrected:
|      cannot find symbol
|        symbol:   class
|      Object java = null;
|      ^
|      static import only from classes and interfaces
|      Object java = null;
|      ^

Here is a version to copy-paste to try:

java.util.List t() {
    return null;
}
java.util.List t(Object u) {
    java.util.List.of();
    return null;
}
Object java = null

So this is just something to be careful of. Since changing to the direct execution control we can actually get away with a simple static import and don't need all the initialization scripts anyways. I'll switch to that and hopefully just step around this :)