Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Package, Class and Method renaming
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <D5ADC9F5.9AB1D%aharui@adobe.com>
Date: Mon, 7 Aug 2017 18:05:37 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D6CD13D-9996-4603-8C05-FD5A86C50A65@gmail.com>
References: <54F78FFC-D59D-4E50-A7B7-1F3935022F20@gmail.com> <D5AD484F.9AAC0%aharui@adobe.com> <8C7468A6-C439-4F06-AA87-9989CDE32087@gmail.com> <D5AD5409.9AAE9%aharui@adobe.com> <7519704C-E6AF-4A03-B84F-E5EE05E6A3E7@gmail.com> <727AE3D9-59CC-4586-861A-86AC2F8A653A@gmail.com> <D5ADC9F5.9AB1D%aharui@adobe.com>
To: dev@flex.apache.org
archived-at: Mon, 07 Aug 2017 15:06:01 -0000


> On Aug 7, 2017, at 5:52 PM, Alex Harui <aharui@adobe.com.INVALID> =
wrote:
>=20
> GCC has some static flow analysis, so yes, they can detect unused
> functions, but I don't think it can detect bracket access to functions =
any
> better than bracket access to properties, both of which are allowed in =
AS
> and JS.

Yes. I realize this. I=E2=80=99m having trouble envisioning a way of =
generalizing automatic avoidance of @exporting.

> FalconJX doesn't call GCC on the command line.  It uses a Java API.  I
> think I've seen APIs that are probably what the property map does.  =
The
> question remain about how to determine what to put in the list.

I was thinking of a hand-crafted list. goog can dump a list of all =
properties and the list can be edited.

> MXML does use dynamic/bracket access, but it should be putting the =
whole
> property name in the file.  I have not investigated as to how GCC =
handles
> that and whether those strings are mapped to a variable and the MXML =
data
> array is updated with the variable, or if there is a way to tell GCC =
that
> once a string is seen anywhere, then don't rename anything using that
> string.  But if you want higher levels of obfuscation then we would =
want
> to rename those properties as well, and potentially even tell data =
binding
> to use the new property name.

Yes. Possibly.

> I think it is all possible, it is just a matter of time and =
priorities.
> Are you thinking you can't deploy without better obfuscation?

I don=E2=80=99t think I can deploy to the public without obfuscation. =
Our first stage is to make it available to partners. That I think I can =
do without obfuscation.

My fallback is probably a script which will do find/replaces on the =
minified code. It=E2=80=99ll probably be tedious to construct the =
script, but doable. In the meantime, I=E2=80=99ve been examining my =
minified code for places where the source can be better constructed to =
output better minified code. That=E2=80=99s where the thought of using =
the set__ and get__ functions came from.

Harbs

>=20
> -Alex
>=20
> On 8/7/17, 2:56 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>=20
>> Yishay came across this post:
>> =
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fstackov=
er
>> =
flow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optimi=

>> =
zations-option&data=3D02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7b=
1b
>> =
5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=3DIwqmGYan9F=
hZ
>> drheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=3D0
>> =
<https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fstacko=
ve
>> =
rflow.com%2Fquestions%2F10433716%2Fgoogle-closure-compilers-advanced-optim=

