Re: additions to java-policy
> 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.
Reply to: