Opened 5 years ago

Last modified 13 months ago

#60206 new defect

Migrate kaffe dependents to Java portgroup — at Version 7

Reported by: chrstphrchvz (Christopher Chavez) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: michaelld (Michael Dickens), l2dy (Zero King), m@…, emcrisostomo (Enrico Maria Crisostomo), simon@…, blair (Blair Zajac), p-bro, emaros
Port: kaffe beanshell castor cglib checkstyle cobertura commons-cli commons-codec commons-io commons-lang commons-pool daisydiff derby derby-server dom4j fantom google-guava itext java_memcached jdom jfreechart jgoodies-common jgoodies-forms jgoodies-looks jmock1 jmock2 jna jtidy libsvm log4jdbc mars msv mysql-connector-java nds2-client-java objenesis pdfbox plovr proguard pulse relames rhino saxon saxpath sbt-0.7 scala-migrations servlet23-api servlet24-api slf4j sphinx4 spymemcached unicodeconverter-java xalanj xercesj xml-commons-resolver xmlenc xmlpull xom

Description (last modified by chrstphrchvz (Christopher Chavez))

Since OpenJDK became available in MacPorts only somewhat recently, many ports still specify Kaffe as a fallback Java runtime. However the kaffe port has been deprecated, since the upstream Kaffe project is dormant, and the kaffe port is outdated and somewhat broken (see #45198 and https://ports.macports.org/port/kaffe/builds).

Some of these ports continue to work as long as a compatible Java installation is already present. However many ports may be old, outdated, no longer maintained upstream, and might have difficulty working with more recent supported Java versions. Some will not compile under recent Java versions, even though their binary distributions might work fine. Certain ports are for libraries which aren't too useful on their own, but were needed by ports like tomcat5/6 and struts which have since been removed. Newer upstream versions of these ports might have introduced incompatibilities with/are not drop-in replacements for the versions still in MacPorts. In cases like these, a decision should be made to either keep and update the port, or remove it.

For the ports that are to be kept, the Java portgroup should be used to declare a dependency on Java (rather than depends_build/depends_lib/depends_run), specify what Java versions are compatible (after researching which ones each port works with), and control which fallback Java version that MacPorts will install if needed (preferably openjdk8 or openjdk11 as those are LTS releases).

The ports might have other outdated dependencies to clean up (e.g. jikes, gnu-classpath, and older versions of maven).

port maintainer status
beanshell 2.0b4_0 #60201
castor 0.9.9_0 #60202
cglib 2.2.2_0 #60197
checkstyle 4.3_0 #32187, #51731
cobertura 1.6_0 #59683
commons-beanutils 1.8.2_0 ???
commons-cli 1.1_1 ???
commons-codec 1.4_0 ???
commons-collections 3.2.1_0 #53939
commons-fileupload 1.2.2_0 ???
commons-io 1.4_0 ???
commons-lang 2.4_0 ???
commons-pool 1.5.4_0 ???
daisydiff 1.2_0 ???
derby 10.9.1.0_0 #54838
derby-server 10.5.3.0_0 ???
dom4j 1.6.1_1 ???
ehcache 1.1_0 ???
fantom 1.0.61_0 hum.ph:m #60213
flyway 6.3.1_0 @emcrisostomo [fae2ad3a13/macports-ports]
google-guava 13.0.1_0 ???
itext 1.1_0 #19385
jakarta-log4j 1.2.16_0 #53458
java_memcached 2.0.1_0 ???
jdom 1.1.1_0 ???
jfreechart 1.0.0-pre2_0 #60200
jgoodies-common 1.4.0_0 ???
jgoodies-forms 1.6.0_0 ???
jgoodies-looks 2.5.2_0 ???
jmock1 1.2.0_0 ???
jmock2 2.5.1_0 ???
jmol 14.29.51_0 @p-bro https://github.com/macports/macports-ports/pull/6636
jna 3.2.7_0 ???
jsch 0.1.54_0 https://github.com/macports/macports-ports/pull/6632
jtidy 04aug2000r7_0 #60198
libsvm 3.20_2 ???
log4jdbc 1.1_0 ???
mars 4.4_0 ???
msv 20081113_1 ???
mysql-connector-java 5.1.12_0 #58685
nds2-client-swig-java 0.16.3_0 @emaros ???
objenesis 1.1_0 ???
pdfbox 0.7.1_0 ???
plantuml 1.2019.11_0 ???
plovr 0.0-20120503103549_0 ???
postgresql7 7.4.24_5 (+java variant) ???
proguard 6.2.0_0 ???
pulse 1.2.18_0 redhillconsulting.com.au:simon ???
relames 20060319_0 ???
rhino 1.7R2_1 ???
saxon 9.5.1.1_0 ???
saxpath 1.0_0 ???
sbt-0.7 0.7.7_0 ???
scala-migrations 1.0.1_0 @blair ???
servlet23-api 1_0 #58389
servlet24-api 5.5.28_0 #58389
slf4j 1.5.6_0 ???
sphinx4 1.0beta5_1 #60199
spring-framework25 2.5.6.SEC01_0 ???
spring-framework30 3.0.7_0 ???
spring-framework31 3.1.2_0 ???
spring-javaconfig 0.2.1.0.0.M4_1 ???
spymemcached 2.8.4_0 ???
statcvs 0.2.2_0 https://github.com/macports/macports-ports/pull/6605
swig-java 4.0.1_0 @michaelld ???
swig3-java 3.0.12_0 @michaelld ???
unicodeconverter-java 2.0_0 ???
xalanj 2.7.1_0 ???
xercesj 2.11.0_0 ???
xml-commons-resolver 1.1_0 #58671
xmlenc 0.52_0 ???
xmlpull 1.1.3.4c_0 ???
xom 1.2.10_0 ???
zanata-cli 4.6.2_0 @l2dy ???

Change History (7)

comment:1 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Description: modified (diff)

comment:2 Changed 5 years ago by p-bro

jmol is still maintained and developed upstream. I occasionally upgrade the port. And I'd like to keep it that way.

How can I check which java version is compatible? Could not find any information on the upstream website.

Side note: On my machine it uses a JRE in /usr/bin, linking to /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java.

$java -version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

comment:3 in reply to:  2 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Replying to p-bro:

jmol is still maintained and developed upstream. I occasionally upgrade the port. And I'd like to keep it that way.

How can I check which java version is compatible? Could not find any information on the upstream website.

Side note: On my machine it uses a JRE in /usr/bin, linking to /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java.

$java -version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

Thanks for the quick response.

I found the FAQ page specifies a minimum Java version (assuming it's not outdated): http://jmol.sourceforge.net/faqs/

Application system requirements

What platforms does the Jmol application run on?

The Jmol application should run on any system that supports Java 1.4. Previous versions of Java are not supported.

This would suggest specifying Java 1.4 or higher in the port.

There is the possibility of a maximum compatible Java version, but have not confirmed this is the case. I briefly looked for discussions of issues with more recent Java versions on the project's mailing list and issue tracker, and so far only came across issues building jmol from source with Java 9 or later: https://sourceforge.net/p/jmol/bugs/608/ https://sourceforge.net/p/jmol/mailman/message/34860374/ . Since the port uses the binary distribution rather than builds from source, this shouldn't be an issue.

If jmol appears to work with the Java 8 on your system, then using Java 8 LTS as the fallback should be fine for now, and I believe is less likely to cause disruption than using Java 11 LTS. To clarify, the fallback version is what will be used if no other Java (version 1.4 or later) installation is already present.

I have opened a pull request on GitHub with the changes I suggest making: https://github.com/macports/macports-ports/pull/6636

comment:4 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Description: modified (diff)

comment:5 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

In fae2ad3a137866fe6c7c5dc439f888daab20745b/macports-ports (master):

flyway: use Java portgroup

Use latest Java LTS (Java 11) as fallback

Remove fallback dependency on deprecated port kaffe
See: #60206

comment:6 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Description: modified (diff)
Port: flyway removed

comment:7 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Description: modified (diff)
Note: See TracTickets for help on using tickets.