For loop with generic collection fails to compile in Java 7 - java

Maybe someone can explain the behaviour below. I know there were some generic type-handling changes from Java 6 to 7, but I couldn't find one to explain this.
This is happening with this library:
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.framework</artifactId>
<version>3.2.2</version>
</dependency>
And the following demonstration code:
import org.apache.felix.framework.util.manifestparser.ManifestParser;
ManifestParser manifestParser = new ManifestParser(null, null, null, null);
for (Capability capability : manifestParser.getCapabilities()) {
capability.toString();
}
// where the signature of getCapabilities() is:
// public List<Capability> getCapabilities() { return m_capabilities; }
// and there are no other methods with similar signatures or names
This demo code compiles just fine with JDK 6 (x86, 1.6.0_45, 32-bit), but fails to compile with JDK 7 (x86, 1.7.0_25, 32-bit, same host):
// line number matches the for loop
java: incompatible types
required: org.apache.felix.framework.capabilityset.Capability
found: java.lang.Object
After some head scratching, I have a workaround but no explanation. The following modification to the demo code compiles with JDK 7:
ManifestParser manifestParser = new ManifestParser(null, null, null, null);
List<Capability> capabilities = manifestParser.getCapabilities();
for (Capability capability : capabilities) {
capability.toString();
}
Why is this?

See How to compile mavenized OSGi 4.3 bundle with OpenJDK 7?
Because of the OSGi classes in that felix jar, you cannot use it to compile against with Java 7.

Are you sure that there is no classpath problem, like different versions of the same class in the classpath? This could be possible if you have in the classpath two versions of the same class, one for java 1.4 returning List and one for java 5+ returning List<Capability>.

Related

Standard Method TEXT is undefined when compiling jasper report

When I package my stand-alone-java-application, that compiles, renders and prints Jasper-Reports, in a fat jar with all dependencies, I get the error that the function TEXT – a function used in the report and defined in the net.sf.jasperreports-functions-library is not found.
The method TEXT(Integer, String) is undefined for the type [...]
value = IF(LEN(TEXT(((java.lang.Integer)parameter_X.getValue()),"#"))==2,"***",REPT("*",6-LEN(TEXT(((java.lang.Integer)parameter_X.getValue()),"#")))) //$JR_EXPR_ID=58$
Other functions from the same library work. When I run the application with gradle run, the function is found and the report can be printed. The library is on my classpath.
There are several similar questions on this site and Stackoverflow, but neither provided answers, that worked for me. In the following, I will explain what I tried:
In my build.gradle-File I defined dependencies to the following libraries:
implementation('net.sf.jasperreports:jasperreports:6.18.1')
implementation('net.sf.jasperreports:jasperreports-functions:6.18.1')
In my java-Files, I created a DesignFile and statically imported the functions into it. I tried two methods:
Method 1 as given in an answer in this thread: Unresolved symbols when compiling jasper report
/*…*/
designFile = JRXmlLoader.load(sourceFile.getAbsolutePath());
designFile.addImport("static net.sf.jasperreports.functions.standard.TextFunctions.*");
designFile.addImport("static net.sf.jasperreports.functions.standard.MathFunctions.*");
designFile.addImport("static net.sf.jasperreports.functions.standard.DateTimeFunctions.*");
designFile.addImport("static net.sf.jasperreports.functions.standard.LogicalFunctions.*");
JasperReport compiledReport = JasperCompileManager.getInstance(ctx).compile(designFile);
/*…*/
Method 2: importing each function on its own
public static String[] textFunctions(){
return new String[]{"BASE", "CHAR", "CLEAN", "CODE", "CONCATENATE", "DOUBLE_VALUE",
"EXACT", "FIND", /*"FIXED", */"FLOAT_VALUE", "INTEGER_VALUE", "LEFT", "LEN", "LONG_VALUE",
"LOWER", "LTRIM", "MID", "PROPER", "REPLACE", "REPT", "RIGHT", "RTRIM", "SEARCH", "SUBSTITUTE",
"T", /*"TEXT",*/ "TRIM", "UPPER"};
}}
/*…*/
designFile = JRXmlLoader.load(sourceFile.getAbsolutePath());
for (String textFunction : textFunctions()){
designFile.addImport("static net.sf.jasperreports.functions.standard.TextFunctions." + textFunction);
}/* similarly for logical functions, numeric functions and datetime functions*/
}
JasperReport compiledReport = JasperCompileManager.getInstance(ctx).compile(designFile);
/*…*/
As you can see, the function TEXT is commented out. That’s because the program fails at runtime when run with “gradle run”, when I comment it in:
net.sf.jasperreports.engine.JRException: Errors were encountered when compiling report expressions class file:
1. The import net.sf.jasperreports.functions.standard.TextFunctions.TEXT cannot be resolved
import static net.sf.jasperreports.functions.standard.TextFunctions.TEXT;
The same thing is true with most datetime-functions, in fact, only TIME can be imported to the DesignObject without error at runtime
In addition to that, when I type net.sf.jasperreports.functions.standard.TextFunctions. in my IDE, the content-assist shows a list of available functions, yet TEXT is missing.
I suspected, that the function is simply missing in the library, but it is there. In the .gradle/cache/modules-2/files-2.1/… directory, there is the jar with the TextFunctions.java, that contains the function TEXT:
When building the FatJar with dependencies, I have a TextFunctions.class-File in it, that contains the TEXT-Function as well.
In my jar, there are two jasperreports_extension.properties on the root level:
with the smaller one (from the jasperreport-functions-dependency) containing the following lines:
net.sf.jasperreports.extension.registry.factory.functions=net.sf.jasperreports.functions.FunctionsRegistryFactory
net.sf.jasperreports.extension.functions.datetime=net.sf.jasperreports.functions.standard.DateTimeFunctions
net.sf.jasperreports.extension.functions.math=net.sf.jasperreports.functions.standard.MathFunctions, net.sf.jasperreports.functions.standard.LogicalFunctions
net.sf.jasperreports.extension.functions.text=net.sf.jasperreports.functions.standard.TextFunctions
net.sf.jasperreports.extension.functions.report=net.sf.jasperreports.functions.standard.ReportFunctions
Funnily enough, commenting out TEXT, running it locally with gradle run, it works without problems. But packaging it and running it with java -jar it fails to find this function. And statically importing this function leads to gradle run failing as well.
What is happening and how can I fix this? I want to distribute my FatJar on a server and run it, but this problems makes it impossible for me.

