harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Wu <wuyue...@gmail.com>
Subject Re: xerces and xalan dependencies
Date Thu, 30 Apr 2009 02:28:25 GMT
I think it's a general idea which applies to all the dependencies such
as ICU, BouncyCastle, etc.

We need to understand one thing that is comparing to the side effect
of folking the src code, what benefits we can harvest. another is
whether they are allowed to be redistributed.

It should be disscussed case by case,

XML related
you have mentioned that we can
1. rebuild them to the same bytecode level
2. make them more natural as harmony modules.

It's the one which I want to customize as soon as I can. With ability
to change the src code and build, we can
1. remove the unnecessary cycle dependency from ICU code rather that a
work around in harmony code.
2. Improve performance - this area is one of the worst against RI.
3. remove unnecessary data and duplicate charsets to reduce the
disk/memory footprint

A quick test shows that it consumes more memories than RI - still dont
know why. but changes to the src code is definitely required to fix
that. Also we can do customization to include basic algorithms into
the core of Harmony Select which are just talking about to reduce the
size and achieve better modulization.

Anyone want to do this?

do we still need that? I see ASM has been included.

just to stimulate the discussion, need more thoughts.

On Thu, Apr 30, 2009 at 8:50 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
> I've been thinking about how we consume Xerces and Xalan, especially
> since we've had to do some of the more recent modifications to the
> build scripts to manipulate the JARs and archives in various ways. As
> an alternative to grabbing the binary packages, we could grab the
> source code itself and do our own builds. We could do this by grabbing
> the officially distributed source archives or we could checkout the
> code directly via svn:externals pointing to release tags (some risk in
> that).
> One advantage this has is that the code would be compiled at the
> bytecode level of our code (Xerces currently builds to support Java
> 1.3). The other would be a more natural fit into the classlib module
> structure, which would allow us to build and package manifests as well
> as additional tests.
> Just something I've been knocking around in my head. Any comments or
> additional thoughts?

Tony Wu
China Software Development Lab, IBM

View raw message