Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"java.lang.IllegalStateException: Workspace is closed" with eclipse('4.7.2') #191

Closed
d1ss0nanz opened this issue Jan 22, 2018 · 29 comments
Closed
Assignees

Comments

@d1ss0nanz
Copy link

d1ss0nanz commented Jan 22, 2018

spotless 3.8.0

21:21:13.863 [ERROR] [com.diffplug.spotless.Formatter] Step 'eclipse formatter' found problem in 'src/main/java/com/[...]/config/schema/[FieldSchema.java](https://github.com/diffplug/spotless/files/1650522/FieldSchema.txt)
':
null

java.lang.reflect.InvocationTargetException
        at com.diffplug.spotless.extra.java.EclipseFormatterStep$State.lambda$createFormat$0(EclipseFormatterStep.java:100)
        at com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
        at com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
        at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
        at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
        at com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:263)
        at com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:205)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.IncrementalTaskAction.doExecute(IncrementalTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:121)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:92)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70)
        at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87)
        at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: java.lang.IllegalStateException: Workspace is closed.
        at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:412)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.createParser(DefaultCodeFormatter.java:332)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.parseSourceCode(DefaultCodeFormatter.java:317)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:213)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:206)
        at org.eclipse.jdt.internal.formatter.CommentsPreparator.formatCode(CommentsPreparator.java:1063)
        at org.eclipse.jdt.internal.formatter.CommentsPreparator.handleFormatCodeTag(CommentsPreparator.java:801)
        at org.eclipse.jdt.internal.formatter.CommentsPreparator.handleHtml(CommentsPreparator.java:665)
        at org.eclipse.jdt.internal.formatter.CommentsPreparator.endVisit(CommentsPreparator.java:621)
        at org.eclipse.jdt.core.dom.TagElement.accept0(TagElement.java:282)
        at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2796)
        at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2867)
        at org.eclipse.jdt.core.dom.Javadoc.accept0(Javadoc.java:205)
        at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2796)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareComments(DefaultCodeFormatter.java:399)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:222)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:177)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:160)
        at com.diffplug.gradle.spotless.java.eclipse.EclipseFormatterStepImpl.format(EclipseFormatterStepImpl.java:38)
        ... 47 more
@nedtwigg
Copy link
Member

Can you show the code of src/main/java/com/sophos/nsg/sep/config/schema/FieldSchema.java? It's crashing the formatter.

@d1ss0nanz
Copy link
Author

It's linked in my first post.

@jbduncan
Copy link
Member

@d1ss0nanz What "first post" are you referring to? :)

@d1ss0nanz
Copy link
Author

d1ss0nanz commented Jan 22, 2018

The first "comment" in this issue.
FieldSchema.java

Let me know if you need anything else.

@nedtwigg
Copy link
Member

Can you show us the eclipse config that you're using? eclipse('4.7.2').configFile(....?

@d1ss0nanz
Copy link
Author

@nedtwigg
Copy link
Member

Does it have .txt extension in your project? There are different formats, and we use the extension to determine what kind of file it is. It should have .xml extension, because it is xml.

So, it should be eclipse('4.7.2').configFile('eclipse_formatter_settings.xml'). If this fixes it, then we need a better error message. It seems like we do throw a descriptive exception, though...

@d1ss0nanz
Copy link
Author

d1ss0nanz commented Jan 22, 2018

It's .xml, but I can't upload XML files here, so I had to change the file extension.

Here's my actual config:

 apply plugin: "com.diffplug.gradle.spotless"
 
 buildscript {
  dependencies {
    classpath "com.diffplug.spotless:spotless-plugin-gradle:3.8.0"
  }
}
spotless {
    java {
        eclipse('4.7.2').configFile 'spotless.eclipseformat.xml'
        ignoreErrorForPath('[...]/config/schema/FieldSchema.java')
    }
}

@d1ss0nanz
Copy link
Author

Please let me know if you need any other information.

@nedtwigg nedtwigg added the bug label Jan 24, 2018
@nedtwigg
Copy link
Member

nedtwigg commented Jan 24, 2018

Sorry, I'm stumped. The ignoreErrorForPath is at least a workaround, correct?

@d1ss0nanz
Copy link
Author

d1ss0nanz commented Jan 24, 2018

