Found some errors in the patch and needs a fix so it works in both debian 9 and fedora. This is still a work in progress.

To build in debian I used:
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export USE_64=1
script -c 'make clean all' typescript.build
Attached is the build log

and to run the jss tests execute
script -c 'make test_jss' typescript.test

One difference is that you'll see in patch is that the $classpath list for fedora we have both
/usr/share/java/commons-codec.jar and
/usr/share/java/apache-commons-codec.jar
but in debian only the first one is listed as I wasn't able to install an apache2-common package. Perhaps the second has features that the first one lacks. This is worth investigating.

Thanks for the patch!

On Fedora, the apache-commons-codec.jar is actually a symlink to commons-codec.jar, so probably we can change the code to use commons-codec.jar such that the same path will work on both Fedora and Debian.

Correction to previous comment:
To build in debian I used:
export BUILD4DEBIAN=1
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export USE_64=1
script -c 'make clean all' typescript.build
and if you want to enable deprecations checks add
export CHECK_DEPRECATION=1 and the do
script -c 'make clean all' typescript.build.deprecation
(make sure the netscape ldap packages are installed)
The build should succeed but with many warnings. Attached is what I got. It's worth comparing against the corresponding one on fedora.

The patch only covers build_java.pl but we also need to address classpath in the test script.

Some crude way of doing that. The tests still fail.

2/33 pass 31/33 fail and all failures are look like this
============= Setup DBs
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -d64 -cp /usr/share/java/slf4j-api.jar:/usr/share/java/slf4j-jdk14.jar:/usr/share/java/commons-lang.jar:/home/emaldonado/sandbox/dist/xpclass.jar org.mozilla.jss.tests.SetupDBs /home/emaldonado/sandbox/tests_results/jss/debian.15 passwords
Jul 12, 2018 3:05:20 PM org.mozilla.jss.CryptoManager loadNativeLibraries
INFO: 32-bit jss library loaded
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.mozilla.jss.CryptoManager.initializeAllNative2(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;ZLjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;ZLjava/lang/String;Ljava/lang/String;ZZZZZZZZZZZ)V
at org.mozilla.jss.CryptoManager.initializeAllNative2(Native Method)
at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:437)
at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:403)
at org.mozilla.jss.tests.SetupDBs.main(SetupDBs.java:31)
JSSTEST_CASE 2 (Setup DBs): FAILED return value 1

The code has been modified to allow the test to use the libjss4.so built in the working area instead of the one installed on the system:

• https://github.com/dogtagpki/jss/commit/42cbe4fda805c48eb0ae15dba591486458e53760

Thank you Endi. Here is a merge of my two previous patches.

All tests are passing.

Plan then do a pull request once I have tested more.

According to @emaldonado there are issues with JSS 4.5 on Debian:

deprecation warnings causing build break
To clarify the deprecation warnings do not cause a build break as long as one uses java jdk 8 which is what fedora, debian 9, and most linux distros use. I saw that because I was initially using linuxmint 19 that has jdk 11. Fedora won't upgrade to open-jdk 11 for another two years so you won't have to worry about it for quite some time. It's still a good practice to give the package maintainers the option to compile with the -xlint:deprecation flag in order to properly analyze such issues.

incorrect path to some libraries
That's the main issue to be addressed.

I have tested the patch on fedora and debian and it's ready for review. When I file the pull request I will likely need a bit of hand-holding as I am a novice on the GitHub workflow. Let's chat online.

Fedora won't upgrade to open-jdk 11 for another two years so you won't have to worry about it ...
Sooner than I though, see https://fedoraproject.org/wiki/Changes/java-11-openjdk-TechPreview
This is beyond the scope of this ticket so I filed https://pagure.io/jss/issue/15 for that.

@edewata reviewed and pushed: https://github.com/dogtagpki/jss/pull/18

Warning: this is a rather long post to dump everything I have learned so far.

The JSS build fails with 4 errors and 100 deprecation warnings:
$ grep error: typescript.build
./org/mozilla/jss/netscape/security/x509/RevocationReasonAdapter.java:20: error: package java.xml.bind.annotation.adapters does not exist
./org/mozilla/jss/netscape/security/x509/RevocationReasonAdapter.java:29: error: cannot find symbol
./org/mozilla/jss/provider/java/security/JSSKeyStoreSpi.java:27: error: package javax.xml.bind is not visible
./org/mozilla/jss/tests/SymKeyDeriving.java:43: error: package sun.security.pkcs11.wrapper is not visible

Basically two errors:
1) error: javax.xml.bind is not visible and
2) error: package sun.security.pkcs11.wrapper is not visible

This what I have learned about the second one.

The debian folks had the same problems I had building jss when debian went to
openjdk 9 a while back - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875589
Jdk 9 and forward jdk uses modules, packages belong to modules and
can be made not public. More info on modules can be found at
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

This site https://fedoraproject.org/wiki/Changes/Java9TechPreview
though now obsolete as it was meant for f27 has some good info on
the HowToTest section that can be adapted to 10 which is available for
Rawhide. For 10:

🔗 How To Test

Install java-10-openjdk
Run (as root) 'alternatives --config java' and select the 10 version
Run 'java -version' to ensure that it is correct

I did that on my Rawhide system.

They have added a nice tool to check for dependencies called jdeps.
When I had opendk 8 as the one:
$ jdeps -jdkinternals /usr/lib64/jss/jss4.jar
jss4.jar -> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.172-14.b11.fc29.x86_64/jre/lib/ext/sunpkcs11.jar
org.mozilla.jss.tests.SymKeyDeriving (jss4.jar)
-> sun.security.pkcs11.wrapper.PKCS11Constants JDK internal API (sunpkcs11.jar)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

Following the instructions made the TechPreviow the default:

$ sudo alternatives --config java
[sudo] password for emaldonado:

There are 2 programs which provide 'java'.

Selection Command

1 java-openjdk.x86_64 (/usr/lib/jvm/java-10-openjdk-10.0.1.10-12.fc29.x86_64/bin/java)
*+ 2 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.172-14.b11.fc29.x86_64/jre/bin/java)

Enter to keep the current selection[+], or type selection number: 1
[emaldonado@localhost jss]$ sudo alternatives --config javac

There are 2 programs which provide 'javac'.

Selection Command

*+ 1 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.172-14.b11.fc29.x86_64/bin/javac)
2 java-openjdk.x86_64 (/usr/lib/jvm/java-10-openjdk-10.0.1.10-12.fc29.x86_64/bin/javac)

Enter to keep the current selection[+], or type selection number: 2

After switching to the openjdk 10 reran the jdeps and got the same message.

Since the modules where introduced the sun.security.pkcs11.wrapper packageis wrapped by a module. The PKCS11Constants interface apparently were intended for the use on the SunPKCS11 JCE provider.

Looking at the code there is this comment
* This is mainly the content of the 'pkcs11t.h' header file.

In that case nothing prevents the team from creating its own
org.mozilla.jss.pkcs11.PKCS11Contants.java to export those constants to the rest of JSS - and possibly client code as well.

No tool to create a java interface from a header file so it would have to be done manually. Fortunately, the pkcs11 headers don't change frequently and we do have our pkcs11 working group representative that can alert the team when changes are approved and shipped.

My bad, that was meant for Ticket 15. Let me post it there.

I'm closing this as this is currently passing on master for Ubuntu, a Debian-like distribution: https://travis-ci.org/dogtagpki/jss/builds/439784990?utm_source=github_status&utm_medium=notification