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.xm
Paulex Yang schrieb:
of course I trust every apache library blind to be downward compatible, but not
down to 0.0.1 pre Alpha rc1 ;)
> Soeren Strassfeld wrote:
>> Ilya Neverov schrieb:
>>
>> Hi Ilya,
>>
>> just followed your link, as I understand it, the endorsed mechanism is only
for API Classes,
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 b
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 featu
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 'ded
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 su
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
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
Actually I cannot right now estimate performance impact,
so we might want to find another solution
Thanks,
Mikhail
2006/4/12, Soeren Strassfeld <[EMAIL PROTECTED]>:
>
> > We can load those libraries by a dedicated class loader so that they
> > will be invisible for apps but visible for our 'bridg
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
Hi,
So you are able to run two different versions of one class within the
one jvm instance? This is cool,
and of course much more elegant tha
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 <[EMAIL PROTECTED]>:
> There are no other opinions but I believe this issue needs broader attention
> so I'd like to start
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 compat
12 matches
Mail list logo
