What did this mean? Features like try-with-resources and the diamond operator could not be used in our source code. These are the kinds of errors I was seeing when trying to build our services...
JWSC Errors
error: try-with-resources is not supported in -source 1.5
try (ZipInputStream zipInputStream = new ZipInputStream(zipData.getInputStream()))
error: diamond operator is not supported in -source 1.5
ArrayList<String> missingParams = new ArrayList<>();
Now that error was strange. The mention of -source 1.5 was out of place. I've checked and double checked how the JWSC task was used, I've even hard-coded it to use '1.7' as the source and target levels, all to no avail.
This is the part of the build system that's using JWSC...
build.properties
...
build.jdk_version=1.7
...
build.xml
...
<jwsc destdir="${path.build}" keepgenerated="no"
source="${build.jdk_version}" target="${build.jdk_version}"
...
Now the documentation clearly states that the source attribute is supported. Something had to be amiss in the JWSC code, so I dug in and started decompiling. The relevant classes were in weblogic-classes.jar. Eventually I tracked the issue down to JamUtil.java in the weblogic.wsee.util package.
Here's the bit of offending code...
JamUtil.java
...
public static JClass[] parseSource(File[] srcFiles, String sourcePath, String classPath, String encoding)
throws WsBuildException
{
...
params.setProperty("javadoc.args", "-source 1.5");
...
The javadoc validation is hard-coded to use Java language level 5! This is what was causing JWSC to fail. Unfortunately my decompiler couldn't reconstruct the full source code for this class, so I had no way to correct the problem and rebuild the class, but I needed to fix it somehow.
I resorted to using Hex Fiend, a hex editor, to see if I could hack the .class file directly. This worked like a charm.
Since the hard-coded value is a simple string, it is stored as text in the .class file and editing it is easy. I searched for the '1.5' string and simply replaced the '5' character with a '7' character to force the language level validation to be at the 1.7 level.
Once I put this modified file on my class path and reran my build, everything compiled perfectly. Checking the compiled code with javap -v reports the correct language level (51 = 1.7)...
javap -v
minor version: 0
major version: 51
So the value passed in the source parameter to JWSC is independent to the language level used for source code validation that's done before compilation, that strikes me as odd, but that's how it is.
I've not tried to see if this would work in the latest WebLogic release, this applies to 12.1.2, the issue may be fixed in later versions already.
This is not a great fix, but it solved an immediate roadblock. Enjoy!
-i
Facebook
Twitter
Google+