harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spark Shen" <smallsmallor...@gmail.com>
Subject Re: [general] jre bundle size
Date Wed, 17 Oct 2007 06:02:46 GMT
17 Oct 2007 09:49:08 +0400, Egor Pasko <egor.pasko@gmail.com>:
>
> On the 0x372 day of Apache Harmony Spark Shen wrote:
> > 2007/10/17, Sean Qiu <sean.xx.qiu@gmail.com>:
> > >
> > > I suggest we maintain our classlib modules (jar) in a central
> repository.
> > > So we can just get a kernel bundle, and it will download the required
> > > jars.
> >
> >
> > +1 for kernel bundle.
> >
> > We can add options for the default build task. Using these options to
> > determine whether
> > to include source code ,debug information etc.
> >
> > And what about  and a new build target 'build-core' for only those
> kernel
> > bundles necessary
> > to start JRE.
>
> Sorry, guys:
> -1
>
> First of all, -1 to removing debug information. When you need it, it
> is time when you really need it and you are really stuck and blaming
> your JRE for various aspects if debug info is not there.


IMHO, reduce the bundle size is a reasonable suggestion Removing source code
and debug symbol table
is just an option. It is better to leave the choice for user to decide
whether they want to also download those
auxiliary content.

I agree with you that debug information is important, but make it a option
for user is not a harm.

For other parts such as JDK tools, they may not appealing to all users. And
as before, we can
still provide the full build.

Secondly, to the kernel bundle:
>
> 1. how many people want to download just 1/3 of the JRE and then keep
>    looking of the damn slow download when running some app? This would
>    be an unpleasant surprize because people just did not ask you to go
>    web. Looks suspicious, slow and ugly. I do not like unpleasant
>    surpizes.
>
> 2. it is a lot of work. We will need to identify places that can be
>    stripped, tweak classloader to download stuff instead of throwing
>    complains. Ideally, we will need to measure user experience: how
>    many users did not want to download more, and what we can do to
>    increase the number of users? Seems pretty hard. So, unless
>    somebody has a good design in their mind, I would object to this
>    effort. And if they have, please, publish the design on wiki.
>
> 3. how about permissions? anyone who runs a Java app is sometimes
>    asked for a root password to update the JRE? not very convenient
>
> 4. I believe Linux package managers would anyway stick to the full
>    package (otherwize it turns to a nightmare of permissions, security
>    issues and such). So, we won't get any lovers of this stuff in the
>    Linux community, which is completely not impressing.
>
> Slow, ugly, surprizing unpleasantly, vulnerable to attacks. gosh.
>
> If Sun likes that, just let them have fun.
>
>
> > 2007/10/17, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > > >
> > > > Good idea. Information shows that SUN JRE6 update N introduced a
> > > > faster installation and update technology, so that only part of the
> > > > JRE needs to be downloaded.
> > > >
> > > > Harmony has very good modularity design, which our
> > > > installation/bundles should be able to leverage.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > On 10/17/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > > > > Guys,
> > > > >
> > > > > we got huge size of jre bundle... For example the size of RI's jre
> is
> > > > > about 16Mb but Harmony's one is about 38Mb...
> > > > >
> > > > > I believe that we should reduce the size of this bundle.
> > > > > The obvious candidates to remove are source code and debug
> information
> > > > > from class files. This  can reduce the size significantly but not
> > > > > enough...
> > > > >
> > > > > Thoughts? Ideas? Volunteers? :)
> > > > >
> > > > > Thanks in advance.
> > > > >
> > > > > SY, Alexey
> > > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> > >
> > >
> > > --
> > > Sean Qiu
> > > China Software Development Lab, IBM
> > >
> >
> >
> >
> > --
> > Spark Shen
> > China Software Development Lab, IBM
>
> --
> Egor Pasko
>
>


-- 
Spark Shen
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message