Tiny scala-library.jar

On Saturday April 9 2011, Jan Kotek wrote:
> Hi,
>
> I am not very happy with size of the Scala library (scala-
> library.jar). ...
>
> Please vote if you think this project would be usefull:
> http://www.surveymonkey.com/s/NGWQSZV

More subsets. I vote no.

With a tool such as ProGuard, you get exactly what you need / use. With
an arbitrary subset, you're hemmed in by the arbitrary definition of
the subset.

> Regards,
> Jan Kotek

Randall Schulz

some thoughts

- generally it's a good thing that there is more and more replacements for the java class library,
as this may lead to greater independence from java
- i think there are two contradicting goals,
a) small library
b) fast widely specialised library
; on the desktop i really wish more of the collections were specialised -- i haven't looked
into 2.9 much yet, but in 2.8 there is very little specialised, so i guess this may be a
reason why 2.9 is bigger (apart from parallel collections) ; 2.8.1 has 6.5 MB
; so if the assumption holds that the specialisation creates a lot of the size, you
may go with an unspecialised version being bundled with your mobile app?
i don't know if this is technically possible, but maybe worth a try
- forking doesn't make too much sense, IMO
- i agree that Proguard works but is not really the best solution. my bet is the different
packages of scala are already to a degree independent. obviously you will have
a core which is probably collections. but i could imagine that actors and xml are
completely independent and could thus be a separate jar, maybe others too
luch as logging, parsing. open question though if they account for a lot of the jar size...

best, -sciss-

On 9 Apr 2011, at 12:18, Jan Kotek wrote:

> Hi,
>
> I am not very happy with size of the Scala library (scala-
> library.jar). In 2.9 it is 8MB.
> It is not good for andorid apps, applets and desktop applications.
> Pro-guard works, but it still enough. It reimplements lot of stuff
> which is already
> included in Java class path (mutable collections, xml...).
>
> I am thinking about starting tiny fork. An library which would
> replace
> original Scala library, but would still allow to use most of Scala
> magic.
> It would rely heavily on Java classpath classes, mostly just thin
> wrapper
> around Java implementation.
> It would not support immutability and concurrency that well (not so
> hot on Android).
>
> I hope to get scala-library-tiny.jar with size around 200 kB.
> It should be compatible with mainstream scala-library.jar at source
> code level
> (ie just replace library jars and recompile).
>
> Please vote if you think this project would be usefull:
> http://www.surveymonkey.com/s/NGWQSZV
>
> Regards,
> Jan Kotek
>
>
>
>
>

On 09/04/2011 17:32, Sciss wrote:
> - i agree that Proguard works but is not really the best solution. my bet is the different
> packages of scala are already to a degree independent. obviously you will have
> a core which is probably collections. but i could imagine that actors and xml are
> completely independent and could thus be a separate jar, maybe others too
> luch as logging, parsing. open question though if they account for a lot of the jar size...

Interesting question. I unzipped the jar, it takes 22.8 MiB of classes.
WinDirStat says that the biggest folder is indeed collections, taking
64% of the total, 14.6 MiB, 1977 classes.

Then comes the files directly under the scala package: 8%, 1.9 MiB, 890
classes (the 22 variants of Function, Product, Tuple, and some more).
Then, close to 1 MiB, comes util, actors, xml, reflect, with ~600
classes (util) and around 300 for the others.

Then comes in decreasing order math, sys, runtime, concurrent, io,
testing, mobile, text, ref, annotation, parallel and compat.

In collection, the parallel package is the biggest: 4 MiB, 653 classes
(28% of the total). Then, files at the top of the package (4 MiB, 506
classes). Then immutable (3.5 MiB, 343 classes) and mutable (2.9 MiB,
326 classes) and the small generic, script and interface packages.

So, indeed, collection is the biggest package, and dropping parallel
(just sticking to 2.8?) can be a big gain.
Then again, ProGuard can do that, no?
I am not sure that reimplementing only mutable collections on top of
Java classes while keeping the rich set of methods will reduce this
package in a significant way.

The idea is interesting, but I don't know if the effort is worth the result.

On Sat, Apr 9, 2011 at 7:18 AM, Jan Kotek <kjan80@gmail.com> wrote:

I hope to get scala-library-tiny.jar with size around 200 kB.

What is this estimate based on?

It should be compatible with mainstream scala-library.jar at source
code level

Even if you get it to compile with a scala-library API wrapper around the Java standard library, what semantics will it have at runtime?

How many hours are you expecting this to take you?

200kB is more like goal, I will simply stop adding classes when I reach that size. 
>Even if you get it to compile with a scala-library API wrapper around the Java standard library, what semantics will it have at runtime? It should mimic Scala API very closely. So it should have basic classes like Product, List, Function... Some annotations for compiler...
I have no idea about time.

Jan

On Sun, Apr 10, 2011 at 4:47 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

On Sat, Apr 9, 2011 at 7:18 AM, Jan Kotek <kjan80@gmail.com> wrote:

I hope to get scala-library-tiny.jar with size around 200 kB.

What is this estimate based on?

It should be compatible with mainstream scala-library.jar at source
code level

Even if you get it to compile with a scala-library API wrapper around the Java standard library, what semantics will it have at runtime?