Yes, ignoreErrorForPath is preventing the task to fail. The exception is still thrown, but that's more a cosmetic issue.

@d1ss0nanz
Copy link
Author

Found the cause of the exception:
When I remove <pre> and </pre> in lines 33 and 37 no exception is thrown.

@nedtwigg
Copy link
Member

nedtwigg commented Feb 6, 2018

Fascinating! I think the eclipse formatter is smart enough that it looks at the imports and uses them for javadoc {@link tags. I wonder if tries to do something fancy with code examples that requires compiled project info, thus triggering the workspace is closed error when it tries to look for project metadata.

Seems like a hard problem to track all the way down. Happy to take a PR, but unlikely to see a fix.

@regrog
Copy link

regrog commented Feb 9, 2018

Same error here with spotless 3.9.0
Removing <pre> and </pre> from source files fix the problem but I don't like that :|

@aram535
Copy link

aram535 commented Feb 13, 2018

Just FYI with eclipse oxygen, spotless 3.9.0 -- in eclipse I have no issue formatting the code. spotlessApplyJava however exceptions with the same message as the OP.

@nedtwigg
Copy link
Member

There is a formatter setting that determines whether java source code inside of a pre block gets formatted:

<setting id="org.eclipse.jdt.core.formatter.comment.format_source_code" value="false"/>

The default value is true, maybe false is a workaround?

@d1ss0nanz
Copy link
Author

Setting this to false isn't a workaround.

@fvgh
Copy link
Member

fvgh commented Apr 5, 2018

Problem
The problem is in the JDT code formatter. Due to pre it tries to created a new parser for the Java code within pre tags. The formatter requires a compilation unit (so in the end files). Since JDT now supports Java 9, it also requires a module-info.java. So what JDT now does is an assembly of fake paths. To make up these fakes, it uses the Eclipse work-space. But spotless has/requires no work-space, so the module is not initialized.
Work-Around
The only work-around I see is to set the following properties to FALSE:
  • org.eclipse.jdt.core.formatter.comment.format_html
  • org.eclipse.jdt.core.formatter.comment.format_source_code

Note that both must be set to false.

Solution
Will provide a fix ASAP, but it will take a while before it'll be available on Maven Central.

@MaximeTessier
Copy link

MaximeTessier commented May 25, 2018

Hello,
Same error, also with a <pre> and </pre> tag in my java documentation.
I use com.diffplug.spotless:spotless-plugin-gradle:3.12.0
Thanks.

@JamzTheMan
Copy link

Same error in 3.13.0 as well.

FYI: For now removed

 tags and added // @formatter:off

JamzTheMan added a commit to JamzTheMan/MapTool that referenced this issue Jun 2, 2018
 * Current spotless can not handle <pre> tags in comment section. Open
issue in github: diffplug/spotless#191

Signed-off-by: Jamz <[email protected]>
JamzTheMan added a commit to JamzTheMan/MapTool that referenced this issue Jun 9, 2018
* #49: Add proper pathfinding taking VBL into account

	- Total WIP POC

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 - Cleaned up code a bit, Tweaked heuristic
 - Currently avoids any cell that has any VBL in it... to be tweaked
later

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 - Buildable version...

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* Bug Fix

 - Preference Diaglog would error if launched from JAR or IDE as it
would be missing native libs for JVMPreferences. StartUp tab is now
disabled if not launched from native executable/missing packager lib.

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 - More progress on A*
 - Added Terrain Modifiers calculation and option on Token properties
 - WIP on multi threading...

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* Bug Fix - Inno Setup

 - Restored iss prop so directory will always populate during windows
install
 -

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 - Token Properties UI changes

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* Enhancement - FoW optimization!

 - Changed circles to 'fake' circles (removing curves from geometry) for
faster Area.add calculations
 - WIP new "GRID" vision/light type!

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 - WIP A* Pathfinding
 - WIP new "GRID" vision/light type!

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* com.github.jai-imageio:jai-imageio-core bumped to 1.4.0 to support Java
9

Signed-off-by: Jamz <[email protected]>

* Changed Sentry.IO to not log in Development envrionments.

Signed-off-by: Jamz <[email protected]>

* Fixes Z Order Violation

Pulled from upstream: RPTools#179

Signed-off-by: Jamz <[email protected]>

* Enhancement - Video Backgrounds

 * POC to add video as a background map

49: Add proper pathfinding taking VBL into account

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* Enhancement - #49: Add proper pathfinding taking VBL into account

 * Finished POC for ASTar Pathfinding, code cleanup
 * Spotless Applied
 * Had to remove grgit.branch.current().name for now, getting errors for
unknown reason

Signed-off-by: Jamz <[email protected]>

* Updated Gradle Build

 * Removed JFX-Plugin
 * Updated Spotless version to 3.13

Signed-off-by: Jamz <[email protected]>

* Updated for Spotless

 * Current spotless can not handle <pre> tags in comment section. Open
issue in github: diffplug/spotless#191

Signed-off-by: Jamz <[email protected]>

* Enhancement - Java 10!

 * Updated packaged JRE to Java 10.

Signed-off-by: Jamz <[email protected]>

* Update .appveyor.yml

Added Linux build

* Update .travis.yml

Removed Linux from the matrix

* Moving linux build to appveyor

 * Setting JAVA_HOME for windows only per matrix

Signed-off-by: Jamz <[email protected]>

* Moving linux build to appveyor

 * Setting JAVA_HOME for windows only per matrix

Signed-off-by: Jamz <[email protected]>

* Another appveyor test

Signed-off-by: Jamz <[email protected]>

* YAT

Signed-off-by: Jamz <[email protected]>

* YAT

Signed-off-by: Jamz <[email protected]>

* Update .appveyor.yml

Trigger appveyor $%$@#%#

* Appveyor not kicking off...

Signed-off-by: Jamz <[email protected]>

* Enhancement - AutoUpdate

 * Added tag name to Auto Update message
 * Appveyor environment var bug fix

Signed-off-by: Jamz <[email protected]>

* YAT

Signed-off-by: Jamz <[email protected]>

* YAT

Appveyor not kicking off if only yml chnaged?


Signed-off-by: Jamz <[email protected]>

* YAT 2

Signed-off-by: Jamz <[email protected]>

* WTF

Signed-off-by: Jamz <[email protected]>

* Attempt #12

Signed-off-by: Jamz <[email protected]>

* Attempt #13

Signed-off-by: Jamz <[email protected]>

* looking for java...

Signed-off-by: Jamz <[email protected]>

* Attempt #15

Signed-off-by: Jamz <[email protected]>

* Attempt #16

Signed-off-by: Jamz <[email protected]>

* Sigh... manually install jdk 10

Signed-off-by: Jamz <[email protected]>

* Hrm

Signed-off-by: Jamz <[email protected]>

* Well, can we go with java 9 then?

Signed-off-by: Jamz <[email protected]>

* Update .appveyor.yml

Adding manual install of Open JDK 10

* Update .appveyor.yml

Checking gradle version

* Update .appveyor.yml

change to unix gradle wrapper

* Update .appveyor.yml

Attempting to install oracle's JDK 10...

* Update .appveyor.yml

sigh...will this ever work...

* Update .appveyor.yml

one more try, why not...

* Update .appveyor.yml

Getting closer... now setting JAVA_HOME

* Update .appveyor.yml

adding fakeroot...

* Update .appveyor.yml

learn to type...

* Update .appveyor.yml

Finally working version for linux, Final tweaks...

* Update .appveyor.yml

Adding windows back.
 * Note sh: commands should only run on linux, build scripts should run on both

* Update build.gradle

Updated vendor to Nerps from Nerps-BETA.

* Update .appveyor.yml

Attempt to fix false spotless fails on windows VM

* Update .appveyor.yml

Adding init stage

* Update .appveyor.yml

added tag: $(APPVEYOR_REPO_TAG_NAME)

* Update .appveyor.yml

Test if linux/windows order matters

* Update .appveyor.yml

Uppercased APPVEYOR_REPO_TAG for Linux

* Enhancement #68 - Changing Language

 * Added JVM User Option to change default MapTool language via Edit ->
Preferences -> Startup tab
 * Moved MAPTOOL_DATADIR from JvmOptions to userJvmOptions and enabled
user setting in Edit -> Preferences -> Startup tab

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 * Pathfinding now properly works for Hex grid!
 * Refactored and cleaned up code for AStar Pathfinding

Task-Url: #49

Signed-off-by: Jamz <[email protected]>

* #63 Restore default behavior of spacebar+left mouse click

 * Spacebar functionality has been restored to it's original behavior
including ctrl+spacebar & shift+spacebar as well.
 * A new shift+ctrl+spacebar command along with a new pointer image is
now available. When this keystroke combo is pressed, and you are a GM,
the pointer will center & zoom all connected clients to that point. When
it is released, all clients will return to their previous view point &
zoom.

Task-Url: #63

Signed-off-by: Jamz <[email protected]>

* Spotless...

Signed-off-by: Jamz <[email protected]>

* #67: New Vision/Light type: GRID

 * Clear gridShapeCache on grid change
 * Instatiante footprint field to prevent null pointer on measuring
tool.

Task-Url: #67

Signed-off-by: Jamz <[email protected]>

* #49: Add proper pathfinding taking VBL into account

 * When token movement is done (left click released) we now wait for the
final background thread for A* Pathfinding is to either finish or time
out so quick or long moves get a chance to render a path.

Task-Url: #49

Signed-off-by: Jamz <[email protected]>
@nedtwigg
Copy link
Member

Thanks to a monumental effort from @fvgh, this has been fixed in plugin-gradle 3.14.0 and plugin-maven 1.14.0.

@achaphiv
Copy link

achaphiv commented Oct 3, 2018

I still encountered issues with <pre> and any sort of comments in general when using the gradle v3.14.0 or v3.15.0 plugin with the following config:

eclipse('4.7.2').configFile('eclipse-formatter.xml')

They seem to be bugs in the eclipse formatter itself, and not the fault of this plugin.

Thus, I could only workaround it by exporting a formatter.xml with comment formatting unchecked. I.E.

  • Enable Javadoc comment formatting
  • Enable line comment formatting

P.S. I would use the eclipse formatter v4.8.x, but that version introduced various unrelated formatting bugs. Thus I'm stuck with v4.7.x or the future v4.9.x.

@fvgh
Copy link
Member

fvgh commented Oct 4, 2018

Sorry @achaphiv , but a back-port of the bug-fix was never foreseen. There are known issues with 4.8.x, like reported with #263. Hence I additionally provided 4.7.3a. But this is also not an option for you?
Can you name a formatting problem with 4.7.3a (small example). 4.9 has been published in Maven central last moth. Will provide a new release if it helps.

@achaphiv
Copy link

achaphiv commented Oct 5, 2018

Sure, here's an example project that demonstrates one of the more annoying issues I encountered.

https://github.com/achaphiv/spotless-problem/

The following simple class uses 100% CPU and seems to cause an infinite loop:

public class CausesEndlessExecution {
  // one
  // two
  {
    if (
      true
    ) {}
  }
}

Tested on mac (java 1.8.0_172) and linux (openjdk 1.8.0_181).

Bizarre right? Those two comments combined with the multi-line if somehow cause the weirdness.

It fails on any eclipse version.

I.E.

  eclipse().configFile('eclipse-formatter.xml')
  eclipse('4.7.3a').configFile('eclipse-formatter.xml')
  eclipse('4.7.2').configFile('eclipse-formatter.xml')
  eclipse('4.8.0').configFile('eclipse-formatter.xml')

I eventually just gave up and disabled all comment formatting to sidestep all these issues.

@fvgh
Copy link
Member

fvgh commented Oct 5, 2018

@achaphiv Thanks for the input. Please give me some days to dig into it. Looks like some different bug.

@fvgh
Copy link
Member

fvgh commented Oct 9, 2018

@achaphiv
I can reproduce the problem, within Eclipse IDE and with Spotless.
But the problem seems not be related to line-comment or JavaDoc, since regardless of these two settings, the problem occurs. Can you confirm? In this case I really would like you to open another issue, if you think it's something I should look into.

To me it seems that some other preference correlation causes the problem:

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
        at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor.findWraps(WrapExecutor.java:526)
        at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor.findWrapsCached(WrapExecutor.java:403)
        at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor$WrapsApplier.newLine(WrapExecutor.java:252)
        at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor$WrapsApplier.token(WrapExecutor.java:225)
        at org.eclipse.jdt.internal.formatter.TokenTraverser.traverse(TokenTraverser.java:103)
        at org.eclipse.jdt.internal.formatter.TokenManager.traverse(TokenManager.java:383)
        at org.eclipse.jdt.internal.formatter.linewrap.WrapExecutor.executeWraps(WrapExecutor.java:366)
        at org.eclipse.jdt.internal.formatter.linewrap.WrapPreparator.finishUp(WrapPreparator.java:1034)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareWraps(DefaultCodeFormatter.java:426)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.prepareFormattedCode(DefaultCodeFormatter.java:224)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:178)
        at org.eclipse.jdt.internal.formatter.DefaultCodeFormatter.format(DefaultCodeFormatter.java:161)
        at com.diffplug.spotless.extra.eclipse.java.EclipseJdtFormatterStepImpl.format(EclipseJdtFormatterStepImpl.java:44)
        at com.diffplug.spotless.extra.java.EclipseJdtFormatterStep.lambda$apply$0(EclipseJdtFormatterStep.java:51)
        at com.diffplug.spotless.extra.java.EclipseJdtFormatterStep$$Lambda$87/605353830.apply(Unknown Source)
        at com.diffplug.spotless.FormatterFunc.apply(FormatterFunc.java:31)
        at com.diffplug.spotless.FormatterStepImpl$Standard.format(FormatterStepImpl.java:78)
        at com.diffplug.spotless.FormatterStep$Strict.format(FormatterStep.java:76)
        at com.diffplug.spotless.Formatter.compute(Formatter.java:230)
        at com.diffplug.spotless.Formatter.isClean(Formatter.java:167)
        at com.diffplug.gradle.spotless.SpotlessTask.check(SpotlessTask.java:264)
        at com.diffplug.gradle.spotless.SpotlessTask.performAction(SpotlessTask.java:205)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)

