Kawa payload size in trivial android apps

Kawa payload size in trivial android apps

[Marius Kjeldahl]

Since I've now managed to integrate kawa with java builds using the
android gradle plugin, I just wanted to share some brief, but very
encouraging numbers. I pretty much created a minimal sample app using
Android Studio with the recognizable taskbar and related libraries.

The two libraries that get included by "standard" are the support-v4
and appcompat-v7 (the build tools version 19.0.1 versions). Their file
sizes (.jar/.aar) are 628kb and 595kb respectively. For comparison,
the kawa.jar file I built is 2.67mb.

But most apps released gets run through proguard before relases, which
typically tries to make things smaller and remove unused code.

Without the kawa stuff, but after running through proguard, the hello
world skeleton app apk created by Android Studio (showing a taskbar,
menu and a default view with a text line) is around 450kb.

With a kawa version in addition to the java version, the apk size only
grows with some 115kb. Based on my experience the kawa stuff will grow
a bit larger initially as more of the kawa standard library gets
pulled in, but eventually growth will slow down again (as only "new
code" written by yourself gets added).

For comparison my plain java Android app on the play store
("Killermatch" - a racket sport match diary) is 1.2mb, of which half
are support libraries (play store and related services). My other app
is a cross platform java game using libgdx ("Math Pyramids") is 3.9mb,
mostly libgdx libraries (it has native opengl, audio, physics
libraries in it).

The good news is that the extra payload size that kawa seems to add is
neglible for anything but the smallest of utilities on the Play Store.

Per, where do I sign up for petitioning for a "join-source" version of
the kawa compiler (one that would recognize and reconcile cross
language dependencies, similar to the groovy and scala compilers...)?
Yeah, patches, I know.. ;-)

Anyway, I'm running out of excuses for keep building apps using just
plain java, which is a good thing I believe. ;-)

Thanks,

Marius K.

Re: Kawa payload size in trivial android apps

[Per Bothner]

On 02/28/2014 02:48 PM, Marius Kjeldahl wrote:
> The good news is that the extra payload size that kawa seems to add is
> neglible for anything but the smallest of utilities on the Play Store.

That's good to hear. I've worked on a "kawart.jar" that leaves out the
"Kawa compiler" but perhaps a tool like proguard makes that lower priority.

> Per, where do I sign up for petitioning for a "join-source" version of
> the kawa compiler (one that would recognize and reconcile cross
> language dependencies, similar to the groovy and scala compilers...)?
> Yeah, patches, I know.. ;-)

Patches - or money.

Ideally, the best way for two mixed-language source would be to build on
javac. I.e. you write an extension to javac to "calls back" into the 
Kawa compiler.
You'd write wrapper classes that match what javac expects, but that wrap
the similar kawac classes.  This would be a non-trivial job, and requires
building familiar with but javac internals and Kawa. When I worked on
JavaFX Script I used to know my way around javac, but I'm a bit rusty now.

The easier approach (used by Grovey and Scala, I believe) is to compile
twice: Compile the Kawa to stub classes; compile the Java code; do the
real compile of the Kawa classes.

Exactly how to compile to stub class is non-obvious.  It helps if you know
the names of the Java classes, which is why hooking into javac is 
preferable.

Could be a Google Summer of Code project.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Kawa payload size in trivial android apps

[Jamison Hope]

On Feb 28, 2014, at 6:59 PM, Per Bothner <per@bothner.com> wrote:

> Ideally, the best way for two mixed-language source would be to build on
> javac. I.e. you write an extension to javac to "calls back" into the Kawa compiler.
> You'd write wrapper classes that match what javac expects, but that wrap
> the similar kawac classes.  This would be a non-trivial job, and requires
> building familiar with but javac internals and Kawa. When I worked on
> JavaFX Script I used to know my way around javac, but I'm a bit rusty now.

Does stock javac have hooks for this kind of thing already, in which case
the only thing to do is write the Kawa-specific piece that fits the API,
or would this be a new feature for javac that we would need to get pushed
into the JDK sources?

> The easier approach (used by Grovey and Scala, I believe) is to compile
> twice: Compile the Kawa to stub classes; compile the Java code; do the
> real compile of the Kawa classes.
> 
> Exactly how to compile to stub class is non-obvious.  It helps if you know
> the names of the Java classes, which is why hooking into javac is preferable.
> 
> Could be a Google Summer of Code project.

Let's add it to the list!

--
Jamison Hope
The PTR Group
www.theptrgroup.com

Re: Kawa payload size in trivial android apps

[Per Bothner]

On 03/02/2014 07:33 AM, Jamison Hope wrote:
> On Feb 28, 2014, at 6:59 PM, Per Bothner <per@bothner.com> wrote:
>
>> Ideally, the best way for two mixed-language source would be to build on
>> javac. I.e. you write an extension to javac to "calls back" into the Kawa compiler.
>> You'd write wrapper classes that match what javac expects, but that wrap
>> the similar kawac classes.  This would be a non-trivial job, and requires
>> building familiar with but javac internals and Kawa. When I worked on
>> JavaFX Script I used to know my way around javac, but I'm a bit rusty now.
>
> Does stock javac have hooks for this kind of thing already, in which case
> the only thing to do is write the Kawa-specific piece that fits the API,
> or would this be a new feature for javac that we would need to get pushed
> into the JDK sources?

In principle the former: Javac is very "pluggable".  For JavaFX Script 
we extended
various javac classes.  However, we may run into cases that are not well 
tested.
I vaguely remember for JavaFX Script we did have to change various 
methods or fields
from private to protected, and things like that.

If nothing else, it seems a useful "research" project.

I'll bring it up on the jvmlangs list.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Kawa payload size in trivial android apps

[Per Bothner]

I added a idea for "Mutually dependent Java and Scheme modules" here:
http://www.gnu.org/software/kawa/Ideas-and-tasks.html
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Kawa payload size in trivial android apps

[Marius Kjeldahl]

Just want to say thanks for the detailed explanations, fixes and
suggestions for future ideas. What I've got now should be sufficient
to get started on some projects and articles.

Thanks,

Marius K.


On Wed, Mar 5, 2014 at 1:43 AM, Per Bothner <per@bothner.com> wrote:
> I added a idea for "Mutually dependent Java and Scheme modules" here:
> http://www.gnu.org/software/kawa/Ideas-and-tasks.html
>
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/