How many hours are you expecting this to take you?

Hi,
in survey there were 15 votes, and only 2 were positive. Most people is worried about Scala fragmentation.
So I am not going to start this project.
Thanks, Jan Kotek
On Sat, Apr 9, 2011 at 12:18 PM, Jan Kotek <kjan80@gmail.com> wrote:

Hi,

I am not very happy with size of the Scala library (scala-
library.jar). In 2.9 it is 8MB.
It is not good for andorid apps, applets and desktop applications.
Pro-guard works, but it still enough. It reimplements lot of stuff
which is already
included in Java class path (mutable collections, xml...).

I am thinking about starting tiny fork. An library which would
replace
original Scala library, but would still allow to use most of Scala
magic.
It would rely heavily on Java classpath classes, mostly just thin
wrapper
around Java implementation.
It would not support immutability and concurrency that well (not so
hot on Android).

I hope to get scala-library-tiny.jar with size around 200 kB.
It should be compatible with mainstream scala-library.jar at source
code level
(ie just replace library jars and recompile).

Please vote if you think this project would be usefull:
http://www.surveymonkey.com/s/NGWQSZV

Regards,
Jan Kotek

Hi,

If it is not fully compatible with Scala, I vote for no.
I was able to get a **full working scala-library.jar*** with Proguard
and pack200 down to below 700 kB.

However, what I would like more is to have some parts of Scala kept in
separate jars. Like collections - one jar, parser combinators and actors
in a separate ones, etc. Getting it slightly more modular would be good
for applications that are not distributed as a single proguarded jar.
However, it is not top priority for me. Much more important are other
things like e.g. IDE support (IntelliJ IDEA is great, but a little
sluggish) or faster compilation (parallel anyone?).

Regards,
Piotr

W dniu 2011-04-09 13:18, Jan Kotek pisze:
> Hi,
>
> I am not very happy with size of the Scala library (scala-
> library.jar). In 2.9 it is 8MB.
> It is not good for andorid apps, applets and desktop applications.
> Pro-guard works, but it still enough. It reimplements lot of stuff
> which is already
> included in Java class path (mutable collections, xml...).
>
> I am thinking about starting tiny fork. An library which would
> replace
> original Scala library, but would still allow to use most of Scala
> magic.
> It would rely heavily on Java classpath classes, mostly just thin
> wrapper
> around Java implementation.
> It would not support immutability and concurrency that well (not so
> hot on Android).
>
> I hope to get scala-library-tiny.jar with size around 200 kB.
> It should be compatible with mainstream scala-library.jar at source
> code level
> (ie just replace library jars and recompile).
>
> Please vote if you think this project would be usefull:
> http://www.surveymonkey.com/s/NGWQSZV
>
> Regards,
> Jan Kotek
>
>
>
>
>
>

Splitting the core lib into jars is something I'd love to see. For small-footprint applications, how much does specialisation of the collections make a difference? If specialisation is the root of bloat here and progard et. al. can't shrink this down again, Would it be possible to bundle the core libs with and without specialisation?
Matthew

2011/4/10 Piotr Kołaczkowski <pkolaczk@elka.pw.edu.pl>

Hi,

If it is not fully compatible with Scala, I vote for no.
I was able to get a **full working scala-library.jar*** with Proguard and pack200 down to below 700 kB.

However, what I would like more is to have some parts of Scala kept in separate jars. Like collections - one jar, parser combinators and actors in a separate ones, etc. Getting it slightly more modular would be good for applications that are not distributed as a single proguarded jar. However, it is not top priority for me. Much more important are other things like e.g. IDE support (IntelliJ IDEA is great, but a little sluggish) or faster compilation (parallel anyone?).

Regards,
Piotr



W dniu 2011-04-09 13:18, Jan Kotek pisze:

Hi,

I am not very happy with size of the Scala library (scala-
library.jar). In 2.9 it is 8MB.
It is not good for andorid apps, applets and desktop applications.
Pro-guard works, but it still enough. It reimplements lot of stuff
which is already
included in Java class path (mutable collections, xml...).

I am thinking about starting tiny fork. An library which would
replace
original Scala library, but would still allow to use most of Scala
magic.
It would rely heavily on Java classpath classes, mostly just thin
wrapper
around Java implementation.
It would not support immutability and concurrency that well (not so
hot on Android).

I hope to get scala-library-tiny.jar with size around 200 kB.
It should be compatible with mainstream scala-library.jar at source
code level
(ie just replace library jars and recompile).

Please vote if you think this project would be usefull:
http://www.surveymonkey.com/s/NGWQSZV

Regards,
Jan Kotek

--
Matthew Pocockmailto: turingatemyhamster@gmail.comgchat: turingatemyhamster@gmail.com msn: matthew_pocock@yahoo.co.ukirc.freenode.net: drdozer(0191) 2566550

>>>>> "Matthew" == Matthew Pocock writes:

Matthew> Splitting the core lib into jars is something I'd love to
Matthew> see. For small-footprint applications, how much does
Matthew> specialisation of the collections make a difference? If
Matthew> specialisation is the root of bloat here and progard
Matthew> et. al. can't shrink this down again, Would it be possible to
Matthew> bundle the core libs with and without specialisation?

I'd like to have an unspecialized version I could use in applets.