[
https://issues.apache.org/jira/browse/FLEX-34225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969694#comment-13969694
]
Stephanie Swiderski edited comment on FLEX-34225 at 4/15/14 4:36 PM:
---------------------------------------------------------------------
Hi Alex Harui,
I fixed it by using a serious bad hack. This why I stated it here since you
could fix it far more better then I could from outside.
The hack I used works as follows:
1. I created a subclass FDT_MXMLC of MXMLC and used it to launch the mxmlc
compiler.
2. FDT_MXMLC overrides method createConfigurator. This new method returns my
subclass FdtConfigurator of Configurator.
3. FdtConfigurator overrides createConfigurationBuffer. This new method calls
its super method and before it returns it corrects the ConfigurationBuffer.
4. To correct the ConfigurationBuffer first the content of the varList field is
gained by reflection (getDeclaredField, setAccessible, ...).
5. The gained value, a string list, is sorted by Collections.sort with a
special comparator.
6. This comparator uses a constant string array containing all options as
reference order for all options (I gained that array by a debug session with
eclipse of the compiler). So any known option in that list is sorted and unkown
options are placed at the end so that new options due to compiler modifications
by adobe are not lost.
Regards,
Steffi
was (Author: ssw):
Hi Alex Harui,
I fixed it by using a serious bad hack. This why I stated it here since you
could fix it far more better then I could from outside.
The hack I used works as follows:
1. I created a subclass FDT_MXMLC of MXMLC and used it to launch the mxmlc
compiler.
2. FDT_MXMLC overrides method createConfigurator. This new method returns my
subclass FdtConfigurator of Configurator.
3. FdtConfigurator overrides createConfigurationBuffer. This new method calls
its super method and before it returns it corrects the ConfigurationBuffer.
4. To correct the ConfigurationBuffer first the content of the varList field is
gained by reflection (getDeclaredField, setAccessible, ...).
5. The gained value, a string list, is sorted by Collections.sort with a
special comparator.
6. This comparator uses a constant string array as reference order of all
options (I gained that array by a debug session with eclipse of the compiler).
So any known option in that list is sorted and unkown options are placed at the
end so that new options due to compiler modifications by adobe are not lost.
Regards,
Steffii
> Configurations dependent on loading order of methods
> ----------------------------------------------------
>
> Key: FLEX-34225
> URL: https://issues.apache.org/jira/browse/FLEX-34225
> Project: Apache Flex
> Issue Type: Bug
> Components: FlexJS
> Affects Versions: Apache FlexJS 1.0
> Environment: Windows 7, 32 Bit, FDT/Eclipse
> Reporter: Stephanie Swiderski
> Priority: Critical
>
> Location:
> org.apache.flex.compiler.config.ConfigurationBuffer, method loadCache, line
> 553; top for-loop
> Problem:
> Using method cfg.getMethods() is not as safe as it appears. The field varList
> is filled with all available configuration options. The evaluation of the
> options is order dependent to field varList (especially for the option
> "target-player" ). The order of methods returned by cgf.getMethods() is JVM,
> Classloader, and memory dependent. Sometimes the order is loaded differently
> as expected and the "target-player" option is evaluated after SDK-swcs are
> collected for the compilation which results in incorrect compiler
> initialisation, incorrect error reports, and failing compilations.
> About Method getMethods:
> http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getMethods%28%29
> The relevant part:
> ".... The elements in the array returned are not sorted and are not in any
> particular order..... "
> This problem is serious if the compiler should be embedded into an IDE like
> FDT. The Classloaders in Eclipse behaves slightly different to the default
> Classloaders.
> The same problem occured with the latest Adobe Flex SDK Action Script
> Compiler 2.0. Since Adobe's cycle of development is very slow we decided to
> solve this problem within FDT by simply sorting the varList field according
> to a working default order.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
