[osgi-dev] JDK7 vs. -target jsr14

Holger Hoffstätte holger.hoffstaette at googlemail.com
Thu Aug 18 08:48:35 EDT 2011


so I figured I give JDK7 a workout. Silly me.

Things run fine, but imagine my surprise when I found the following
problem when trying to compile existing code that builds perfectly with
JDK5/6. Here is a reduced example (archive available on request):


holger>set JAVA_HOME=C:\Developer\JDK6
holger>%JAVA_HOME%\bin\javac -cp
org.osgi.core-4.2.0.jar;org.osgi.enterprise-4.2.0.jar MyRSA.java
-> OK

holger>set JAVA_HOME=C:\Developer\JDK7
holger>%JAVA_HOME%\bin\javac -cp
org.osgi.core-4.2.0.jar;org.osgi.enterprise-4.2.0.jar MyRSA.java
MyRSA.java:13: error: MyRSA is not abstract and does not override abstract
method exportService(ServiceReference,Map) in RemoteServiceAdmin
public class MyRSA implements RemoteServiceAdmin
MyRSA.java:17: error: name clash:
exportService(ServiceReference,Map<String,Object>) in MyRSA and
exportService(ServiceReference,Map) in RemoteServiceAdmin have the same
erasure, yet neither overrides the other
    public Collection<ExportRegistration> exportService(ServiceReference
MyRSA.java:16: error: method does not override or implement a method from
a supertype
3 errors


"MyRSA" is just a skeleton class that implements the RSA interface, which
contains a few generic method signatures. Note that the errors have
nothing to do with the @Override annotation; removing them does not fix
the original problem.

My guess is that overriding/implementing generic method signatures is now
verified at compile time and that the elaborate backwards compatibility
via -target jsr14 in the OSGI enterprise jar somehow violates this.

A sad twist is that *removing* the generics from the method signatures in
the implementng class makes things compile - at the expense of requiring
the usual type casts. Obviously this is not an option.

Any ideas or suggestions? IMHO this makes the whole jsr14 generics effort
pretty much useless going forward.


More information about the osgi-dev mailing list