It sounds like I've missed something, but why exclude build time
generation? I punted the idea because these are values which are
determined once the build starts (i.e. when the target has been
specified) and don't alter once the build has completed, so build time
sounds the right place to generate the file containing them.
An further problem with a dictionary style API (beyond the checking one)
is a performance penalty. Using a get("android.build.property.XXXX")
would typically involve converting "android.build.property.xxxx" into
some value which is then used in a lookup (e.g. an index into an array,
or a hash into a table). This type of solution can't be optimised by
compilers or JITs because it's impossible to predict all the possible
parameter values and corresponding return values without actually
running all possible use cases for all uses of the method (and I don't
know of a single compiler which will try to do that).
There is also the question of is dynamic expansion a desirable goal?
Dave Bort has already said that system properties are becoming a bit of
a dumping ground, would allowing dynamic expansion simply move the
dumping ground onto a new site and avoid the underlying problem of
people not considering alternatives but just adding their own variable
in just because that's the way it's been done elsewhere?
In the end the use of final statics against a dynamically expandable API
may just be a few clock cycles, but I come from a background of coding
for 68000 embedded systems and Psions in the 90's and J2ME earlier this
decade, so I'm an every clock cycle counts type of guy :).
Al.
Jean-Baptiste Queru wrote:
> Like I wrote in the original requirements, auto-generating java files
> as part of the build process is explicitly something that we don't
> want to do. That's why Joe's initial suggestion (and his current
> recommendation) is to use an API based on functions, not members, such
> that the list of values can be expanded dynamically without having to
> change the API.
>
> JBQ
>
> On Wed, Jan 21, 2009 at 12:48 AM, Al Sutton <[email protected]> wrote:
>
>> Looks good to me, it's an improvement over the existing code because
>> dereferencing a static final variable will give any compiler or JIT a
>> very strong hint that it's safe to substitute the value directly into
>> the places where it's used at compile time as opposed to generating code
>> which goes through the process of setting up and executing a method call
>> each time the value is needed.
>>
>> On the implementation detail, how does generating the Config.java file
>> as part of the build process sound? As I see it the properties are most
>> likely going to be dependant on the build target so rather than having
>> multiple Config.java's for dev, non-Google build, and Google Build, why
>> not patch the build system to generate the correct values?
>>
>> Al.
>>
>> Jean-Baptiste Queru wrote:
>>
>>> I've uploaded a proposed implementation with the following changes:
>>> http://review.source.android.com/8415
>>> http://review.source.android.com/8256
>>> http://review.source.android.com/8416
>>> http://review.source.android.com/8257
>>>
>>> Please don't pay too much attention to the fact that the parameter is
>>> backed by a system property, that's an implementation detail at this
>>> point. I'm mostly interested in knowing whether this approach is
>>> sustainable in the future.
>>>
>>> Thanks,
>>> JBQ
>>>
>>> On Fri, Jan 16, 2009 at 4:30 PM, Jean-Baptiste Queru <[email protected]>
>>> wrote:
>>>
>>>
>>>> Agreed. The explicitly goal here is to avoid the use of an additional
>>>> system property (well, undo it, or at least hide it behind an API that
>>>> we'll be able to re-implement some other way).
>>>>
>>>> JBQ
>>>>
>>>> On Fri, Jan 16, 2009 at 4:18 PM, Brian Swetland <[email protected]>
>>>> wrote:
>>>>
>>>>
>>>>> As a side-note I'd like to try to reduce usage of the underlying system
>>>>> properties -- they're becoming a dumping ground for all kinds of random
>>>>> stuff, and they were not really intended as an open-ended registry of
>>>>> every possible thing we might think to dump in there....
>>>>>
>>>>> [Dave Bort <[email protected]>]
>>>>>
>>>>>
>>>>>> The major benefit of using static final fields that I see is that it
>>>>>> becomes very obvious who is using a given flag (e.g., "provisioned"),
>>>>>> we can track the existence of that flag using our existing API
>>>>>> checking tools, and the build breaks if a flag is removed but there
>>>>>> are users of it.
>>>>>>
>>>>>> A dictionary-style interface, on the other hand, provides no
>>>>>> possibility for static checking; there's no way to tell whether or not
>>>>>> anyone is using a particular flag. This is the main reason we're
>>>>>> trying to kill the uses of the SystemProperties API.
>>>>>>
>>>>>> --dbort
>>>>>>
>>>>>> On Fri, Jan 16, 2009 at 3:58 PM, Jean-Baptiste Queru <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> As a follow-up to the thread about the "provisioned" bit, I'd like to
>>>>>>> look at the way some build-time-configurable aspects are exposed to
>>>>>>> applications.
>>>>>>>
>>>>>>> Right now, we're exposing android.os.Build ("Information about the
>>>>>>> current build, extracted from system properties."). It contains a
>>>>>>> dozen of fields (mostly strings) that contain information about the
>>>>>>> source code that was used, the build combo, and who built it, where,
>>>>>>> and when, i.e. what we often refer to as "the build".
>>>>>>>
>>>>>>> Next to that, we also have android.util.Config ("Build configuration.
>>>>>>> The constants in this class vary depending on [the] build."). It
>>>>>>> contains a handful of booleans, which were meant to be set according
>>>>>>> to the build configuration (e.g. DEBUG, PROFILE, LOGV). Given the way
>>>>>>> we now check API differences for compatibility breaks, we can't
>>>>>>> actually change those values without introducing what our api-checking
>>>>>>> tool considers an API breakage.
>>>>>>>
>>>>>>> I'd like to introduce a mechanism to allow the build-time side to pass
>>>>>>> parameters that can be checked at run-time at the SDK API level, for
>>>>>>> parameters like the "requires_provisioning" bit.
>>>>>>>
>>>>>>> Requirements:
>>>>>>> -Values must be read-only when seen from applications.
>>>>>>> -Must not involve any API change when the parameters change.
>>>>>>> -Must allow to document each possible value using the usual mechanism.
>>>>>>> -Must not involve build-time-generated (or build-dependent) source
>>>>>>> files written in the java programming language.
>>>>>>> -Performance and footprint are both important.
>>>>>>> -Must support at least booleans, integers (int and/or long?) and
>>>>>>> strings.
>>>>>>>
>>>>>>> I'm thinking that Config is a more appropriate location than Build for
>>>>>>> those parameters.
>>>>>>>
>>>>>>> One approach is to do something similar to Build: grab each parameter
>>>>>>> at init time (i.e. in a static final) from whichever location is
>>>>>>> appropriate (SystemProperties or any other place).
>>>>>>>
>>>>>>> Another approach is to not directly expose individual fields, but
>>>>>>> instead to expose functions that take string keys and return the
>>>>>>> values: e.g. boolean getBoolean(String key), int getInt(String key),
>>>>>>> and expose static final constant strings for the keys.
>>>>>>>
>>>>>>> The former feels like it'd be lighter-weight in terms of memory and
>>>>>>> CPU. The latter feels a lot more automated (so that we could just
>>>>>>> stick the values in a data file and parse that).
>>>>>>>
>>>>>>> What's the preferred option?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> JBQ
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste M. "JBQ" Queru
>>>>>>> Android Engineer, Google.
>>>>>>>
>>>>>>>
>>>>>>>
>>>> --
>>>> Jean-Baptiste M. "JBQ" Queru
>>>> Android Engineer, Google.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> --
>> ======
>> Funky Android Limited is registered in England & Wales with the
>> company number 6741909. The registered head office is Kemp House,
>> 152-160 City Road, London, EC1V 2NX, UK.
>>
>> The views expressed in this email are those of the author and not
>> necessarily those of Funky Android Limited, it's associates, or it's
>> subsidiaries.
>>
>>
>>
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"android-framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-framework?hl=en
-~----------~----~----~----~------~----~------~--~---
