You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2006/04/11 10:15:38 UTC
External libraries in the bootclasspath (was: Version Conflict with bcel?)
There are no other opinions but I believe this issue needs broader attention
so I'd like to start another thread.
Harmony has a number of external libraries on the bootclasspath: ICU4C,
Xerces/Xalan. What if an app. uses the same library but another version?
What if library versions are not compatible? The possible way to resolve the
issue to perform repackaging (i.e. put everything external under
org.apache.harmony namespace, however I'm not sure that this applicable for
ICU4C library).
Are there other options?
Thanks,
Stepan Mishura
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: External libraries in the bootclasspath
Posted by Ilya Neverov <il...@gmail.com>.
Hi,
I think there are actually two issues mostly independent from each other.
1) How to ensure that differnt versions of some package (bunch of
classes) are compatible with the rest of JRE classes. Or combination
of versions of other classes.
I think it's a huge problem and demand for such feature should be
estimated first to balance it with work for implementing a solution
for this complex problem.
2) tech question - how to hide classes included in JRE bundle from
application which requires specific (newer or older) version of API
and implementation.
IMHO all 3 ways are good for that - repackaging, separating by means
of classloaders and rearranging bootclasspath (put endorsed before
system jar-files). I think 3rd one is the easiest way to provide JRE
with specific version of top-level component. By top-level I mean
functionality which isn't used by other components of JRE or is used
through very general API provided by most versions of that component.
JAXP (XML processing) is an example of such component.
On 4/14/06, Stepan Mishura <st...@gmail.com> wrote:
> Hi Soeren,
>
> I agree with you that this mechanism doesn't solve the issue with old
> library versions. And it doesn't prevent possible version conflicts with
> newer version so there is a chance that newer library version will break
> Harmony code. Right now I see only two alternatives repackaing and 'dedicated
> class loader' (as Mikhail suggested). IMHO we can repackage libraries in any
> but first it would be good to estimate how hard will be to implement the
> second approach.
>
> Thanks,
> Stepan.
>
--
Thank you.
Ilya Neverov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: External libraries in the bootclasspath
Posted by Stepan Mishura <st...@gmail.com>.
Hi Soeren,
I agree with you that this mechanism doesn't solve the issue with old
library versions. And it doesn't prevent possible version conflicts with
newer version so there is a chance that newer library version will break
Harmony code. Right now I see only two alternatives repackaing and 'dedicated
class loader' (as Mikhail suggested). IMHO we can repackage libraries in any
but first it would be good to estimate how hard will be to implement the
second approach.
Thanks,
Stepan.
On 4/14/06, Soeren Strassfeld wrote:
>
> Ilya Neverov schrieb:
>
> Hi Ilya,
>
> just followed your link, as I understand it, the endorsed mechanism is
> only for API Classes, which
> are developed outside the JCP. This contains the org.w3c, org.xml and
> the CORBA/omg packages, but
> not internally used packages. I guess sun in some way trusts those
> library vendors to be downward
> compatible, and so not break the API.
> And as you said, the endorsed.dir is only for newer versions of
> libraries (the docs explicitly
> points to this as well), so Applications, which depend on older
> versions, would still fail.
>
> Thanks,
> Soeren
>
> > Hi,
> >
> > I think we can follow standardized way in this case.
> >
> > On 4/11/06, Stepan Mishura <st...@gmail.com> wrote:
> >
> >> There are no other opinions but I believe this issue needs broader
> attention
> >> so I'd like to start another thread.
> >>
> >> Harmony has a number of external libraries on the bootclasspath: ICU4C,
> >> Xerces/Xalan. What if an app. uses the same library but another
> version?
> >> What if library versions are not compatible? The possible way to
> resolve the
> >> issue to perform repackaging (i.e. put everything external under
> >> org.apache.harmony namespace, however I'm not sure that this applicable
> for
> >> ICU4C library).
> >>
> >> Are there other options?
> >>
> >
> > Since J2SE 1.4 SUN introduced "Endorsed Standards Override Mechanism"
> > for helping users to survive with rapidly evolving versions of popular
> > libraries. This mechanism allows overriding implementation of some
> > packages included in JRE bundle; the list of packages can be found at
> > [1].
> >
> > Moreover, user can install external library providing version of
> > related public API which is newer than API included in given JRE and
> > this newer version of API becomes available for applications instead
> > of the version bundled with the JRE. This is intended for supporting
> > external API-s which are standardized outside of JCP, like CORBA or
> > SAX and DOM for XML processing. You can run an app on J2SE 1.4 with
> > DOM Level 3 API instead of DOM Level 2 bundled with jdk 1.4.
> >
> > It's quite easy-to-use mechanism – just put library's jar-files to the
> > <java-home>/lib/endorsed directory or point to their location with the
> > system property 'java.endorsed.dirs'. I suspect that it's easy for
> > implementation also. Looks like that putting referred jar-files before
> > system jar-files in bootclasspath would be enough to have such magic
> > :) I'm not sure that any certified JRE does check that provided
> > jar-files contain classes only related to the list of packages in [1]
> > so we would be compatible with them in this place.
> >
> > [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
> >
> >
> >> Thanks,
> >> Stepan Mishura
> >> Intel Middleware Products Division
> >>
> >
> > Thank you.
> > Ilya Neverov,
> > Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
-----------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: External libraries in the bootclasspath
Posted by Chris Gray <ch...@kiffer.be>.
On Friday 14 April 2006 10:51, Paulex Yang wrote:
> Soeren Strassfeld wrote:
> > Ilya Neverov schrieb:
> >
> > Hi Ilya,
> >
> > just followed your link, as I understand it, the endorsed mechanism is
> > only for API Classes, which
> > are developed outside the JCP. This contains the org.w3c, org.xml and
> > the CORBA/omg packages, but
> > not internally used packages. I guess sun in some way trusts those
> > library vendors to be downward
> > compatible, and so not break the API.
>
> I guess Harmony also trusts the introduced external dependent classlib.;)
>
> > And as you said, the endorsed.dir is only for newer versions of
> > libraries (the docs explicitly
> > points to this as well), so Applications, which depend on older
> > versions, would still fail.
>
> Jar versioning is a difficult issue in Java world (in fact more
> significant on Java EE world), maybe the official solution(I mean, the
> standard) is JSR-277, but we probably need to wait for Java 7 to provide
> the spec and RI. Not sure if other component mechanism like OSGi has
> provided good idea on this issue?
OSGi allows each "bundle" to specify which bundles it depends upon, optionally
including a version spec which uses the _Java 2 Package Versioning
Specification_,
http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: External libraries in the bootclasspath
Posted by Paulex Yang <pa...@gmail.com>.
Soeren Strassfeld wrote:
> Ilya Neverov schrieb:
>
> Hi Ilya,
>
> just followed your link, as I understand it, the endorsed mechanism is
> only for API Classes, which
> are developed outside the JCP. This contains the org.w3c, org.xml and
> the CORBA/omg packages, but
> not internally used packages. I guess sun in some way trusts those
> library vendors to be downward
> compatible, and so not break the API.
I guess Harmony also trusts the introduced external dependent classlib.;)
> And as you said, the endorsed.dir is only for newer versions of
> libraries (the docs explicitly
> points to this as well), so Applications, which depend on older
> versions, would still fail.
>
Jar versioning is a difficult issue in Java world (in fact more
significant on Java EE world), maybe the official solution(I mean, the
standard) is JSR-277, but we probably need to wait for Java 7 to provide
the spec and RI. Not sure if other component mechanism like OSGi has
provided good idea on this issue?
> Thanks,
> Soeren
>
>> Hi,
>>
>> I think we can follow standardized way in this case.
>>
>> On 4/11/06, Stepan Mishura <st...@gmail.com> wrote:
>>
>>> There are no other opinions but I believe this issue needs broader
>>> attention
>>> so I'd like to start another thread.
>>>
>>> Harmony has a number of external libraries on the bootclasspath: ICU4C,
>>> Xerces/Xalan. What if an app. uses the same library but another
>>> version?
>>> What if library versions are not compatible? The possible way to
>>> resolve the
>>> issue to perform repackaging (i.e. put everything external under
>>> org.apache.harmony namespace, however I'm not sure that this
>>> applicable for
>>> ICU4C library).
>>>
>>> Are there other options?
>>>
>>
>> Since J2SE 1.4 SUN introduced "Endorsed Standards Override Mechanism"
>> for helping users to survive with rapidly evolving versions of popular
>> libraries. This mechanism allows overriding implementation of some
>> packages included in JRE bundle; the list of packages can be found at
>> [1].
>>
>> Moreover, user can install external library providing version of
>> related public API which is newer than API included in given JRE and
>> this newer version of API becomes available for applications instead
>> of the version bundled with the JRE. This is intended for supporting
>> external API-s which are standardized outside of JCP, like CORBA or
>> SAX and DOM for XML processing. You can run an app on J2SE 1.4 with
>> DOM Level 3 API instead of DOM Level 2 bundled with jdk 1.4.
>>
>> It's quite easy-to-use mechanism – just put library's jar-files to the
>> <java-home>/lib/endorsed directory or point to their location with the
>> system property 'java.endorsed.dirs'. I suspect that it's easy for
>> implementation also. Looks like that putting referred jar-files before
>> system jar-files in bootclasspath would be enough to have such magic
>> :) I'm not sure that any certified JRE does check that provided
>> jar-files contain classes only related to the list of packages in [1]
>> so we would be compatible with them in this place.
>>
>> [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
>>
>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>
>> Thank you.
>> Ilya Neverov,
>> Intel Middleware Products Division
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: External libraries in the bootclasspath
Posted by Soeren Strassfeld <nc...@netcologne.de>.
Ilya Neverov schrieb:
Hi Ilya,
just followed your link, as I understand it, the endorsed mechanism is
only for API Classes, which
are developed outside the JCP. This contains the org.w3c, org.xml and
the CORBA/omg packages, but
not internally used packages. I guess sun in some way trusts those
library vendors to be downward
compatible, and so not break the API.
And as you said, the endorsed.dir is only for newer versions of
libraries (the docs explicitly
points to this as well), so Applications, which depend on older
versions, would still fail.
Thanks,
Soeren
> Hi,
>
> I think we can follow standardized way in this case.
>
> On 4/11/06, Stepan Mishura <st...@gmail.com> wrote:
>
>> There are no other opinions but I believe this issue needs broader attention
>> so I'd like to start another thread.
>>
>> Harmony has a number of external libraries on the bootclasspath: ICU4C,
>> Xerces/Xalan. What if an app. uses the same library but another version?
>> What if library versions are not compatible? The possible way to resolve the
>> issue to perform repackaging (i.e. put everything external under
>> org.apache.harmony namespace, however I'm not sure that this applicable for
>> ICU4C library).
>>
>> Are there other options?
>>
>
> Since J2SE 1.4 SUN introduced "Endorsed Standards Override Mechanism"
> for helping users to survive with rapidly evolving versions of popular
> libraries. This mechanism allows overriding implementation of some
> packages included in JRE bundle; the list of packages can be found at
> [1].
>
> Moreover, user can install external library providing version of
> related public API which is newer than API included in given JRE and
> this newer version of API becomes available for applications instead
> of the version bundled with the JRE. This is intended for supporting
> external API-s which are standardized outside of JCP, like CORBA or
> SAX and DOM for XML processing. You can run an app on J2SE 1.4 with
> DOM Level 3 API instead of DOM Level 2 bundled with jdk 1.4.
>
> It's quite easy-to-use mechanism – just put library's jar-files to the
> <java-home>/lib/endorsed directory or point to their location with the
> system property 'java.endorsed.dirs'. I suspect that it's easy for
> implementation also. Looks like that putting referred jar-files before
> system jar-files in bootclasspath would be enough to have such magic
> :) I'm not sure that any certified JRE does check that provided
> jar-files contain classes only related to the list of packages in [1]
> so we would be compatible with them in this place.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
>
>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>
> Thank you.
> Ilya Neverov,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: External libraries in the bootclasspath (was: Version Conflict with bcel?)
Posted by Ilya Neverov <il...@gmail.com>.
Hi,
I think we can follow standardized way in this case.
On 4/11/06, Stepan Mishura <st...@gmail.com> wrote:
> There are no other opinions but I believe this issue needs broader attention
> so I'd like to start another thread.
>
> Harmony has a number of external libraries on the bootclasspath: ICU4C,
> Xerces/Xalan. What if an app. uses the same library but another version?
> What if library versions are not compatible? The possible way to resolve the
> issue to perform repackaging (i.e. put everything external under
> org.apache.harmony namespace, however I'm not sure that this applicable for
> ICU4C library).
>
> Are there other options?
Since J2SE 1.4 SUN introduced "Endorsed Standards Override Mechanism"
for helping users to survive with rapidly evolving versions of popular
libraries. This mechanism allows overriding implementation of some
packages included in JRE bundle; the list of packages can be found at
[1].
Moreover, user can install external library providing version of
related public API which is newer than API included in given JRE and
this newer version of API becomes available for applications instead
of the version bundled with the JRE. This is intended for supporting
external API-s which are standardized outside of JCP, like CORBA or
SAX and DOM for XML processing. You can run an app on J2SE 1.4 with
DOM Level 3 API instead of DOM Level 2 bundled with jdk 1.4.
It's quite easy-to-use mechanism – just put library's jar-files to the
<java-home>/lib/endorsed directory or point to their location with the
system property 'java.endorsed.dirs'. I suspect that it's easy for
implementation also. Looks like that putting referred jar-files before
system jar-files in bootclasspath would be enough to have such magic
:) I'm not sure that any certified JRE does check that provided
jar-files contain classes only related to the list of packages in [1]
so we would be compatible with them in this place.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
Thank you.
Ilya Neverov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: External libraries in the bootclasspath (was: Version Conflict with bcel?)
Posted by Mikhail Loenko <ml...@gmail.com>.
We can load those libraries by a dedicated class loader so that they
will be invisible for apps but visible for our 'bridge' classes
Thanks,
Mikhail
2006/4/11, Stepan Mishura <st...@gmail.com>:
> There are no other opinions but I believe this issue needs broader attention
> so I'd like to start another thread.
>
> Harmony has a number of external libraries on the bootclasspath: ICU4C,
> Xerces/Xalan. What if an app. uses the same library but another version?
> What if library versions are not compatible? The possible way to resolve the
> issue to perform repackaging (i.e. put everything external under
> org.apache.harmony namespace, however I'm not sure that this applicable for
> ICU4C library).
>
> Are there other options?
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org