The type org.apache.axiom.om.impl.llom.OMStAXWrapper is not visible

I have below code in old version. Now I have upgraded the axis2 version from 1.1.1 to 1.6.2. It then have compile problem as indicated below. I find in the web with link: https://issues.apache.org/jira/browse/AXIS2-4363
But I do not understand it. First of all Do I need to amend code? If yes, is there any example for me to follow?
if (reader.getEventType() == javax.xml.stream.XMLStreamConstants.START_ELEMENT && reader.getName().equals(new javax.xml.namespace.QName(org.apache.axiom.om.impl.MTOMConstants.XOP_NAMESPACE_URI, org.apache.axiom.om.impl.MTOMConstants.XOP_INCLUDE)))
{
java.lang.String id = org.apache.axiom.om.util.ElementHelper.getContentID(reader, "UTF-8");
object.set_return(((org.apache.axiom.soap.impl.builder.MTOMStAXSOAPModelBuilder)
((org.apache.axiom.om.impl.llom.OMStAXWrapper)
reader).getBuilder()).getDataHandler(id));
<--- highlight this The type org.apache.axiom.om.impl.llom.OMStAXWrapper is not visible
reader.next();
reader.next();
}
This appears to be generated code. If you upgrade from Axis2 1.1.1 to 1.6.2, then you need to regenerate that code. Note that the usual best practice applies here: generated code should always be generated during the build, not checked into the source control system.

ConcurrentHashMap crashing application compiled with JDK 8 but targeting JRE 7