>> =
izations-option&data=3D02%7C01%7C%7Cf34315ae09c24c6132e008d4dd7aa141%7Cfa7=
b1
>> =
b5a7b34438794aed2c178decee1%7C0%7C0%7C636376966140467607&sdata=3DIwqmGYan9=
Fh
>> ZdrheOGOK78KS6pWSHyTKq2eWfILnjkM%3D&reserved=3D0>
>>=20
>> I wonder if there=E2=80=99s some way to use the property_map options =
to control
>> renaming. My guess is that it would only work if @export is not used.
>>=20
>> Related to this general topic:
>>=20
>> I realized that goog is much better at minifying functions than
>> properties. That makes sense because you can reliably point to =
functions
>> using references. Referencing variables is not reliable because the
>> references can end up pointing to different values.
>>=20
>> Theoretically, getters and setters could be better for that. The =
problem
>> is that goog treats the getters like variables. If the compiler would
>> rewrite getter and setter access to the underlying getter and setter
>> functions, goog could probably do a better job optimizing those. =
(i.e.
>> instead of foo.baz =3D =E2=80=9Cbaz=E2=80=9D, Falcon could write =
foo.set__baz(=E2=80=9Cbaz=E2=80=9D) and
>> var baz  =3D foo.baz could become var baz =3D foo.get__baz())
>>=20
>> Harbs
>>=20
>>> On Aug 7, 2017, at 9:56 AM, Harbs <harbs.lists@gmail.com> wrote:
>>>=20
>>> Another case which seems to need exports is any property used in =
MXML.
>>>=20
>>> It seems like the low hanging fruit would be to allow some kind of
>>> markup to specify classes which don=E2=80=99t need exports.
>>>=20
>>> Rewriting constants to literals is another one which should be =
pretty
>>> easy to solve.
>>>=20
>>>> On Aug 7, 2017, at 9:24 AM, Alex Harui <aharui@adobe.com.INVALID>
>>>> wrote:
>>>>=20
>>>> Dynamic access (aka square bracket access) is used in data binding, =
but
>>>> people use it for other things as well.  The really hard case =
involves
>>>> "string math" where you access something like foo[someValue + =
"label"].
>>>> It is hard to know that "enUSLabel" and "frFRLabel" should not be
>>>> renamed.
>>>>=20
>>>> And yes, modules will need to find APIs in other modules or the =
host
>>>> and
>>>> renaming is a problem there too.
>>>>=20
>>>> But I'll bet that only a small fraction of APIs should not be =
renamed
>>>> in
>>>> any typical app, especially if no modules are in play.  The =
question is
>>>> "which ones"?  But if we can make it possible, it should be a good
>>>> obfuscator as well.
>>>>=20
>>>> My 2 cents,
>>>> -Alex
>>>>=20
>>>> On 8/6/17, 10:57 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>=20
>>>>> I=E2=80=99m fuzzy on all the reasons for using @import so much.
>>>>>=20
>>>>> We=E2=80=99ve had discussions on the topic, but hey were spread =
out.
>>>>>=20
>>>>> The reasons that stick in my mind was for bracketed access (needed =
for
>>>>> binding?) and reflection. Another reason I think that was =
mentioned
>>>>> was
>>>>> for modules (which we don't=E2=80=99 yet really have a way to =
use).
>>>>>=20
>>>>> Is that it?
>>>>>=20
>>>>>> On Aug 7, 2017, at 8:34 AM, Alex Harui <aharui@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>=20
>>>>>> It might be more interesting and fruitful to investigate removing
>>>>>> @export
>>>>>> annotations.  How could we determine which variables are being
>>>>>> accessed
>>>>>> via foo[someProperty] and only keep @export on those properties?
>>>>>>=20
>>>>>> You might be able to use a text replacement tool to remove =
@export
>>>>>> and
>>>>>> mess around with the rest of the source to prevent renaming of =
the
>>>>>> few
>>>>>> variables that will be looked up by foo[someProperty].  Either
>>>>>> keeping
>>>>>> the
>>>>>> @export or use ["string"] access which I think prevents renaming =
in
>>>>>> GCC.
>>>>>>=20
>>>>>> There are options in the compiler to skip generating the js-debug =
and
>>>>>> just
>>>>>> call GCC.
>>>>>>=20
>>>>>> My 2 cents,
>>>>>> -Alex
>>>>>>=20
>>>>>> On 8/6/17, 3:13 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>>>=20
>>>>>>> I=E2=80=99m getting close to the release of my app and I=E2=80=99m=
 starting to think
>>>>>>> about some things related.
>>>>>>>=20
>>>>>>> I would like to have the option for minified code to have =
package,
>>>>>>> class
>>>>>>> and members renamed at compile time. I have two reasons for =
this:
>>>>>>>=20
>>>>>>> 1. Obfuscation. As it stands, it=E2=80=99s pretty easy to take =
minified code
>>>>>>> from
>>>>>>> FlexJS and reconstruct the original code with the original =
structure
>>>>>>> and
>>>>>>> naming. Everything is @exported and easily readable. I=E2=80=99d =
like to
>>>>>>> have a
>>>>>>> method to rename everything to something completely =
unintelligible.
>>>>>>>=20
>>>>>>> 2. Code size. I was not sure how much package paths would effect
>>>>>>> code
>>>>>>> size, so I just did an experiment. I renamed every package path =
in
>>>>>>> my
>>>>>>> app
>>>>>>> to a much shorter version (i.e. org.apache.flex.core becomes =
fxc,
>>>>>>> etc.) I
>>>>>>> did not spend the time renaming class names or class member =
names.
>>>>>>> Just
>>>>>>> shortening the package paths resulted in a reduction of 509KB to
>>>>>>> 505KB
>>>>>>> after gzipping. (Prior to gzipping the reduction was 53 KB.) =
Class
>>>>>>> names
>>>>>>> and member names are a significant percentage of the remaining
>>>>>>> code, so
>>>>>>> it stands to reason that renaming those will result in a further
>>>>>>> reduction of code size.
>>>>>>>=20
>>>>>>> To be clear: obfuscation is a much bigger drive for me than code
>>>>>>> size.
>>>>>>> Code size is just an added plus.
>>>>>>>=20
>>>>>>> I was thinking of ideas on how to accomplish this goal.
>>>>>>>=20
>>>>>>> One idea was to  enable some kind of metadata (or comments) in =
the
>>>>>>> code
>>>>>>> that the compiler could interpret to rewrite the names
>>>>>>>=20
>>>>>>> Another idea was some kind of mapping file that serves the same
>>>>>>> purpose.
>>>>>>>=20
>>>>>>> This is something that should be enabled via a compiler option.
>>>>>>>=20
>>>>>>> The challenge would be with library code in a swc. Since it=E2=80=99=
s
>>>>>>> already
>>>>>>> compiled to JS, it would be much harder to rename things unless =
it
>>>>>>> would
>>>>>>> work using find/replace. It seems to me that it would be more
>>>>>>> reliable
>>>>>>> if
>>>>>>> done while walking the tree and packages, classes and members =
could
>>>>>>> each
>>>>>>> be handled explicitly.
>>>>>>>=20
>>>>>>> Thoughts?
>>>>>>>=20
>>>>>>> Harbs
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20