java.lang.IllegalArgumentException: MALFORMED When Analyzing Java Files

[txiao]

I'm currently running Windup 2.7.0.Final against an application to be migrated from EAP 5 to EAP 7. Most of the rules process successfully, however the AnalyzeJavaFilesRuleProvider rule failed, apparently due to a problem unzipping a jar (Windup is being run against the compiled EAR file).

The stack trace is below, and I've attached the output from Windup with some more context.

java.lang.IllegalArgumentException: MALFORMED

  at java.util.zip.ZipCoder.toString(ZipCoder.java:58)

  at java.util.zip.ZipFile.getZipEntry(ZipFile.java:566)

  at java.util.zip.ZipFile.access$900(ZipFile.java:60)

  at java.util.zip.ZipFile$ZipEntryIterator.next(ZipFile.java:524)

  at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:499)

  at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:480)

  at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.isPackage(ClasspathJar.java:155)

  at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.findClass(ClasspathJar.java:94)

  at org.eclipse.jdt.internal.compiler.batch.FileSystem.findClass(FileSystem.java:262)

  at org.eclipse.jdt.internal.compiler.batch.FileSystem.findType(FileSystem.java:354)

  at org.eclipse.jdt.core.dom.NameEnvironmentWithProgress.findType(NameEnvironmentWithProgress.java:42)

  at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createPackage(LookupEnvironment.java:755)

  at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:107)

  at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:188)

  at org.eclipse.jdt.core.dom.CompilationUnitResolver.beginToCompile(CompilationUnitResolver.java:213)

  at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:990)

  at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:636)

  at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:990)

  at org.jboss.windup.ast.java.BatchASTProcessor$2.call(BatchASTProcessor.java:97)

  at org.jboss.windup.ast.java.BatchASTProcessor$2.call(BatchASTProcessor.java:68)

  at java.util.concurrent.FutureTask.run(FutureTask.java:266)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

  at java.lang.Thread.run(Thread.java:745)

Thanks!

[manarh]

Please could you try to run Windup 3.0.0.CR1 or 2.7.0.Final at least?

[txiao]

I misread the output of "windup -v", I was looking at the JBoss Forge version. The version of WIndup used is 2.7.0.Final.

[manarh]

ok, np

Could you post here what Windup command looks like ?

[manarh]

Does it work if you manually unzip the EAR file to disk and try if it throws the same exception?

[txiao]

Here's the command. I've changed the filename of the EAR and the package name, but the rest of the syntax is the same.

[txiao@work-laptop bin]$ ./windup --input ~/path/to/ear/legacy-app.ear --output test --source eap:5 --target eap:7 --packages com.client.packages

[txiao]

The same error occurred, on a different rule:

[36/246] InitialAnalysisPhase - AnalyzeJavaFilesRuleProvider - AnalyzeJavaFilesRuleProvider_1

java.lang.IllegalArgumentException: MALFORMED

  at java.util.zip.ZipCoder.toString(ZipCoder.java:58)

  at java.util.zip.ZipFile.getZipEntry(ZipFile.java:566)

  at java.util.zip.ZipFile.access$900(ZipFile.java:60)

  at java.util.zip.ZipFile$ZipEntryIterator.next(ZipFile.java:524)

  at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:499)

  at java.util.zip.ZipFile$ZipEntryIterator.nextElement(ZipFile.java:480)

  at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.isPackage(ClasspathJar.java:155)

  at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.findClass(ClasspathJar.java:94)

  at org.eclipse.jdt.internal.compiler.batch.FileSystem.findClass(FileSystem.java:262)

  at org.eclipse.jdt.internal.compiler.batch.FileSystem.findType(FileSystem.java:354)

  at org.eclipse.jdt.core.dom.NameEnvironmentWithProgress.findType(NameEnvironmentWithProgress.java:42)

  at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createPackage(LookupEnvironment.java:755)

  at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:107)

  at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:188)

  at org.eclipse.jdt.core.dom.CompilationUnitResolver.beginToCompile(CompilationUnitResolver.java:213)

  at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:990)

  at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:636)

  at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:990)

  at org.jboss.windup.ast.java.BatchASTProcessor$2.call(BatchASTProcessor.java:97)

  at org.jboss.windup.ast.java.BatchASTProcessor$2.call(BatchASTProcessor.java:68)

  at java.util.concurrent.FutureTask.run(FutureTask.java:266)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

  at java.lang.Thread.run(Thread.java:745)

The command run was:

./windup --input ~/path/to/ear/unzipped-ear --output test --source eap:5 --target eap:7 --packages com.client.packages --updateRulesets

[manarh]

hmm, it seems broken somehow. Some tips to try:

1. Extract everything into exploded structure and use --explodedApp option
2. Print out packages from application with --discoverPackages

[manarh]

your command seems ok

[jsightler]

To me, it sounds like this app has a corrupted jar file embedded and that is causing the AST analyzer to fail. Is there any way that we can try a copy of the app here?

[txiao]

Extracting the files worked, I unzipped all of the archives in the project, and it processed correctly. Thanks for your help!

[manarh]

Glad you, solved that!

[ozizka]

Trevor, is it possible that the .jar files have non-UTF encoding? Were they created by JDK or some system-specific zip tool?

There is a problem with ZIP format, read e.g.

Non-UTF-8 encoding in ZIP file (Xueming Shen's Oracle Blog) and

https://marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/

Any chance you could give us any of the .jar files you're scanning so we could check?

[txiao]

I believe they were created using the Oracle JDK, but I only had access to the compiled artifacts, so I'm not sure how they were built. I can't attach the jar files, since they're proprietary client code.

I've since moved off the project, so unfortunately I no longer have access to the artifacts or the Windup report. Sorry I can't help more with the debugging.

[ozizka]

Ok, no problem, and thanks for the quick reply.