I ran into a very unexpected error today and while I was able to find a way to fix the problem as a whole I'm not sure I completely understand why it did what it did.
The code I'm working with was originally written with a JDK 7 environment of course targeting JRE 7. In the code I was using a ConcurrentHashMap and needed to iterate over the keys in the map. For this I was using the map.keySet() which according to the JavaDocs should return a Set<K>. This worked fine until our build environment switched to JDK8.
When we moved to JDK8 I ensured that I was calling a target/source for 1.7 when calling the javac. So I was pretty surprised when the code started failing right when it wanted to iterate through the keys of the map. No error was thrown, no exception, the thread just simply stopped. After doing some research I found that Java8's implementation for ConcurrentHashMap the .keySet() method returns a KeySetView<K,V>.
I fixed the problem by switching from using the map.keySet() to getting an Enumeration<K> using map.keys().
Now my guess as to the problem is that although the project was compiled targeting Java7 since the JDK8 was used the Java8 libraries were included, but why didn't it thrown an error or an exception when it hit the mismatch?
As asked here is a code snippet:
class MapProcessing
{
private ConcurrentHashMap<String, Object> map = new ConcurrentHashMap<String, Object>();
public MapProcessing()
{
map.put("First",new Object());
map.put("Second",new Object());
map.put("Third",new Object());
}
public void processing()
{
// when calling this type of loop causes a freeze on our system.
for(String key : map.keySet())
{
System.out.println(key);
}
}
public void working()
{
// This is what I had to do to fix the problem.
Enumeration<String> keys = map.keys();
while(keys.hasMoreElements())
{
String key = keys.nextElement();
System.out.println(key);
}
}
}
We are compiling using Oracle JDK 8 build 40 using a target for 1.7 and source 1.7 in the javac on a Windows 2012 server.
The code is running using Oracle JVM 7 build 25 running on Windows 2012 server.
If i compile your code with Java 8 and javac -source 1.7 -target 1.8 and then run it with Java 7 i get an
Exception in thread "main" java.lang.NoSuchMethodError:
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
at stackoverflowt.Test.processing(Test.java:20)
at stackoverflowt.Test.main(Test.java:27)
This is because the the byte code looks like
public void processing();
Code:
0: aload_0
1: getfield #4 // Field map:Ljava/util/concurrent/ConcurrentHashMap;
4: invokevirtual #10 // Method java/util/concurrent/ConcurrentHashMap.keySet:()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
7: invokevirtual #11 // Method java/util/concurrent/ConcurrentHashMap$KeySetView.iterator:()Ljava/util/Iterator;
10: astore_1
and referring explicitly to ConcurrentHashMap$KeySetView which is not present in Java 7. I am on Mac with Java 1.7.0_79 and 1.8.0_45
If you change the code to (only use the Map Interface):
private Map<String, Object> map = new ConcurrentHashMap<String, Object>();
then it work's for me. Bytecode then looks like
public void processing();
Code:
0: aload_0
1: getfield #4 // Field map:Ljava/util/Map;
4: invokeinterface #10, 1 // InterfaceMethod java/util/Map.keySet:()Ljava/util/Set;
9: invokeinterface #11, 1 // InterfaceMethod java/util/Set.iterator:()Ljava/util/Iterator;
14: astore_1
Whenever you build a project using a newer JDK using the -source argument targeting an older version, you'll get this compiler warning:
warning: [options] bootstrap class path not set in conjunction with -source 1.7
This blog entry talks about what it means.
Basically, you get this warning because Java is compiling it using older language rules but against the newer class library... and there are some compatibility issues with the Java 8 versions as Oracle moved some of the internal classes around.
The fix is to use the -bootclasspath argument to point it at the rt.jar from the older version while compiling.

Why can't I call UIComponent.setValueExpression()?

I have received a project with many lines like the following ones:
HtmlOutputText content = new HtmlOutputText();
ValueBinding vb = dashBoardBean.getApplication()
.createValueBinding(columnas[cont][1]);
content.setValueBinding("value", vb);
Eclipse, with Java 5, marks them as deprecated (both class ValueBindingand the method setValueBinding).
So I looked the API for HtmlCommandLink.setValueBinding() (it actually is at UIComponentBase) and found this:
Deprecated. This has been replaced by UIComponent.setValueExpression(java.lang.String, javax.el.ValueExpression).
So I changed the last line code to the following:
content.setValueExpression("value", null);
But now I get a compiler error.
I also tried:
UIComponent uic;
uic.setValueExpression("", null);
And get the same error:
The type javax.el.ValueExpression cannot be resolved. It is indirectly referenced from
required .class files
What's the meaning of that error? How can I solve it?
You need the JSF 1.2 (or greater) jars on your classpath.

JDK compiler error

Before anyone screams about EOL'ed JDK, I'd like to point out that my question is not about how to compile the following. There is a real question here and it's not about JDK 1.5 being EOL'ed...
The following under JDK 1.5, up to 1.5.0_22 (the last one I could find) produces on my system a compiler error:
private Object[] boozinga() {
boolean b = Math.abs(42) > 0;
Object[] res = new Object[1];
res[0] = b ? new int[1] : new String[1];
return res;
}
Changing the Math.abs(42) > 0 to true allows compilation.
Changing the ternary "assignment" to an if/else allows compilation.
Using JDK 1.6 allows compilation.
So I was wondering: is there something not legal in the above code under Java 1.5 and that is allowed under Java 1.6?
Does it crash for those of you that are under Java 1.5 too?
The crash says something like this:
An exception has occured in the
compiler (1.5.0_22). Please file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport)
after checking the Bug Parade for
duplicates. Include your program and
the following diagnostic in your
report. Thank you.
I take it filling a bug report for an EOL'ed JDK is an exercice in futility but still, I'd still like to know if the above is valid Java 1.5 code or not.
I think it is legal. The evidence is that JDK 1.6.0_21 compiles it with options -source 1.5 -target 1.5. Can't you use JDK 1.6 with these options to compile and JRE 1.5 to run?
It crashes for me, too (JDK 1.5.0_12). It crashes for me even with:
public Object boozinga() {
boolean b = true;
Object res = b ? new int[1] : new String[1];
return res;
}
The difficulty for the compiler is that the type of b ? new int[1] : new String[1] is java.lang.Object & java.io.Serializable & java.lang.Cloneable.
The problem here is that the compiler has trouble to decide the type of the expression b ? new int[1] : new String[1]. I had something like this before (with 1.1.8 or 1.2, I think - but with a real error message, not a compiler crash), and then simply used a cast to help the compiler here.
res[0] = b ? (Object)new int[1] : new String[1];
I didn't look what the language specification says about this - but the compiler should never crash with an exception, it should give a real error message.

Categories

Resources