felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-532) Package inheritance dependencies are not imported when maven-compiler-plugin is defined in build
Date Thu, 10 Apr 2008 10:22:09 GMT

    [ 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...


"    * 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.

View raw message