If you are submitting a bug, please include the following:
with order
4=com.myTeam
3=java
2=javax
1=
0=#
- [ ] copy-paste the full content of any console errors emitted by `gradlew spotless[Apply/Check] --stacktrace`
N/A
If you're just submitting a feature request or question, no need for the above.
EclipseFormatter issues
https://github.com/krasa/EclipseCodeFormatter/issues/200
https://github.com/krasa/EclipseCodeFormatter/issues/105
Write
package somePackage;
import static somePackage.Foo.SomeEnum.Bar;
import static somePackage.Foo.SomeZClass;
import static somePackage.Foo.SomeZClass.m;
import java.util.function.Supplier;
// Use as a type argument to be a static import.
public class Foo implements Supplier
public void someMethod() {
SomeEnum e = Bar;
m(); // call m with a static import
}
@Override
public SomeZClass get() {
return null;
}
public enum SomeEnum {
Bar
}
// Add Z this should be sorted after SomeEnum
public static class SomeZClass {
static void m() {}
}
}
Eclipse Plugin will order imports:
import static somePackage.Foo.SomeZClass;
import static somePackage.Foo.SomeEnum.Bar;
import static somePackage.Foo.SomeZClass.m;
Eclipse will order imports:
import static somePackage.Foo.SomeEnum.Bar;
import static somePackage.Foo.SomeZClass.m;
import java.util.function.Supplier;
import somePackage.Foo.SomeZClass;
and spotless will order imports
import static somePackage.Foo.SomeEnum.Bar;
import static somePackage.Foo.SomeZClass;
import static somePackage.Foo.SomeZClass.m;
import java.util.function.Supplier;
```
Spotless using Eclipse format rules should have the same behavior as Eclipse
Thanks for another example. Related: #167, #174
Sorry I forgot to look up relevant issues, would you like me to dupe this issue out?
I think your issue adds helpful new information. Looks like krasa/EclipseCodeFormatter#105 fixed part of this problem (so they are closer to a fix than we are), and krasa/EclipseCodeFormatter#200 fixes the rest of it. If someone ever gets around to a PR for one of these import sorter issues, I'd like to resolve all of them, to minimize back-compat issues.
What I mean by back-compat is that it's important for Spotless users to have the option to freeze their formatting. Fixing this bug will change the order of imports in existing code. So it's important to have something like <importOrder><mode>legacy</mode>... for people who don't want to choose between "reorder all your imports" and "get new bugfixes and features". If we fix these bugs all at once, then there's just two modes, but if we fix them bit by bit it gets more complicated.
Hello. I have another case of inconsistent import order handling which is not related neither upper case packages(EclipseCodeFormatter#105) nor static imports(EclipseCodeFormatter#200). Do I need to file a new issue against it or it's ok to provide details here?
Is the problem that it's different than eclipse? If so this issue is a good place for it. Otherwise a new issue is better.
@nedtwigg yes it is.
So, in a nutshell the problem is that Spotless tries to arrange imports of packages that are not specified in "importorder" config in alphabetical order with respect to other imports. Eclipse Code Fromatter, in turn, places such imports at the end of the imports block.
Below is an example:
build.gradle:
plugins {
// Language plugins
id 'java'
id "com.diffplug.gradle.spotless" version "3.28.1"
}
repositories {
maven { url "https://plugins.gradle.org/m2/" }
mavenCentral()
jcenter()
}
dependencies {
implementation 'io.opencensus:opencensus-api:0.26.0'
}
spotless {
java {
importOrderFile 'Test.importorder'
eclipse().configFile 'CodeStyle.xml'
}
}
Test.importorder:
5=org
4=com
0=com.test
The file pre-formatted with ECF with Test.importorder:
package com.test;
import com.test.foo.Bar;
import org.xml.sax.SAXException;
import io.grpc.Deadline;
public class Example {
public void test() throws SAXException {
Deadline.getSystemTicker();
throw new SAXException(Bar.BAR);
}
}
Output of gradle spotlessCheck:
> Task :spotlessJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':spotlessJava'.
> The following files had format violations:
src/main/java/com/test/Example.java
@@ -2,10 +2,10 @@
import路com.test.foo.Bar;
+import路io.grpc.Deadline;
+
import路org.xml.sax.SAXException;
-import路io.grpc.Deadline;
-
public路class路Example路{
路路路路public路void路test()路throws路SAXException路{
Run 'gradlew spotlessApply' to fix these violations.
@nedtwigg any update on this issue?
I have no personal plans to work on any of the importsorter issues. I don't care what the order is, I just care that something enforces it. I agree it's a bug, and I'm happy to merge a solution from anyone.
So, in a nutshell the problem is that Spotless tries to arrange imports of packages that are not specified in "importorder" config in alphabetical order with respect to other imports. Eclipse Code Fromatter, in turn, places such imports at the end of the imports block.
@ekropotin we can work around this issue by adding an additional item to the .importorder file that forces unspecified imports to go at the end, for example:
#Organize Import Order
#Mon Apr 15 23:51:55 CEST 2019
0=java
1=javax
2=org
3=com
4=
This makes spotless formatting consistent with IDEA/Eclipse code formatter, so I'm able to use save actions with reformat on save without causing any conflicts.
@cimi This works like a charm! Thanks. You made my day!
So, in a nutshell the problem is that Spotless tries to arrange imports of packages that are not specified in "importorder" config in alphabetical order with respect to other imports. Eclipse Code Fromatter, in turn, places such imports at the end of the imports block.
@ekropotin we can work around this issue by adding an additional item to the
.importorderfile that forces unspecified imports to go at the end, for example:#Organize Import Order #Mon Apr 15 23:51:55 CEST 2019 0=java 1=javax 2=org 3=com 4=This makes spotless formatting consistent with IDEA/Eclipse code formatter, so I'm able to use save actions with reformat on save without causing any conflicts.
Good advice, however unfortunately this still doesn't seem fix the issue entirely in some cases:
Eclipse:
import com.sun.jna.platform.win32.Guid.CLSID;
import com.sun.jna.platform.win32.Guid.GUID;
import com.sun.jna.platform.win32.Guid.IID;
import com.sun.jna.platform.win32.Ole32;
import com.sun.jna.platform.win32.Variant;
import com.sun.jna.platform.win32.WinDef.BOOLByReference;
import com.sun.jna.platform.win32.WinDef.DWORD;
import com.sun.jna.platform.win32.WinDef.UINT;
import com.sun.jna.platform.win32.WinDef.UINTByReference;
import com.sun.jna.platform.win32.WinNT.HRESULT;
import com.sun.jna.platform.win32.COM.Unknown;
Spotless:
import com.sun.jna.platform.win32.COM.Unknown;
import com.sun.jna.platform.win32.Guid.CLSID;
import com.sun.jna.platform.win32.Guid.GUID;
import com.sun.jna.platform.win32.Guid.IID;
import com.sun.jna.platform.win32.Ole32;
import com.sun.jna.platform.win32.Variant;
import com.sun.jna.platform.win32.WinDef.BOOLByReference;
import com.sun.jna.platform.win32.WinDef.DWORD;
import com.sun.jna.platform.win32.WinDef.UINT;
import com.sun.jna.platform.win32.WinDef.UINTByReference;
import com.sun.jna.platform.win32.WinNT.HRESULT;
Eclipse seems to order segments consisting entirely of uppercase letters below segments with mixed case, regardless of the characters.
Most helpful comment
@ekropotin we can work around this issue by adding an additional item to the
.importorderfile that forces unspecified imports to go at the end, for example:This makes spotless formatting consistent with IDEA/Eclipse code formatter, so I'm able to use save actions with reformat on save without causing any conflicts.