Opened 4 years ago
Last modified 6 months ago
#60206 new defect
Migrate kaffe dependents to Java portgroup — at Version 4
| 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 | ??? |
| flyway 6.3.1_0 | @emcrisostomo | ??? |
| 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 (4)
comment:1 Changed 4 years ago by chrstphrchvz (Christopher Chavez)
| Description: | modified (diff) |
|---|
comment:2 follow-up: 3 Changed 4 years ago by p-bro
comment:3 Changed 4 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 4 years ago by chrstphrchvz (Christopher Chavez)
| Description: | modified (diff) |
|---|
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.