The change is binary compatible which is the most important thing. It is not source compatible. But if your are changing your build to use newer jar files to recompile your source, you can make the minor source changes to deal with the additional of generic signatures.
Changing from Dictionary to Map is both a binary incompatible change (== BAD) and also a non-trivial source compatible change since Dictionary and Map are different in many ways. We are not going to change existing API to use Map (from Dictionary) due to the above concerns. We are however using Map in new API. For example see to new Resource and Bundle Wiring API which all use Map. -- 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: Ancoron Luciferis <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 2012/06/14 14:26 Subject: [osgi-dev] OSGi Core r4.3, Dictionary and API breaks Sent by: [email protected] Hi devs, I just stumbled across this (again) while upgrading some libraries from 4.2.0 to 4.3.0. As I got some compile errors caused by the change to require Dictionary<String, ?> instead of just Dictionary for e.g. service registration (which effectively is a change in contract - breaking API - in a minor version update), I had a look into the JavaDoc for Dictionary again and noticed (again) that it had been deprecated for quite some time. So I have the following questions: 1.) Why breaking compile-time API in a minor version release - at least for Java 1.5+? 2.) If breaking compile-time anyway why not just clean up at the same time (Dictionary -> Map)? 3.) Why is Dictionary still being used in r5 (Map is there since Java 1.2 - should be safe to change)? I would have expected that new methods get introduced in that minor version update using Map and the other ones marked as deprecated, so that code maintainers have a grace period where they can test new features coming with the new release without having to change other parts of their module. Thanx for any comments on this. Cheers, Ancoron _______________________________________________ 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
