From: Arnaud D. <ar...@gm...> - 2011-10-13 07:42:35
|
Hi all, I am embedding jython into GeoGebra, an interactive algebra/geometry software [1], in order to use it as a scripting language for users[2]. The project is still in its early days but show potential (see [3]). One issue is that Proguard is used in GeoGebra releases to obfuscate names (only to save space, as GeoGebra is GPL and everybody has access to the source), which creates a problem for jython scripts! I am not sure how to tackle this issue and would be grateful for some guidance. The only solution I can think of at the moment is to create some java "Proxy" class for each class that I need and include a proxy method for each method that I need e.g. if I have a class with a method that I need to call from within the jython script class GeoElement { ... public void setLabel(String lbl) { ... } ... } Then include this in the Proxy class: class GeoElementProxy { ... public void setLabel() { // geo is a private reference to the real GeoElement return geo.setLabel(lbl); } ... } Then tell Proguard not to obfuscate any of the Proxy classes. I don't really like this approach as it is a bit tedious and incurs a lot of repetition, although I could generate all these classes from some config file I guess. Is there a better way? [1] http://www.geogebra.org [2] http://www.geogebra.org/trac/wiki/Jython [3] http://www.geogebra.org/trac/wiki/Jython/AlgebraicBestFit |
From: Johannes B. <buc...@gm...> - 2011-10-13 08:29:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2011 09:42 AM, Arnaud Delobelle wrote: > Hi all, > > I am embedding jython into GeoGebra, an interactive > algebra/geometry software [1], in order to use it as a scripting > language for users[2]. The project is still in its early days but > show potential (see [3]). One issue is that Proguard is used in > GeoGebra releases to obfuscate names (only to save space, as > GeoGebra is GPL and everybody has access to the source), which > creates a problem for jython scripts! I am not sure how to tackle > this issue and would be grateful for some guidance. > > The only solution I can think of at the moment There is another, obvious solution. Don't obfuscate. See proguard -dontobfuscate > is to create some java "Proxy" class for each class that I need and > include a proxy method for each method that I need > > e.g. if I have a class with a method that I need to call from > within the jython script > > class GeoElement { ... public void setLabel(String lbl) { ... } > ... } > > Then include this in the Proxy class: > > class GeoElementProxy { ... public void setLabel() { // geo is a > private reference to the real GeoElement return geo.setLabel(lbl); > } ... } > > Then tell Proguard not to obfuscate any of the Proxy classes. I > don't really like this approach as it is a bit tedious and incurs a > lot of repetition, although I could generate all these classes from > some config file I guess. > > Is there a better way? > > > [1] http://www.geogebra.org [2] > http://www.geogebra.org/trac/wiki/Jython [3] > http://www.geogebra.org/trac/wiki/Jython/AlgebraicBestFit > > ------------------------------------------------------------------------------ > > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and > makes sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ Jython-users > mailing list Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6WoRYACgkQ7X1+MfqVcr0SgQCePk0oQEbH7XTk+yjEY4+gV1dq vsgAoIRgf6/f3uIbPZPwg8opAupcH8m7 =Q/ol -----END PGP SIGNATURE----- |
From: Arnaud D. <ar...@gm...> - 2011-10-13 12:05:59
|
On 13 October 2011 09:28, Johannes Buchner <buc...@gm...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/13/2011 09:42 AM, Arnaud Delobelle wrote: >> Hi all, >> >> I am embedding jython into GeoGebra, an interactive >> algebra/geometry software [1], in order to use it as a scripting >> language for users[2]. The project is still in its early days but >> show potential (see [3]). One issue is that Proguard is used in >> GeoGebra releases to obfuscate names (only to save space, as >> GeoGebra is GPL and everybody has access to the source), which >> creates a problem for jython scripts! I am not sure how to tackle >> this issue and would be grateful for some guidance. >> >> The only solution I can think of at the moment [...] > There is another, obvious solution. Don't obfuscate. > > See proguard -dontobfuscate Thank you for the suggestion. Unfortunately, I can't do this. Regards, -- Arnaud |
From: Johannes B. <buc...@gm...> - 2011-10-13 12:48:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2011 02:05 PM, Arnaud Delobelle wrote: > On 13 October 2011 09:28, Johannes Buchner > <buc...@gm...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 10/13/2011 09:42 AM, Arnaud Delobelle wrote: >>> Hi all, >>> >>> I am embedding jython into GeoGebra, an interactive >>> algebra/geometry software [1], in order to use it as a >>> scripting language for users[2]. The project is still in its >>> early days but show potential (see [3]). One issue is that >>> Proguard is used in GeoGebra releases to obfuscate names (only >>> to save space, as GeoGebra is GPL and everybody has access to >>> the source), which creates a problem for jython scripts! I am >>> not sure how to tackle this issue and would be grateful for >>> some guidance. >>> >>> The only solution I can think of at the moment [...] > >> There is another, obvious solution. Don't obfuscate. >> >> See proguard -dontobfuscate > > Thank you for the suggestion. Unfortunately, I can't do this. - From the Proguard page it is pretty clear that obfuscation only brings minuscule improvements, and most of the work is done by shrinking + optimization, so your motivation to insist on obfuscation is unclear to me. Of course you could write a script that creates Proxy classes from the Java code, but it will make your code difficult to understand and maintain (not to say obfuscated). It also looks like Proguard has quite sophisticated -keep* options, that would allow you to specify all public-facing (API) classes without listing them -- see the example with Serializable on the Usage page. Cheers, Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6W3b8ACgkQ7X1+MfqVcr0DwwCeOqHjGB4TRkASJmJoBBD0dA/L Ya4An0PSMVI2MkX/cuFGYyxHmBMmD6Pw =M1J0 -----END PGP SIGNATURE----- |
From: Arnaud D. <ar...@gm...> - 2011-10-13 12:58:31
|
On 13 October 2011 13:46, Johannes Buchner <buc...@gm...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/13/2011 02:05 PM, Arnaud Delobelle wrote: >> On 13 October 2011 09:28, Johannes Buchner >> <buc...@gm...> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 10/13/2011 09:42 AM, Arnaud Delobelle wrote: >>>> Hi all, >>>> >>>> I am embedding jython into GeoGebra, an interactive >>>> algebra/geometry software [1], in order to use it as a >>>> scripting language for users[2]. The project is still in its >>>> early days but show potential (see [3]). One issue is that >>>> Proguard is used in GeoGebra releases to obfuscate names (only >>>> to save space, as GeoGebra is GPL and everybody has access to >>>> the source), which creates a problem for jython scripts! I am >>>> not sure how to tackle this issue and would be grateful for >>>> some guidance. >>>> >>>> The only solution I can think of at the moment [...] >> >>> There is another, obvious solution. Don't obfuscate. >>> >>> See proguard -dontobfuscate >> >> Thank you for the suggestion. Unfortunately, I can't do this. > > - From the Proguard page it is pretty clear that obfuscation only brings > minuscule improvements, and most of the work is done by shrinking + > optimization, so your motivation to insist on obfuscation is unclear > to me. > > Of course you could write a script that creates Proxy classes from the > Java code, but it will make your code difficult to understand and > maintain (not to say obfuscated). > > It also looks like Proguard has quite sophisticated -keep* options, > that would allow you to specify all public-facing (API) classes > without listing them -- see the example with Serializable on the Usage > page. Hi Johannes. Thanks for the precisions. As a understand it, GeoGebra has a sophisticated build process which has been refined over the years. I am not in a position to modify it myself (and I certainly do not understand it fully) but I will forward your comments. -- Arnaud |
From: Alan K. <jyt...@xh...> - 2011-10-13 13:17:44
|
[Arnaud] >>> One issue is that Proguard is used in >>> GeoGebra releases to obfuscate names (only to save space, as >>> GeoGebra is GPL and everybody has access to the source), which >>> creates a problem for jython scripts! I am not sure how to tackle >>> this issue and would be grateful for some guidance. Does proguard generate a list of the names it has mangled, and the names that it has mangled them to? If yes, then it should be straightforward to generate some jython mappings from one to the other. If no, can you request for that to be generated in the build process? Alan. |
From: Arnaud D. <ar...@gm...> - 2011-10-13 13:31:56
|
On 13 October 2011 14:17, Alan Kennedy <jyt...@xh...> wrote: > [Arnaud] >>>> One issue is that Proguard is used in >>>> GeoGebra releases to obfuscate names (only to save space, as >>>> GeoGebra is GPL and everybody has access to the source), which >>>> creates a problem for jython scripts! I am not sure how to tackle >>>> this issue and would be grateful for some guidance. > > Does proguard generate a list of the names it has mangled, and the > names that it has mangled them to? Yes it does - but the problem is that it (ab)uses method overloading so that many originally differently named methods (but with a different signature) end up having the same name. I think this would complicate things quite a bit. > If yes, then it should be straightforward to generate some jython > mappings from one to the other. > > If no, can you request for that to be generated in the build process? > > Alan. > |