1.16.20 Fails to build under Java 9 - does not override abstract method getSibling(String) in PathFileObject

[wltjr]

I have had to modify several classes via sed, removing support for < 9. I have made good progress, but I got stuck at the following. It is driving my crazy as I have tried to add the missing abstract method several times. I cannot seem to get the format down. Not sure if its improper usage of said class or something to do with the class modifiers. I have thrown the kitchen sink and nothing gets me past the following error.

I have put it at start and end of class just to see if that mattered. I know that sounds insane but I cannot for the life of my figure out why it cannot see the method I have added.

src/core/lombok/javac/apt/Javac9BaseFileObjectWrapper.java:38: error: Javac9BaseFileObjectWrapper is not abstract and does not override abstract method getSibling(String) in PathFileObject
class Javac9BaseFileObjectWrapper extends com.sun.tools.javac.file.PathFileObject {
^

I also get errors about the @OverRide but only when I add in the missing method and override it. Here is both inline so you can see the added method and the error on @OverRide.

src/core/lombok/javac/apt/Javac9BaseFileObjectWrapper.java:38: error: Javac9BaseFileObjectWrapper is not abstract and does not override abstract method getSibling(String) in PathFileObject
class Javac9BaseFileObjectWrapper extends com.sun.tools.javac.file.PathFileObject {
^
src/core/lombok/javac/apt/Javac9BaseFileObjectWrapper.java:113: error: method does not override or implement a method from a supertype
        @Override com.sun.tools.javac.file.PathFileObject getSibling(String basename) { throw new Exception("Not implemented"); }

I have looked at the source to PathFileObject. I have added it just like that and others. Nothing seems to work. Thus thinking something is wrong with that class or how its using PathFileObject in the first place. Given previous classes used the now removed BaseFileManager.

This is my last error to building under Java 9. Once again I do not need lombok it is a dependency of other things and it is preventing my progress. Specifically on packaging Netbeans 9 from source. I have filed a bug with byte-buddy-dep, requesting they stop using lombok. It is really the worst Java package I have ever come across. Please take that with a grain of salt. I have packaged from source some 900+ java packages and libraries from source. I do not make such statement lightly.

Bad enough I had to package some 70+ eclipse packages, as seen in byte-buddy-dep feature request issue. Which lombok seems nifty but due to the massive dependencies. I could never use it myself. 70+ deps for a single library. That is a nightmare for systems administrators....

[wltjr]

I feel like this is improper usage of PathFileObject. It does not seem the abstract methods can be overriden.

Abstract methods in PathFIleObject

    abstract String inferBinaryName(Iterable<? extends Path> paths);
    abstract PathFileObject getSibling(String basename);

I have made a simple test. I am experimenting and have same errors I get from Lomboks version.

import com.sun.tools.javac.file.PathFileObject;

import java.nio.file.Path;

public class test extends PathFileObject {

        @Override
        String inferBinaryName(Iterable<? extends Path> paths) {
                return(new String());
        }

        @Override
        PathFileObject getSibling(String basename) {
                return((PathFileObject)null);
        }
}

Compile

javac --add-exports="jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED" test.java

Result

test.java:6: error: test is not abstract and does not override abstract method getSibling(String) in PathFileObject
public class test extends PathFileObject {
       ^
test.java:8: error: method does not override or implement a method from a supertype
        @Override
        ^
test.java:13: error: method does not override or implement a method from a supertype
        @Override
        ^
3 errors

[wrprice]

I have made a simple test. I am experimenting and have same errors I get from Lomboks version.

Those abstract methods have default (package) access in the superclass, so they aren't visible (and can't be overridden/implemented by javac, even if the name and signature is the same) from a subclass defined in a different package.

Unless your test class is in the com.sun.tools.javac.file package, the design of PathFileObject does not seem to support extension by traditional means. I think you'll find Lombok does a lot of fancy and often "illegal" tricks (mostly allowed by the JVM, but many not valid in the language called "Java").

I'm not clear what you're trying to do -- it should be possible to compile Lombok from source using the provided build scripts. If you're modifying source code with sed then, well, don't do that. If you don't like compiling other projects' source code with Lombok involved, you could run that other source code through Lombok's delombok utility to output source code that (in theory) is the same as what Lombok would do.

[wltjr]

@wrprice Then it seems like the usage of said class in Javac9BaseFileObjectWrapper. Previous versions did not have that file. I am not sure it is correct for Java 9.

I am building lombok from source, not using providing build system. Most are not compatible with Gentoo's build system, portage, sanboxing, etc. I have been building lombok from source for past versions. Though they also have required a patch still in use, plus other stuff now to remove code that does not build under Java 9. Given how much of that code is based on conditionals within Java source files. I fail to see how even using default build would make that any different. Unless its removing code like I am for things that will not build under a give version of JDK.

Lombok is only needed as a dependency by one thing in my case, byte-buddy-dep. Which I have found out for byte-buddy-dep usage of Lombok, Google AutoValue is a drop in replacement for EqualsAndHashCode. I am not a google fan, but that package has considerably less dependencies and build issues. I opened an issue and submitted PR to byte-buddy to change from Lombok to AutoValue. That may happen, but legacy support and Auto* jars in Maven/Gradle repos being >=1.8 target/byte code, breaks legacy builds for byte-buddy. In my case I will continue with AutoValue replacing Lombok in byte-buddy-dep which eliminates the need for Lombok. Till I come across another package that needs it, if any.

[Maaartinus]

Which I have found out for byte-buddy-dep usage of Lombok, Google AutoValue is a drop in replacement for EqualsAndHashCode.

@wltjr That's definitely wrong.

Google AutoValue is an ordinary annotation processor and therefore it can't do what Lombok does: Add stuff to an existing class. It allows you to generate a different class extending the annotated class and having methods like equals etc. in a way similar to what lombok does. Have you checked e.g., how array comparison works for both? Do they both do the element-wise comparison? Do they both recurse into nested arrays? Does it depend on the runtime type or on the declared type of the field? Do they compute hashCode in exactly the same way?

TL;DR There's no drop in replacement.

Lombok needs its crazy dependencies to do its crazy stuff. As Lombok itself is no runtime-dependency, hardly anybody cares. I, as a user, never needed to compile Lombok. I did compile it when I worked on my tiny contribution, but still I have no idea what dependencies it has; it just worked.

[wltjr]

@Maaartinus thus far it does seem to be a drop in replacement for EqualsAndHashCode. I replaced that in byte-buddy-dep and thus far no issues. Not sure exactly if it introduced any issues or not. I have yet to run into any. On Gentoo everything is built from source. No point really in FOSS stuff if just using binaries others made. At times that can cause issues if the jar was made for a different version of Java. Like Auto* stuff is >=1.8, so causes problems for byte-buddy supporting 6 and 7/

[rspilker]

No comment

[rspilker]

Please give up trying to build lombok from source, without using the provided ant scripts.

[wltjr]

More like give up on Lombok. It was only needed thus far at build time for byte-buddy. I have successfully switched it over to AutoValue. Thus no need for Lombok. I will likely see about removing from my repository. Which I am now over 1k java packages from source including much of Netbeans 9 building fine not using their ant build system under Java 9....

Thank you for telling someone to give up on your code.... Nothing should require vodoo from a build system. None the less I fail to see how this issue is addressed. I may for the fun of it try building lombok via ant under Java 9, or Java 10... Since I am about done with stuff for Java 9 and onto 10...Good luck with this stuff... Seems many have a low opinion of the project and nothing I have seen thus far would give me anything other than the same.