search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

User Admin 1.1 not updated after generification #2989

Closed bjhargrave closed 4 years ago

bjhargrave commented 5 years ago

Original bug ID: BZ#3121 From: @pkriens Reported version: R7

bjhargrave commented 5 years ago

Comment author: @pkriens

User Admin service API was made generic made the package version was not updated.

There is an org.osgi.service.useradmin.jar on Maven central that is 1.1 and has no generics. Compendium for R7 also has a package 1.1 but has been made generic.

I think the package version should be updated to 1.1

bjhargrave commented 5 years ago

Comment author: @pkriens

Sorry, it should be updated to 1.2

bjhargrave commented 5 years ago

Comment author: @bjhargrave

(In reply to Peter Kriens from comment BZ#1)

Sorry, it should be updated to 1.2

Actually it would be updated to 1.1.1 (micro bump since we would not be changing the spec or (erased) API.)

We also need to figure out what other items are un-generified. A quick look shows the WireAdmin is in the same situation.

Basically anything which has not been updated after Nov 20, 2015 (https://osgi.org/gitweb/build.git?a=commit&h=40bc012fe258cabe0e664e8a8e3f6f74fa3b71c3) will probably need an update to pick up generics.

bjhargrave commented 5 years ago

Comment author: @pkriens

I think adding generics is a minor change since the JAR file now has the generic information a client could rely on. I.e. getField().getGenericType() will now return something different.

Such a change is not binary compatible.

bjhargrave commented 5 years ago

Comment author: @bjhargrave

(In reply to Peter Kriens from comment BZ#3)

Such a change is not binary compatible.

It is binary compatible since binary compatibility only cares about the erased signature. And the behavior of the API does not change due to the presence or absence of generic signature information.

We did micro bumps for Core/Cmpn 4.3 to 4.3.1 to add generics to the companion code jars but just failed to update the individual jars at the same time.

The fact that one can observe the presence or absence of generic signatures at runtime does not alter the semantic version of the API just as the fact that one can observe the presence or absence of method parameter names at runtime (javac -parameters) does not alter the semantic version of the API.

bjhargrave commented 5 years ago

Comment author: @pkriens

That is a very narrow interpretation of binary compatibility and in my opinion in direct conflict of the intent of semantic versions.

bjhargrave commented 5 years ago

Comment author: @bjhargrave

(In reply to Peter Kriens from comment BZ#5)

That is a very narrow interpretation of binary compatibility

It is in fact part of the definition of binary compatibility in the JLS:

From https://docs.oracle.com/javase/specs/jls/se12/html/jls-13.html#jls-13.4.14

"For purposes of binary compatibility, adding or removing a method or constructor m whose signature involves type variables (§4.4) or parameterized types (§4.5) is equivalent to the addition (respectively, removal) of an otherwise equivalent method whose signature is the erasure (§4.6) of the signature of m."

and in my opinion in direct conflict of the intent of semantic versions.

The JLS is clear that generic signatures are not part of binary compatibility. They are, of course, however part of source compatibility.

In the case here before us, we are discussing moving from methods without generic signatures and adding generic signatures to provide more source level detail on the types supported by the existing, unchanged semantics of the API. So we are not altering the semantics of the API, we are just more precisely stating them in the source code for the API. So this is not a minor change to the API semantics. It is NO change to the semantics of the API. Just a change to the source code which is micro bump.

Also, we have already released these packages, with generic signatures, in the osgi.cmpn jars, under their current package versions. So we actually don't need to change the package versions at all. We just need to release a micro bumped version of the jar to maven central. For example, org.osgi:org.osgi.service.useradmin:1.1.1 which contains the same org.osgi.service.useradmin package as org.osgi:osgi.cmpn:7.0.0.

bjhargrave commented 5 years ago

Comment author: @bjhargrave

CPEG call: BJ will update micro version for the affected spec jars.

bjhargrave commented 4 years ago

Comment author: @bjhargrave

Fixed by https://osgi.org/gitweb/build.git/commit/50ef16bd88d3c1c1e255dbcd0f2fc2b851999362

The following packages had micro version bumps:

org.osgi.service.deploymentadmin org.osgi.service.device org.osgi.service.http org.osgi.service.jndi org.osgi.service.upnp org.osgi.service.useradmin org.osgi.service.wireadmin org.osgi.util.xml