android: Pass list of java files as command line, instead of through a file list.

android: Pass list of java files as command line, instead of through a file list.

There aren't that many java files, so this should be well below the command
length file system limit. (Checked with `find. -name '*.java' | wc`).

No intended behavior change.

BUG=177552
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257467

[Nico, 2014-03-14 16:23:35]

What do you think of this? It's a bit less code, and fewer files getting
generated. It should be pretty safe command-line length wise, given that we have
way more cc files than java files, and all .o files are passed on the linker
too. (Or used to, until 2 days ago, when content became too big to fit in a
command line.)

[cjhopman, 2014-03-17 17:35:28]

On 2014/03/14 16:23:35, Nico (on GMT time Mar 15 - 24) wrote:
> What do you think of this? It's a bit less code, and fewer files getting
> generated. It should be pretty safe command-line length wise, given that we
have
> way more cc files than java files, and all .o files are passed on the linker
> too. (Or used to, until 2 days ago, when content became too big to fit in a
> command line.)

What is the command line length limit? Looks like our large internal java
library is ~50k worth of java paths.

This also makes the command much longer, which could make figuring out what is
wrong with it harder-- but we print all the java files anyway when the javac
call fails so I'm not worried about that.

[Nico, 2014-03-17 17:56:00]

On 2014/03/17 17:35:28, cjhopman wrote:
> On 2014/03/14 16:23:35, Nico (on GMT time Mar 15 - 24) wrote:
> > What do you think of this? It's a bit less code, and fewer files getting
> > generated. It should be pretty safe command-line length wise, given that we
> have
> > way more cc files than java files, and all .o files are passed on the linker
> > too. (Or used to, until 2 days ago, when content became too big to fit in a
> > command line.)
> 
> What is the command line length limit? Looks like our large internal java
> library is ~50k worth of java paths.

The cros builder started failing to link libcontent.so when the link command
grew longer than 128 kiB last week, so I'd guess that's the limit. So I think
that should be fine for now?

> This also makes the command much longer, which could make figuring out what is
> wrong with it harder-- but we print all the java files anyway when the javac
> call fails so I'm not worried about that.

[cjhopman, 2014-03-17 17:58:26]

On 2014/03/17 17:56:00, Nico (on GMT time Mar 15 - 24) wrote:
> On 2014/03/17 17:35:28, cjhopman wrote:
> > On 2014/03/14 16:23:35, Nico (on GMT time Mar 15 - 24) wrote:
> > > What do you think of this? It's a bit less code, and fewer files getting
> > > generated. It should be pretty safe command-line length wise, given that
we
> > have
> > > way more cc files than java files, and all .o files are passed on the
linker
> > > too. (Or used to, until 2 days ago, when content became too big to fit in
a
> > > command line.)
> > 
> > What is the command line length limit? Looks like our large internal java
> > library is ~50k worth of java paths.
> 
> The cros builder started failing to link libcontent.so when the link command
> grew longer than 128 kiB last week, so I'd guess that's the limit. So I think
> that should be fine for now?
> 
> > This also makes the command much longer, which could make figuring out what
is
> > wrong with it harder-- but we print all the java files anyway when the javac
> > call fails so I'm not worried about that.

Agreed. lgtm.

[Nico, 2014-03-17 18:17:07]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2014-03-17 18:17:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/thakis@chromium.org/197213006/1

[commit-bot: I haz the power, 2014-03-17 18:23:18]

Change committed as 257467