2

We have a code library that is used by developers and requires using Java 1.8. However, there have been requests to support 1.7 and it would be trivial to do so.

The library is basically a Java wrapper for a .NET CLI tool, so there is no real need for security outside of the .NET executable that is called.

I have a couple of questions about the security issues with Java:

  1. Is there a security risk involved with have the Java 1.7 JDK installed on our build machine if all it is being used for is to compile the jar file?

  2. Does running our library (that uses 1.7) create any security risks if it is being used in a program that is being compiled with Java 1.8 (or the latest version), or does that mitigate the security risks and put in place the security patches of later Java versions?

  3. Are there any major security concerns with supporting Java 1.7 when it is being used as a wrapper for a CLI tool?

  • 1
    I am not fully comfortable answering all three parts of your question so I will leave this as a comment. To answer your question as a whole, I would not recommend using Java 1.7 anymore. According to java.com/en/download/faq/java_7.xml (Oracle's website for Java 7), it hit end of life support back in April 2015 and will no longer receive security updates. Therefore if there is no known security vulnerabilities in Java 7 now (I am sure there is), there sure will be at some point and they will not be patched. Support 1.8 and up is my recommendation. – dFrancisco Feb 1 '18 at 20:08
5

Is there a security risk involved with have the Java 1.7 JDK installed on our build machine if all it is being used for is to compile the jar file?

Probably not, but there's no need to do that: javac provides the -target flag, which allows you to generate classfiles compatible with any version (provided that you don't use source features or call library methods that were not supported by that version).

Are there any major security concerns with supporting Java 1.7 when it is being used as a wrapper for a CLI tool?

Probably not. Security concerns with Java generally involve implementation issues in the JVM (Java Virtual Machine) or the libraries that it uses. There are also some issues with third-party libraries that enable exploitable behaviors (for example, Apache Commons Collections supporting a Map implementation that could execute arbitrary code).

If you're simply compiling the same code for different target architectures (1.7 versus 1.8) then you are almost guaranteed to get the same bytecode output. You can compare the bytecode generated for each version with the javap program.

Does running our library (that uses 1.7) create any security risks if it is being used in a program that is being compiled with Java 1.8 (or the latest version), or does that mitigate the security risks and put in place the security patches of later Java versions?

I can't understand the question that you're asking, so I'll answer the question that I think you're asking: if you run a 1.7-compatible compiled class on an up-to-date 1.8 JVM then you receive all security benefits of that JVM. If running on a 1.7 JVM or an older 1.8 JVM you are subject to whatever security flaws were present in that VM.

Note that many open source libraries are targeted to 1.6 and even 1.5. The only real reason to target a newer version is if you use language features (eg, Lambdas) or library functions that weren't available in the earlier release. In that case, picking the minimum necessary target version will prevent an earlier installation from compiling with the class, because each Java version uses a different classfile version and older compilers won't accept newer files.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.