Ant build failed (AbstractPainter.class error)

A

alphacow

New member
Having an issue building out from source. On a mac, using jenv to run java 1.6. Error follows. Any help would be appreciated.

Code: 
$ java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
$
$ ant
Buildfile: /Users/<me>/Code/KoLmafia/kolmafia-code/build.xml

start:

init:

svn-version:

gitsvn-version:

version:
     [echo] Current revision: 19527M

debug:

init:

svn-version:

gitsvn-version:

version:
     [echo] Current revision: 19527M

compile:
    [javac] Compiling 1393 source files to /Users/<me>/Code/KoLmafia/kolmafia-code/build
    [javac] /Users/<me>/Code/KoLmafia/kolmafia-code/lib/org/jdesktop/swingx/JXLabel.java:71: cannot access org.jdesktop.swingx.painter.AbstractPainter
    [javac] bad class file: /Users/<me>/Code/KoLmafia/kolmafia-code/build/org/jdesktop/swingx/painter/AbstractPainter.class
    [javac] class file has wrong version 52.0, should be 50.0
    [javac] Please remove or make sure it appears in the correct subdirectory of the classpath.
    [javac] import org.jdesktop.swingx.painter.AbstractPainter;
    [javac]                                   ^
    [javac] Compile failed; see the compiler error output for details.

BUILD FAILED
/Users/<me>/Code/KoLmafia/kolmafia-code/build.xml:363: The following error occurred while executing this line:
/Users/<me>/Code/KoLmafia/kolmafia-code/build.xml:149: Failed to compile third-party libraries

Total time: 5 seconds
 
...aaaaand nevermind, just deleted and re-checked out from source, everything built just fine. Move along, nothing to see here.
 
That looks like you built with java 1.8 first (class file version 52.0 is when it was built targetting java 1.8), and then didn't clean fully before rebuilding with 1.6.
 
I built with Java 13, since I had it on my machine, and I only found one change that was needed in swingx ErrorSupport.java. It's 100% not needed, but if you all ever decide to move to a new target version, it's easy enough for amateurs like me to do...
 
MCroft said:
I built with Java 13, since I had it on my machine, and I only found one change that was needed in swingx ErrorSupport.java. It's 100% not needed, but if you all ever decide to move to a new target version, it's easy enough for amateurs like me to do...
Click to expand...

I'm lazy and would rather ask than reconfigure my machine and try. What happens if you make the change so things compile under Java 13 and then uninstall Java 13 and build under something earlier, say Java 11? I don't think we want to do anything that requires all of the devs and other home builders to update. Thanks.
 
It fails, because the fix (as I implemented it) is a lambda expression so it requires Java 8. If kolmafia ever switches Java 8, then this can be changed.

Code: 
Index: lib/org/jdesktop/swingx/error/ErrorSupport.java
===================================================================
--- lib/org/jdesktop/swingx/error/ErrorSupport.java	(revision 19728)
+++ lib/org/jdesktop/swingx/error/ErrorSupport.java	(working copy)
@@ -67,7 +67,8 @@
      * added.
      */
     public ErrorListener[] getErrorListeners() {
-        return listeners.toArray(null);
+
+        return listeners.stream().toArray(n -> new ErrorListener[n]);
     }
 
     /**

Here's what happens to source and target = 1.6 if you have this change.
Code: 
compile:
    [javac] Compiling 1545 source files to /Users/mcroft/projects/kolmafia/build
    [javac] /Users/mcroft/projects/kolmafia/lib/org/jdesktop/swingx/error/ErrorSupport.java:71: error: lambda expressions are not supported in -source 1.6
    [javac]         return listeners.stream().toArray(n -> new ErrorListener[n]);
    [javac]                                             ^
    [javac]   (use -source 8 or higher to enable lambda expressions)
    [javac] 1 error
    [javac] Compile failed; see the compiler error output for details.
Java 13 error with original source.
Code: 
    [javac] /Users/mcroft/projects/kolmafia/lib/org/jdesktop/swingx/error/ErrorSupport.java:70: error: reference to toArray is ambiguous
    [javac] 		return listeners.toArray(null);
    [javac] 		                ^
    [javac]   both method <T#1>toArray(IntFunction<T#1[]>) in Collection and method <T#2>toArray(T#2[]) in List match
    [javac]   where T#1,T#2 are type-variables:
    [javac]     T#1 extends Object declared in method <T#1>toArray(IntFunction<T#1[]>)
    [javac]     T#2 extends Object declared in method <T#2>toArray(T#2[])
 
fully converting it to 13 (or 8) would probably want to look at some of the deprecated methods that javac warns of, but in terms of compiling and running it was successful with 13.0.2 and OpenJ9 instead of HotSpot.
 
I would like to be able to use Java 8 features, including lambda expressions.
I wonder how many of our users are not running Java 8?

Java SE 6 was released December 2006 and hit its end-of-life date on December 2018
Java SE 7 was released in July 2011 and is end-of-life on July 2022
Java SE 8 was released in March 2014 and is end-of-life on March 2025

If we advance our target version requirement, I'd suggest we go straight to 8.
 
I'd be in favor of a newer target version (surprise!).

The reason I fixed swingx instead of updating swingx (and letting them fix it) was that there is no more recent version of swingx. Luckily it was a one-line fix.

It'll be interesting to see what libraries would need updating. I would definitely want to see LTS releases when updating (8 and 11, for example).
 
I will run whatever version of Java is needed. The days when I had to be compatible with a work environment on this machine are past.

I have been making a distinction between a compile environment and a run environment. I am under the impression that if I compile and build on version X with the appropriate switches, the resulting jar file can run on version Y where Y <= X.

If that is correct then I think the devs can decide to upgrade without any impact on users. The historical reasons for not upgrading the devs were rooted in Java versions and Mac support and at least one dev who could not upgrade. Those days are long gone, I believe.

If I am wrong then we should probably start a thread elsewhere and see if any users here have concerns about requiring a runtime of 7 or 8.
 
You must log in or register to reply here.
Back
Top