Stepan Mishura schrieb: Hi Stepan, I totally agree with you, Mikhails dedicated classloader solution would be the best, as no external source/bytecode would have to be changed (I guess, Mikhail??). For the second solution I´ve created jira-336 (works, but if you decide to use it in the standard build, it needs a lot of cleanup).
Mikhail, could you provide some infos how how a dedicated classloader should be implemented? (My knowledge on classloading is actually very poor) Thanks, Soeren > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > ----------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Thanks, > Stepan Mishura > Intel Middleware Products Division > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