It is irritating the the Eclipse JDT preference editor does not prevent these malicious settings.
Anyhow, I am afraid I cannot investigate further, since it seems to be JDT problem and the latest JDT does not behave differently.

If you find anything that works with your Eclipse IDE but not with Spotless, let me know.

@achaphiv
Copy link

achaphiv commented Oct 9, 2018

But the problem seems not be related to line-comment or JavaDoc, since regardless of these two settings, the problem occurs. Can you confirm?

I only made one change to the eclipse-formatter.xml and my test project works in both spotless/eclipse:

-<setting id="org.eclipse.jdt.core.formatter.comment.format_line_comments" value="true"/>
+<setting id="org.eclipse.jdt.core.formatter.comment.format_line_comments" value="false"/>

In this case I really would like you to open another issue, if you think it's something I should look into.

Hmm, probably not necessary. Definitely looks like an Eclipse issue.

I made my original comment because I thought it worked in the IDE, but not spotless. But I see my test project freezing in the IDE as well. I was likely running into at least 2 separate issues:

  • Some files failing when not using 4.7.3a+.
  • Other files failing on this weird line comment handling.

If you find anything that works with your Eclipse IDE but not with Spotless, let me know.

I'll be on lookout, but Eclipse 4.9 (2018-09) still seems to have issues with line comments, so I've turned off all comment handling in both eclipse/spotless to avoid all current and future comment-related issues.

