GeezerVison

@benfry do you see any issues with this change? @omerjerk and I revised it, and it fixes the problems on android mode after replacement of ecj.jar, without introducing any problems on the other modes. If everything looks good on your side, I will go ahead and merge it.

I had these signature errors while doing the initial move from ecj.jar to the rest of the Eclipse JARs, but managed to fix it by making sure that everything was using the correct version. See version history here:
https://github.com/processing/processing/tree/master/java/mode
Hoping this isn't a necessary change.

Hi @benfry,
I had a look at this commit - b73f9dd, but I couldn't find anything special in the way those jar files are referenced. We're doing the same in Android mode. The only difference is that in the above commit, jar files referred are the ones inside /java/mode/, whereas in Android mode, we refer to the files inside /build/linux/work/modes/java/mode/ .
I don't think it'll make any difference as both are the same copies.
What do you think ?
P.S. Have a look at this commit showing the way we reference - omerjerk/processing-android@57d1f7c

@benfry I've been looking into this issue for a while, and unfortunately was unable to find a solution that does not involve changing the signature of the eclipse jars. I tried to directly load jdtCompilerAdapter.jar from within org.eclipse.jdt.core.jar (it turns out it is possible), but still get the SecurityException. It looks like that even if a jar is nested inside a signed jar, needs to be signed as well.

This fellow encountered the same problem in the past. The replies from the other user are informative.

One explanation as to why the use of jdtCompilerAdapter in the various Processing build scripts is fine could be that, as suggested in the thread, ant runs with runtime signature verification disabled by default. Running ant programmatically perhaps triggers runtime signature verification automatically? I checked the Project class javadoc, and didn't see any method to enable/disable such verification through code. Are you aware of any way of doing so by means of some little known option in the build file? (didn't find myself)

I agree that @omerjerk 's solution of removing the signature files from org.eclipse.jdt.core.jar is not very clean. But I don't see any other options so far, with the exception to re-sign all jars with a "Processing" signature, not clean either but at least one could argue it is a more "consistent" solution. I haven't tried though.

Any ideas are welcome.

But why haven't we had to do this elsewhere? Android isn't the only place that we're using ant (it also exports applications, and we build Processing itself using the JDT .jar files from ant). Messing with binaries like this just seems really hacky and wrong, and I hate the idea of adding a "carefully remove all signatures from a dozen JARs" as a step that's necessary whenever we update the compiler in the PDE.

Seems that other instances where ant is used in Processing are different in one way or another: when building Processing itself, ant is run from the command line (ultimately this should be the same as running it programmatically, but maybe not?), and the other place I found where org.apache.tools.ant.Project is used is to build the Windows launcher, but the build file (launch4j-build.xml) doesn't seem to involve the jdtCompilerAdapter (it does use extJavac for build.compiler).

This is why I found interesting that the guy in the thread I mentioned earlier asks "Is certificate checking normally enabled when running ant?", as if it were possible to disable it.

So, it will be great if we can find a non-hacky solution, but so far I have been unable to do so. I will keep looking into this, and will try to reach out folks on the Eclipse forum.

@omerjerk @benfry : following the last comment in the java.lang.SecurityException thread in the Eclipse forum, we eventually found the ecj.jar file that corresponds to the eclipse release used by Processing (4.4.1).

So I modified the generation of the build.xml file in AndroidBuild so it uses this ecj.jar (which I put in processing-android/mode). The problem is that all the files in java/mode are in the classpath when running the build process to compile the android sketch, so I still get the java.lang.SecurityException error, after cleaning and rebuilding all relevant projects.

I tried two more things, which I describing here for reference:

• Replaced jdtCompilerAdapter.jar by ecj.jar in all build files and classpaths, cleaned and rebuild everything, which worked, with the goal of running the android mode from eclipse and test running sketches from there. However, when I try to run processing-app from eclipse, after removing all references to jdtCompilerAdapter.jar and making sure that there are no errors and that the build process from the command line works I get the following:

• Since after replacing jdtCompilerAdapter.jar by ecj.jar everywhere I could still build processing normally, I though of creating an updated package of the android mode and drop it inside sketchbook/modes. However, when I run Processing with "ant run", the android mode is not added into the UI, and I see the message "AndroidMode contains an incompatible Mode" in the console... I guess this is due to a different issue, and I might need to update something else in the android mode to work with the latest version of the pde.

So, my apologies for going this long, but I wanted to keep a record of what I did. So far, I'm unable to solve the SecurityException, unless I apply Umair's original solution of removing the signatures from org.eclipse.jdt.core.jar.

This is the only issue blocking an updated release of the android mode that would work for processing 3.0a10+. I'm happy to consider any other ideas, suggestions, etc.

I give up. Let's just remove the signature. Are you sure it's just one file?

Since we're updating the binaries, we should update all of the jars to that slightly newer point release.

Be extremely careful when doing the removal so we don't wind up with an uncompressed JAR or have extra .DS_Store boogers or whatever else in it.

Yes, I tested the file in this PR, and the only chance it introduces is the removed signatures.

I also confirm this. The only change is the removal of signature files.

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.