Forgot to respond to the "Just curious, what is the advantage of creating instances of every tool in the group?" In the FlexToolApi there is a mechanism that auto-detects Tool-Groups (in flexJS there is the "Falcon" tool group and the "FlexJS" tool group) In order to build an index of the tools available on the system, I built a map of tool instances. Usually this should not be a problem but in our case the Constructors have side-effects. This is actually the bad thing and it's the thing I didn't know when creating the FlexToolApi 1,5 years ago. We could change the tool api, to create the instances of tools in the "getFlexTool" method. I would eventually change the map from Map<String, FlexTool> to Map<String, Class<implements FlexTool>) and would create instances on the fly, but that would create multiple instances on every call ... I wanted to avoid that. Of course we could make the system even more complex and cache instances of each tool after they have been created. But in the case of any change in the FlexToolApi we would need to do a new release of that. Or we could just do the state-handling correctly without global static variables (except the Threadlocal ... that has to stay something global). I strongly vote for keeping the tool api simple and making the compiler thread-safe as we will be running into that problem sooner than later.
Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Sonntag, 8. Mai 2016 07:23:43 An: dev@flex.apache.org Betreff: Re: AW: [FLEXJS] Probably found the reason for some of my problems ... On 5/7/16, 12:01 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > >I agree that the initial version doesn't have to be perfect. But we have >to keep track of such places and make sure to clean them up as soon as we >have some time. Perhaps it would be a good idea if implementing something >we know is hacky, to create an Issue for cleaning up? > >It's just that tracking down stuff like this comes close to being >impossible. I was confused why the backend I put in when creating the >COMPJSC instance wasn't there when using it. I could only track that down >by using an insanely expensive property-access-breakpoint. Just curious, what is the advantage of creating instances of every tool in the group? I'm not clear it was intended for sharing between instances of the compiler, just for sharing data from various places in the compiler. I'm not a Java VM expert, but I think when we do builds we create an instance of the compiler, compile something, destroy that instance, create another instance, compile that next thing, etc. Which is pretty much what would happen on the command-line. Are you trying to keep certain things in memory so the start up doesn't have to happen every time, sort of like fcsh? Thanks, -Alex
