On 1/2/17, 1:54 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>Hi, > >I am currently going through some issues in the code and stumbled over >several that need discussion: > > >- The Ant build script claims the source to be Java 1.6, but >there’s code in there that is marked as “since 1.7” (COMPJSC.java Lines >349 and 351): What source level are we using? I would vote for 1.7 as we >are doing new stuff and I don’t see the point in writing that in a no >longer supported Java version. I would even be ok with 1.8. You couldn’t >use it with Maven with Java 1.6 anyway because our minimum Maven version >already requires 1.7. I don't know much about Java version compatibility, but here's what I understand: In flex-falcon, the flex-compiler-oem jar plugs in Flash Builder. Flash Builder comes bundled with an older version of Eclipse. Supposedly these versions of Eclipse and Flash Builder are stuck on Java 1.6? Flex-compiler-oem calls into the other jars in the flex-falcon/compiler project, but uses a launcher for running the code in the flex-falcon/compiler-jx project. So, could that mean that compiler-jx could be on a newer Java version? However, in trying to create the ability for Flash Builder to build both the SWF and JS versions in one go, I think the flex-compiler-oem.jar will be calling into jars from compiler-jx. So I was told that we need to stay with 1.6, but I have no idea if that's really true or not. Now recently, Adobe supposedly found a way to get Flash Builder to run on Java 7 and 8 on Mac [1]. No idea about Windows. And the process seems a bit difficult. Not sure if we could automate it. IMO, Flash Builder remains important and will be important for at least a few more years. But if there is a way to get our code to run in Flash Builder without being stuck on 1.6, I'm more than happy to move to a newer version. [1] http://blogs.adobe.com/flashplayer/2016/09/running-adobe-flash-builder-on-m ac-with-java-78.html#sthash.KQAn0JLy.dpbs > > > >- I have encountered several code blocks in which if statements >compare String constants with the “==” operator. In most cases this can’t >possibly be true … unfortunately there are larger code blocks in there. >Now I could simply delete the code blocks (they don’t seem to be needed >at the moment) but I guess they were written for a purpose, so I don’t >quite feel well with deleting. > >o org.apache.flex.compiler.internal.codegen.as.ASEmitter Line: 1332 > >o >org.apache.flex.compiler.internal.codegen.js.flexjs.JSFlexJSDocEmitter >Line: 173, 251, 252, 346, 385, 389, 393, 405, 409 > >o org.apache.flex.compiler.internal.codegen.js.flexjs.JSFlexJSEmitter >Line: 475-479 > >o org.apache.flex.compiler.internal.codegen.js.goog.JSGoogDocEmitter >Line: 115, 119, 204, 205, 435, 442, 505, 506 > >o org.apache.flex.compiler.internal.codegen.js.goog.JSGoogEmitter Line: >430, 649, 704, 710, 780, 785 > >o org.apache.flex.compiler.internal.codegen.mxml.MXMLEmitter Line: 184 > >o >org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSASDocEmitt >er: Line 822 > >o ... > >Some of these “==” issues might even be correct if the source is >initialized with the same constant as which it’s being compared to. If you are feeling brave, clean these up and see if all tests pass. -Alex
