Variable called "java" messes with the imports

[orichalque]

Hello,
I'm Spooning the JUnit4 source code, and in the following class, a variable has been named "java":

String java = System.getProperty("java.home") + File.separator + "bin" + File.separator + "java";

I configured my launcher with launcher.getEnvironment().setAutoImports(false);, after running the launcher, the following code is generated:

java.lang.String java = ((((java.lang.System.getProperty("java.home")) + (java.io.File.separator)) + "bin") + (java.io.File.separator)) + "java";

Which is completely normal, but the compilation will fail because "java.lang.System" refers to the "java" String declared earlier, which has no "lang" attribute (obviously).

Since my previous issue I'm running Spoon using launcher.getEnvironment().setAutoImports(false);.

Since it is quite specific, I'm renaming the Java variable in the source code, but it can be a bit time-consuming, when there's multiple classes with a similar variable.

Thibault

[msteinbeck]

Why is the package "java.lang" listed at all? Isn't it imported by default?

[orichalque]

Hello @msteinbeck,
With AutoImports having the "false" value, Spoon specifies it. Is there a specific option for not importing the standard libraries such as String or System ?

[msteinbeck]

Is there a specific option for not importing the standard libraries such as String or System ?

Actually, I can't answer this question but I assume that it is not possible. From my point of view, even when autoimports are disabled, java.lang should not be listed explicitly.

[surli]

Since my previous issue I'm running Spoon using launcher.getEnvironment().setAutoImports(false);.

You're issue has been fixed, so you should be able to use the autoimport with Spoon 5.7.0-SNAPSHOT. I'll release it soon.

java.lang.String java = ((((java.lang.System.getProperty("java.home")) + (java.io.File.separator)) + "bin") + (java.io.File.separator)) + "java";

This should not happen, so there's a real bug here: when autoImport is disabled we have a mechanism to check this kind of conflict and to import the minimum classes to avoid this kind of error.

Actually, I can't answer this question but I assume that it is not possible. From my point of view, even when autoimports are disabled, java.lang should not be listed explicitly.

From my point of view, there's already a lot of options in Spoon, it would be overwhelming to add another one :) However we can discuss about the contract of Spoon when autoImport is disabled.
In my opinion, the behaviour should remain to use fully-qualified name everywhere, when it's possible, so no exception for java.lang.

WDYT @monperrus @tdurieux @pvojtechovsky ?

[pvojtechovsky]

In my opinion, the behavior should remain to use fully-qualified name everywhere, when it's possible, so no exception for java.lang.

I agree with Simon. There is no reason to change behavior of spoon for implicit java packages. It is OK that spoon generates java.lang.String. I intuitively expect that

• autoimport=true means use import + short class names when possible
• autoimport=false means do not use import + qualified class names when possible

It is just my feeling. If somebody has good reason for another behavior, I have no problem with anything else too. No algorithm I know depends on that.

[monperrus]

* autoimport=true means use import + short class names when possible * autoimport=false means do not use import + qualified class names when possible

+1 autoimport = false = for the machine, autoimport = true = for the human.

[msteinbeck]

I didn't know that Spoon already fixes this issue with 5.7.0. That being said, I agree with you that importing java.lang in case of autoimport = false is suitable.

[surli]

I didn't know that Spoon already fixes this issue with 5.7.0

Just to clarify, when I said the bug is fixed to @orichalque I was talking about #1306 which may have led to the use of autoimport = false.

[surli]

Another question: do you all agree that in either mode, we never need to explicitly import anything from java.lang. So the output file will never contain an import java.lang.XXX, right?

[pvojtechovsky]

output file will never contain an import java.lang.XXX

I agree.

[msteinbeck]

Another question: do you all agree that in either mode, we never need to explicitly import anything from java.lang. So the output file will never contain an import java.lang.XXX, right?

That is what i suggested above :)