> But I think the process should go in the other direction: Instead of > specifing something and waiting for people to implement it we should > document what has been implemented and is working well.
This is not necessarily true; take as an example the /usr/lib/jni proposal. Although pretty much everyone agreed on this, it would have never "evolved" on its own since it requires simultaneous changes from JVM maintainers and Java library maintainers, in order that this transition can be seamless for users. Changes do and IMHO should take place in both directions (policy then implementation, implementation then policy). > Using versioned JARs in packages without versioned dependencies or > outside of packages is very dangerous. As soon as the corresponding > package is upgraded your JAR is simply not there any more. One major > point about packages is that you can count on their content remaining > the same and that's not the case for versioned JARs. This is not the case for unversioned JARs either. I remember when versioned jars first appeared in policy; it was an attempt to simulate what happens with versioned C libraries. The problem is that Java library APIs tend not to have the same stability as C library APIs. In particular, you can find that the package is upgraded and even though your unversioned JAR is still there, its contents are somewhat changed and no longer work with your package. So sure, using versioned JARs without versioned dependencies can cause apps to break when you upgrade (just like depending on libfoo1 | libfoo2 | libfoo3 but linking specifically against libfoo2). But you are fooling yourself if you claim that simply removing versioning all together will bring with it stability. The sad fact with the Java world is that if your package or app uses some Java library, you have to follow changelogs to see how that library changes with each upgrade and whether your source code needs to be upgraded accordingly. > If we want to use versioned JARs, we also need to put the version in the > package name - otherwise we'll gain nothing at all. I could quite happily live with versions in the package names (and I could quite happily live without them), though it is rather unfortunate that there is no concept of API version like we have with C libraries (sonames). I certainly don't believe we should remove versioned JARs until we can come up with a solution that addresses the API problem. The current solution is like giving a C library an soname that is equal to the application version. If we remove versioned JARs it's like abandoning sonames altogether. Ben.
