The OSGi jars contain source code. Just recompile them with JDK 7 if you need to use JDK 7. Seems pretty easy to address the issue.
JDK 7 is not deployed in any significant amount yet (still waiting for JDK 7 on my Mac :-) so those brave pioneers can recompile for JDK 7 if they need to use JDK 7. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Holger Hoffstätte <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2011/08/18 09:07 Subject: [osgi-dev] JDK7 vs. -target jsr14 Sent by: [email protected] Hi, 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): --snip-- 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 reference, ^ MyRSA.java:16: error: method does not override or implement a method from a supertype @Override ^ 3 errors --snip-- "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. cheers Holger _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