@fvgh
Copy link
Member

fvgh commented Oct 9, 2018

@achaphiv
When I found that the problem also occurs in Eclipse IDE, I tested with the default Eclipse Photon build-in preferences. It has format_line_comments set to true and works. I tried to change some of the preferences according to your configuration, but could not quickly determine where exactly the problem is.
I think you have found a really nasty bug in JDT and your example is very good.
Maybe you want to consider to raise a bug report in the Eclipse bug tracker.
It took a while, but with my settings my Photon Eclipse got out of memory with your example, like Spotless did on my system.
As soon as I am aware about an Eclipse version that fixes formatter bugs or has any enhancements in that respect, I am happy to provide a new Spotless Eclipse JDT version.
Sorry that I was not able to help you, with your current problem.

@fvgh fvgh changed the title java.lang.reflect.InvocationTargetException with eclipse('4.7.2') "java.lang.IllegalStateException: Workspace is closed" with eclipse('4.7.2') Oct 9, 2018
@fvgh
Copy link
Member

fvgh commented Oct 9, 2018

The original bug tile is misleading. Every exception which occurs within a Spotless Eclipse implementation leads to a java.lang.reflect.InvocationTargetException on Spotless plugin level. The cause of the exception (in this case "java.lang.IllegalStateException"), is the important one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants