Remove dependency on xtext's @Pure and ToStringBuilder

[lemmy]

lsp4j.debug depends on xtext base at runtime, because the generated POJOs import org.eclipse.xtext.xbase.lib.Pure and org.eclipse.xtext.xbase.lib.util.ToStringBuilder. Neither @Pure nor ToStringBuilder are required by lsp4j.debug's functionality. Please consider removing the xtext dependency to shrink the set of lsp4j.debug's dependencies.

Related: https://twitter.com/lemmster/status/1346543929299140610

[jonahgraham]

@spoenemann any thoughts on removing use of @Pure. It will be easier to do this dep removal of we do the same for LSP as DAP.

Thanks for your insights.

[spoenemann]

I think this can be changed in the JsonRpcDataProcessor, that is what generates the getters and setters as well as toString.

[jonahgraham]

@lemmy I think we have as much approval as we need for this. Would you like to provide a PR?

[lemmy]

I can do that. To confirm, though, we have an agreement to remove all @Pure annotations in POJOs, not just @Pure on toString methods?

[cdietrich]

these other pures are generated by
org.eclipse.lsp4j.generator.JsonRpcDataProcessor.generateImplMembers(MutableClassDeclaration, JsonRpcDataTransformationContext)
delegating to
org.eclipse.xtend.lib.annotations.AccessorsProcessor.Util

[lemmy]

Thanks, I guess adding @Pure is a side-effect of JsonRpcDataProcessor.generateImplMembers then. ;-)

[jonahgraham]

I can do that. To confirm, though, we have an agreement to remove all @Pure annotations in POJOs, not just @Pure on toString methods?

Yes! removing all use of @Pure and ToStringBuilder in LSP4J.

I hope that removes all dependencies on xbase (I believe it will for DAP side, it may not for LSP).

[lemmy]

Any suggestions how to remove @Pure without rewriting AccessorProcessor and EqualsHashCodeProcessor? @Pure is hard-wired in AccessorProcessor's getter generator and EqualsHashCodeProcessors's addHashcode/addEquals.

As a last resort, I can add a post-gen step to gradle to remove @Pure from the POJOs.

[jonahgraham]

I don't know. There are a few xtend/xtext experts in lsp4j, but you may get better answers from their specific channels?

[cdietrich]

The simplest is to copy&paste the original code.
You may also check if calling removeAnnotation on MutableField and MethodDeclaration works
(similar to the calls on class here https://github.com/eclipse/xtext-xtend/blob/7c6989c0d362cdd3c0754d577989e849c3d1130e/org.eclipse.xtend.ide.tests/src/org/eclipse/xtend/ide/tests/macros/AbstractReusableActiveAnnotationTests.xtend#L674)

[lemmy]

I appreciate your time but this PR has gone beyond my time budget (I will simply create dummies for @Pure and ToStringBuilder in my client jar). My fork of lsp4j contains an incomplete attempt to remove @Pure in case someone familiar with xtext wants to take a shot.

Thanks again!

[jonahgraham]

Thanks for having a look. Please let us know if you have other ideas for improvement.

[jonahgraham]

I think the correct code that @lemmy started in

https://github.com/lemmy/lsp4j/blob/1bf4a5b49539d046bd9f28d3dd06e1bfd18e1063/org.eclipse.lsp4j.generator/src/main/java/org/eclipse/lsp4j/generator/JsonRpcDataProcessor.xtend#L44-L54

should be

		impl.getDeclaredMethods.forEach [ method | 
			val purified = method.findAnnotation(Pure.findTypeGlobally)
			if (purified !== null) {
				method.removeAnnotation(purified)
			}
		]

In addition, a new implementation of toString needs to be provided. ToStringBuilder does quite a bit, but it should be easy enough to add a toString that is sufficient but not the same content.

I leave the above in case someone wants to pick up the work.

[jonahgraham]

I think that @cdietrich changes in #529 will fix this.