@SafeVarargs and Java 6 interoperability

Question

I have a method with a generic varargs parameter in my API. I want my API to be Java 6 source and binary compatible, but it would be nice if Java 7 API consumers wouldn't suffer from unnecessary "varargs" warnings.

A trick that I can think of is to add my own java.lang.SafeVarargs annotation to my API and ship it with my deliverable. As an effect:

Java 6 compilers wouldn't recognise this annotation and just ignore it.
Java 7 compilers would recognise this annotation, and probably (?) class-load the one from the JDK first and thus they wouldn't produce the annoying warnings anymore.

Apart from license concerns, is this guaranteed to work? It seems to work with javac. Or are there configurations where re-defining an annotation from the JDK has undesireable side-effects at the call-site? Or is there another way to solve this Java 6/7 interoperability issue?

A related question:

Using Java 7 SDK features in Java 6

I don't understand the problem fully but if warnings are a problem they can be supressed as long as one is sure that there is no real reason to be warned. — NoDataDumpNoContribution, Jan 13 '14 at 09:00
@Trilarion: No, you don't understand the problem :-) I don't want to leave the burden of suppressing warnings to my API consumers. I'd like to use the declaration-site `@SafeVarargs` annotation, but that's not available in Java 6 — Lukas Eder, Jan 13 '14 at 09:15

uk4sx · Answer 1 · 2014-02-16T13:36:19.590

Question: is this guaranteed to work?

Answer: it depends. I would like to point out one potential issue.

The "real" @SafeVarargs annotation is declared with RetentionPolicy.RUNTIME (see here). The reason for this (in contrast with @Override, which has RetentionPolicy.SOURCE) is probably to allow the compiler to check for it at the calling site. However,

IF your version of the SafeVarargs annotation is declared with RetentionPolicy.RUNTIME
AND the code which uses it is run using JRE 6 (which does NOT contain this annotation)
AND your version of the SafeVarargs annotation is on the classpath

THEN any code which uses Reflection to get the method annotations at runtime (e.g. Spring framework) will fail miserably with SecurityException because the package name of the annotation starts with "java." (see the relevant code from the ClassLoader.preDefineClass() method and the stactrace below, both from Sun JRE 1.6.0_31).

If the annotation is on the classpath at compile time but not at runtime ("provided" scope in maven) then there is no exception thrown (at least with Sun JRE).

The best solution would be to have some Maven artifact like java.lang.java7-annotations at disposal and use it with scope "provided". I found something here (artifact: com.google.backport.safevarargs) but it is not in the central repo.

if ((name != null) && name.startsWith("java.")) {
    throw new SecurityException("Prohibited package name: " +
                                 name.substring(0, name.lastIndexOf('.')));
}

Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang
    at java.lang.ClassLoader.preDefineClass(ClassLoader.java:479)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
    at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

@SafeVarargs and Java 6 interoperability

1 Answers1