Android aapt --non-constant-id anyone?

[Fabrizio Giudici]

aapt options say:
...
--non-constant-id
Make the resources ID non constant. This is required to make an
R java class
that does not contain the final value but is used to make
reusable compiled
libraries that need to access resources.

It could resolve a problem of mine, but I can't see any difference in
the output; above all, I can't find any reference on the internet (this
thing would be useful to see what the option has been designed for and
whether it's similar to what I'm searching for). Does the option really
exist or is it a phantom?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Xavier Ducrohet]

(I don't think this is the right mailing list for this, but since I'm
reading it...)

This is in preparation of better Library Project support. Right now
they are used in source form and I'd like to be able to have library
as a jar file and a set of resources instead.

Generating non constant id for R.*.* will make these values not
inlined when compiled, so that only the final id value (generated from
the full set of resources coming from the project and libraries) is
used.

This is not used anywhere are this time though. We're still working on it.

Xav

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Fabrizio Giudici]

On 06/22/2011 12:00 AM, Xavier Ducrohet wrote:
> (I don't think this is the right mailing list for this, but since I'm
> reading it...)
>
> This is in preparation of better Library Project support. Right now
> they are used in source form and I'd like to be able to have library
> as a jar file and a set of resources instead.
>
> Generating non constant id for R.*.* will make these values not
> inlined when compiled, so that only the final id value (generated from
> the full set of resources coming from the project and libraries) is
> used.
>
> This is not used anywhere are this time though. We're still working on it.

Thanks. Yes, the constant inlining is the problem I was facing yesterday
and it's for reusing stuff. I could be blogging on the experimental work
I'm doing soon (but not sure, it's a hard week), in any case at the
moment I've solved it by patching the R.java generated in this way (I'm
using Maven, so I'm patching the code after it is generated by aapt):

public static final int view_news= (null != null) ? 0 :0x7f030001;

as per suggestion from
http://stackoverflow.com/questions/3524150/is-it-possible-to-disable-javacs-inlining-of-static-final-variables
- I can confirm that in this way there's still a constant, but it is not
inlined. Not having a constant, in the end, would cause some other
problem for me, as I suspect non constant ids couldn't be used as
parameters to annotations (e.g. RoboGuice offers annotations to inject
references into variables).

Now - and here's why I posted here, with a lot of cross-domain experts
;-) - I don't know if the trick of putting an expression in a constant
definition is guaranteed and will always guarantee that the constant is
not inlined. The same post at StackOverflow mentions the use of dummy
functions as suggested by Joshua Bloch, so it should be some consistent
stuff. But, e.g., will it work also for Java 7 etc?

PS For the non Android guys, R.java is a generated source containing int
ids referring to resources that are precompiled from an xml file. The
values assigned to the constants are not controllable from the
programmer and if you add/remove/change order of the stuff they will
change. You need to have a R.java otherwise you can't compile your code.
If you want to reuse some code _but_ with different resources (e.g. a
different screen layout) a apparently simple solution is to remove the
original R from a jar file and replace with another containing the same
constants (with different values). But the javac compiler inlines
constants, so without disabling this compiler feature the replacement
operation is unsuccessful.

[Cédric Beust ♔]

On Tue, Jun 21, 2011 at 11:39 PM, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:

On 06/22/2011 12:00 AM, Xavier Ducrohet wrote:

(I don't think this is the right mailing list for this, but since I'm
reading it...)

This is in preparation of better Library Project support. Right now
they are used in source form and I'd like to be able to have library
as a jar file and a set of resources instead.

Generating non constant id for R.*.* will make these values not
inlined when compiled, so that only the final id value (generated from
the full set of resources coming from the project and libraries) is
used.

This is not used anywhere are this time though. We're still working on it.

Thanks. Yes, the constant inlining is the problem I was facing yesterday and it's for reusing stuff. I could be blogging on the experimental work I'm doing soon (but not sure, it's a hard week), in any case at the moment I've solved it by patching the R.java generated in this way (I'm using Maven, so I'm patching the code after it is generated by aapt):

public static final int view_news= (null != null) ? 0 :0x7f030001;

Does this work? It looks like the compiler should be able to optimize this.

-- 

Cédric
 

[Fabrizio Giudici]

On 06/22/2011 02:51 PM, Cédric Beust ♔ wrote:
>
>
> Does this work? It looks like the compiler should be able to optimize
> this.
>

Funny, eh? Frankly, I was unaware of the inlining problem (or I forgot
about it). After reading the stuff, I'd say the same as you, that the
compiler should optimize out anyway, but it indeed works. I've tried
splitting a single project into three modules, and replacing R as I said
in my earlier post, and with that trick it works - javac 1.6.0_24 and
this Maven configuration:

<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<debug>true</debug>
<optimize>true</optimize>
<source>1.5</source>
<target>1.5</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<fork>true</fork>
<compilerArgument>-Xlint:all</compilerArgument>
</configuration>
</plugin>

So, optimizations are in.
But how long will it work?

[Cédric Beust ♔]

On Wed, Jun 22, 2011 at 6:08 AM, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:

On 06/22/2011 02:51 PM, Cédric Beust ♔ wrote:

Does this work? It looks like the compiler should be able to optimize this.

Funny, eh? Frankly, I was unaware of the inlining problem (or I forgot about it). After reading the stuff, I'd say the same as you, that the compiler should optimize out anyway, but it indeed works.

Indeed:

    int n = null != null ? 0 : 1;

public static void main(java.lang.String[]);

  Code:

   0:   aconst_null

   1:   ifnull  8

   4:   iconst_0

   5:   goto    9

   8:   iconst_1

   9:   istore_1

   10:  return

}

Amazing, and disappointing too. If javac misses that, what else is it missing?

-- 

Cédric

[Fabrizio Giudici]

On 06/22/2011 03:14 PM, Cédric Beust ♔ wrote:
> Amazing, and disappointing too. If javac misses that, what else is it
> missing?

OTOH, I'm wondering whether this is irrelevant from the performance
perspective as the JIT will optimize it correctly...

[Cédric Beust ♔]

2011/6/22 Fabrizio Giudici <fabrizio...@tidalwave.it>

On 06/22/2011 03:14 PM, Cédric Beust ♔ wrote:

Amazing, and disappointing too. If javac misses that, what else is it missing?

OTOH, I'm wondering whether this is irrelevant from the performance perspective as the JIT will optimize it correctly...

Probably (although I'm not sure, since it's a one time initialization, isn't it exactly what a JIT would not bother with?), but it's such an easy peephole optimization (constant expression) that I would think this kind of thing would be in the 1.0 version of a compiler...

-- 

Cédric