On Tuesday 20 September 2005 00:07, Jeff McAffer wrote:
> There is Java visibility and there is the ability of A to actually
> directly reference C. Of course class C has to be available to load class
> A but that does not mean that bundle A's classloader has to be able to see
> class C. It just needs to know someone (e.g., bundle B) who can. So, any
> direct reference to C's classes from A should fail unless A explicitly
> states a dependency (Import-Package or Require-Bundle) that makes them
> visible. At build/compile time, this means that setting up the classpath
> for compilation is more complicated.
Huh?? Example;
public class A extends B
{
public A()
{
System.out.println( "Message: " + getMessage() );
}
}
public class B extends C
{
}
public class C
{
protected String getMessage()
{
return "Hello";
}
}
Are you saying that it is a legal construct to have a Classloader for A that
does not have class C visible?? And yet, that the getMessage() is called
properly?
Would be interested to hear how the JLS could allow that?
That would also imply that,
public class D
{
private C m_member;
public D( A instance )
{
m_member = instance;
}
}
would also be legal even if class B is not visible to class D's classloader.
Is that right?
Also;
<quote>
So, any direct reference to C's classes from A should fail
</quote>
Are you talking about inner classes in C, or is "A extends B extends C" some
form of "bundle" inheritance, or something??
> I will leave
> the religious arguments about Require-Bundle and Import-Package aside and
> note that both are part of the spec.
Ok, even though the rumour is that it was introduced to ease migration within
Eclipse ;o)
> Are you suggesting that Maven should be unable to build bundles that use
> Require-Bundle?
No. I thought I said that having a Maven dependency resulting in a
Require-Bundle entry in the manifest is not the right solution.
<rant type="high school philosophy" >
Premise; "If it is raining, it is blowing."
Condition; "It is blowing."
Conclusion about raining; N/A.
</rant>
I assume that Require-Bundle will be "marketed" as a "last resort" or "special
cases", since it doesn't rhyme well with "service replacements" and
"alternative implementations", which I thought was central to OSGi.
That would imply that the Maven plaugin has a mechanism to create the
Require-Bundle entry, but require some form of additional "enable".
Cheers
Niclas
