Source option 6 is no longer supported. Use 7 or later

[maximilianotaverna]

[INFO] Compiling 220 source files to /Applications/webfont-generator-master/vendor/sfntly/java/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Source option 6 is no longer supported. Use 7 or later.
[ERROR] Target option 6 is no longer supported. Use 7 or later.
[INFO] 2 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:00 min
[INFO] Finished at: 2022-02-04T11:22:44+11:00

[jamesbebbington]

Yeah, I'm receiving the same error when running setup.

webfont-generator v1.3.2
macOS 12.4

[bdusell]

Ah, software rot. It sounds like newer versions of javac are dropping support the version of Java that sfntly was written in. What version of Java are you using?

[jamesbebbington]

Thanks for getting back to me, I managed to find another solution to my problem, but FTR:

$ java -showversion
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)

[myspoonistoobig]

Thanks for getting back to me, I managed to find another solution to my problem, but FTR:

$ java -showversion
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)

What was the solution you found? I'm running into the same thing and there are no answers here.

[jamesbebbington]

Nothing that helpful for others I'm afraid, I was just looking to locally test out a font on a web site, so I just used the .ttf file. The project got shelved so I didn't have to cross the webfont bridge in the end.

[Y0RI0]

FWIW I was able to get it to work by simply changing the compiler version in the POM.XML for sfntly

/vendor/sfntly/java/pom.xml

Changed:
<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>

To:
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>

Reran setup and the compile section of the script was able to compile sfntly

Additionally I guess if you wanted to hack in a solution you could drop in a new function for setup to do something like this after fetch_sfntly()

force_new_compiler() {
  log 'Forcing new compiler version..'
  (
    cd "$SFNTLY_DIR"/java &&
    sed -i -e "s/source>.*/source>1.7<\/maven.compiler.source>/g" pom.xml &&
    sed -i -e "s/target>.*/target>1.7<\/maven.compiler.target>/g" pom.xml
  )
}

[kiwi-x]

Hi,

does anybody knows why the version of sfntly and woff are fixed to a commit:

SFNTLY_COMMIT='0e3a4a3c8e1623749a7d90cbfa5d431ac15c44ef'
WOFF2_COMMIT='5bbcf1f8ad44c07e797a088fec1dd2317611089a'

I just builded it with openjdk 17 and the latest github versions of sfntly and woff.

Build was sucessful and it looks like its working as expected.

So I don't know why I should patch an old version of sfntly instead
of using its latest version.

Cheers
kiwi-x

[bdusell]

It's just to make it future-proof, as those versions are known to work correctly. Is there a reason you need to use the newer versions?

[kiwi-x]

I just needed it to compile with openjdk 17 on debian bookworm.

And I just asked me the question why I should patch the old version
of snifty instead of using a newer, working version.

Now I understand your point of view.