[
https://issues.apache.org/jira/browse/FELIX-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587572#action_12587572
]
Stuart McCulloch commented on FELIX-532:
----------------------------------------
OK, here's the change from the clarifications section of the second edition of
the JavaTM Virtual Machine Specification...
http://java.sun.com/docs/books/jvms/second_edition/html/ChangesAppendix.doc.html
" * Clarifying that the class hierarchy is searched when resolving fields
and methods.
The original specification was unclear as to whether, during method or
field resolution, the referenced field had to be declared in the exact class
referenced or could be inherited. This led to variations among Java virtual
machine implementations and inconsistency between The Java Virtual Machine
Specification and The JavaTM Language Specification. The revised specification
gives a more precise description that agrees with the behavior of most
implementations, but not with The JavaTM Language Specification. The JavaTM
Language Specification will be corrected in its next edition.
This choice gives programmers the flexibility of moving methods and
fields in the class hierarchy while retaining binary compatibility with
previous implementations of their programs. "
Which is why with target > 1.2 the method invocation uses a reference to the
sub-class (because the hierarchy will be searched) while with target = 1.1 the
method invocation uses the abstract base class (because the original JVM spec
didn't say that the hierarchy would be searched). And as they say in the
clarification, the reason why the hierarchy should be searched is because
developers can then move methods around in the various superclasses without
breaking binary compatibility.
So from my perspective it looks as though Bnd is working correctly - if you use
the 1.1 bytecode it has this additional reference to the "support" package, so
it's correct that Bnd should add this as an import because you may need it when
running in an older JVM, whereas with the 1.2 bytecode you won't need this
import because the newer JVMs (>1.1) will traverse the hierarchy transparently.
All of which leads to the question - does this cause an actual error when you
deploy to an OSGi framework? Or are you seeing the error elsewhere, such as
Eclipse/PDE, which has a number of known bugs relating to visibility of
abstract base classes (PDE/JDT thinks it needs an import but the OSGi spec
actually says the import is not needed).
> Package inheritance dependencies are not imported when maven-compiler-plugin
> is defined in build
> ------------------------------------------------------------------------------------------------
>
> Key: FELIX-532
> URL: https://issues.apache.org/jira/browse/FELIX-532
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: JDK 1.5.0_14 on Windows XP
> Reporter: James Rowe
> Assignee: Stuart McCulloch
> Priority: Minor
> Attachments: package-inheritance-test.zip
>
>
> When maven-compiler-plugin is explicitly added to the build, inheritance
> dependencies are not resolved. For example, the attached test case uses
> org.springframework.jdbc.core.JdbcTemplate, which extends
> org.springframework.jdbc.support.JdbcAccessor (note the superclass lives in a
> different package). The method we invoke is defined on JdbcAccessor, hence
> the inheritance dependency. When the compiler plugin is included in the
> build, the bundle plugin fails to import the inherited
> org.springframework.jdbc.support package dependency. When the compiler
> plugin is taken out of the build, the bundle plugin correctly imports it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
