Lombok - Hrisey conflict

Question

I am using Lombok and Hrisey in my Android app. I have installed both plugins on Android Studio.

But since I started using Hrisey I get some errors during the build. I guess there is a conflict somehow.

Here is the error, in my Application class, even if is not thrown by any specific line:

 Warning:(14, 8) lombok.javac.apt.Processor could not be initialized. Lombok will not run during this compilation: java.lang.ClassCastException: Cannot cast hrisey.javac.handlers.ArgumentHandler to lombok.javac.JavacAnnotationHandler
at java.lang.Class.cast(Class.java:3084)
at lombok.core.SpiLoadUtil$1$1.next(SpiLoadUtil.java:111)
at lombok.javac.HandlerLibrary.loadAnnotationHandlers(HandlerLibrary.java:170)
at lombok.javac.HandlerLibrary.load(HandlerLibrary.java:155)
at lombok.javac.JavacTransformer.<init>(JavacTransformer.java:43)
at lombok.javac.apt.Processor.init(Processor.java:86)
at lombok.core.AnnotationProcessor$JavacDescriptor.want(AnnotationProcessor.java:87)
at lombok.core.AnnotationProcessor.init(AnnotationProcessor.java:141)
at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.init(AnnotationProcessor.java:53)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:517)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:614)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:707)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1108)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
at com.sun.tools.javac.main.Main.compile(Main.java:439)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132)
at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:42)
at org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJavaCompiler.java:35)
at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.delegateAndHandleErrors(NormalizingJavaCompiler.java:97)
at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:50)
at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:36)
at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:34)
at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:25)
at org.gradle.api.tasks.compile.JavaCompile.performCompilation(JavaCompile.java:158)
at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:138)
at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$IncrementalTaskAction.doExecute(AnnotationProcessingTaskFactory.java:235)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:211)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$IncrementalTaskAction.execute(AnnotationProcessingTaskFactory.java:222)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:200)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:305)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

He is an example of how I am using Lombok and Hrisey together:

@Data
@NoArgsConstructor
@hrisey.Parcelable
public class Contacts implements Parcelable {

    private String phoneNumber;

}

Lombok is (imho) a very unstable framework with lots of problems - differing API and strange behaviours. I would not consider using lombok.. — Stefan, Jul 01 '15 at 09:29
well I am using it in two apps and it works like charm... I get this problem when I started using hrisey — Daniele Vitali, Jul 01 '15 at 09:32
lombok lacks performance and even creates errors on equals/hashcode method. Generating getters setters is highly outperformed by IDE assistance. Lombok can cause eclipse and intellij in lots of situations to crash and not recover. It even fails having a stable behaviour when new versions are released. I have never heard of anyone using lombok to stick up with it after some time and complexity. — Stefan, Jul 01 '15 at 09:35
@Stefan Your first comment is slightly off - for many people including me, Lombok works pretty well. Your second comment is nonsense. +++ Lombok's equals/hashCode is no worse than what eclipse generates, it's actually better as it can handle inheritance. +++ "highly outperformed by IDE assistance" - if the goal is get more lines, than yes. Otherwise, no way. +++ And no, I'm neither author nor contributor of Lombok, just a happy user. — maaartinus, Jul 01 '15 at 12:15
just because you have not seen such errors and are a happy user does not mean it does not exist. I have seen different customers using lombok -all of them stopped using it after a year or two with many different problems. Glad everything works fine but keep a warning in mind if you have silly problems.. — Stefan, Jul 01 '15 at 13:53
@Stefan Sure, there are some problems as what Lombok internally does is rather hacky and there's no big company behind it. When combined with other less common tools, more problems are to be expected. But this doesn't make your "very unstable" or "differing API" sentences right nor your FUD spreading correct. And your performance claim as just plain wrong (or unclear what performance you mean). Feel free to invite me to chat in case you want discuss it. — maaartinus, Jul 02 '15 at 02:20

score 1 · Accepted Answer · answered Jul 01 '15 at 12:19

1

I don't know Hrisay, but this page lists Lombok annotations and the doc says, it's based on Lombok. So I guess, you shouldn't use both as it's already included.

answered Jul 01 '15 at 12:19

maaartinus

44,714
32
161
320

I see, but that means the "Lombok features" in Hrisay won't be updated as soon as there is a new version of Lombok right? – Daniele Vitali Jul 01 '15 at 16:06
@DanieleVitali I guess, they won't. But note that Lombok develops rather slowly and that this project is [very active](https://github.com/mg6maciej/hrisey/commits/develop). It's a Lombok fork so what you were trying was like applying Lombok twice. – maaartinus Jul 02 '15 at 02:09
I was wondering because if I am not wrong, they release a new version of Lombok few weeks ago. Thank you anyway :) – Daniele Vitali Jul 02 '15 at 08:45
@DanieleVitali You're right, the newest changes ([16.4](https://projectlombok.org/changelog.html)) aren't included yet. But these are just bugfixes which you may or may not don't need (rather no). Version 16.2 is [merged](https://github.com/mg6maciej/hrisey/commit/677bef7e38def282ef28f5f73b51dcd49e6df61c), in case you do need more, [file an issue](https://github.com/mg6maciej/hrisey/issues/new). – maaartinus Jul 02 '15 at 08:58

Lombok - Hrisey conflict

1 Answers1