We Keep Coding

Can Java 10 type inference for local variables infer void?

With Java 10, we can use type inference.
String s1 = "hello"; // before Java 10
var s2 = "hello"; // now
However, there is one thing which we couldn't do before: have variables of type void.
So, in previous versions we simply couldn't define the variable type void. But now we can assign result of method returning void to the variable:
void emptyMethod() { }
...
void v1 = emptyMethod(); // won't compile
var v2 = emptyMethod(); // no problem at all
The question is - why does it even compile, what purpose does it serve? Do you have any use case for this strange thing?
Variable of type void has no methods, it cannot be even used as a parameter of a method.

Why do you think it compiles? It doesn't compile:
> javac Main.java
Main.java:5: error: cannot infer type for local variable v2
var v2 = emptyMethod(); // no problem at all
^
(variable initializer is 'void')
1 error
You probably use IntelliJ IDEA, do you? IDEA currently does not detect such kind of an error. There is a bug for that: https://youtrack.jetbrains.com/issue/IDEA-188623

Weird result from "#SuppressWarnings"

Eclipse was warning me that a local variable randInt might not be initialized (it was). So I added the first line:
#SuppressWarnings("all")
return randInt;
The warning went away, but I'm getting two new errors on the first line:
Syntax error: insert "enum Identifier" to complete EnumHeaderName, and
Syntax error: insert "EnumBody" to complete BlockStatement
What on earth? It's surprisingly hard to find information about #SuppressWarnings. Is there a more precise way of getting rid of this specific warning than using "all"?
Minimal, complete, verifiable example:
public class SuppressTest {
public int cut() {
int randInt = 0;
#SuppressWarnings("all")
return randInt;
}
}

You can't insert #SuppresWarnings on a return statement. In java 8 you can annotate only classes, methods/constructors, fields, parameters and (new in java 8) local variables.
So in your case java can't parse what you have written. Move the #SuppressWarnings at the method level.

ClassCastException: java.lang.Object incompatible with com.company.base.BaseDocument

I have a piece of code that has to be JDK 1.4 compliant. And below is a snippet which gets a runtime exception.
BaseDocument baseDocument = new BaseDocument();
baseDocument.setGuid("{somethinghere}");
List document = new ArrayList();
document.add(baseDocument);//runtime error
Exception:
java.lang.ClassCastException: [Ljava.lang.Object; incompatible with [Lcom.company.base.BaseDocument;
I don't understand why we cant cast it to a java Object(since Object is the parent class of all Classes in java).
Im using IBM JDK version 1.7 with Eclipse compiler settings set to JDK 1.4
Please explain what mistake I'm doing here. I know generics is the standard, but it has to be JDK 1.4 compliant :(
Thanks in advance!

Actually, the message says:
[Ljava.lang.Object; incompatible with [Lcom.company.base.BaseDocument;
The [ characters are very important. Apparently, something is attempting cast something of type Object[] to BaseDocument[]; i.e. you are dealing with array types here.
However, I have no idea what is actually causing the problem here, because (on the face of it) there should be no instances of BaseDocument[] in the code you have posted. Furthermore, I don't believe your claim that that exception is thrown at that line. Here is the source code of the ArrayList.add method (Java 6 version):
private transient Object[] elementData;
public boolean add(E e) {
ensureCapacity(size + 1); // Increments modCount!!
elementData[size++] = e;
return true;
}
An assignment of a reference into an object array (Object[]) does not entail any runtime type-checks, and cannot throw a ClassCastException.
If you showed us a complete stacktrace, it would be easier to diagnose.

Compilation error while using Tuple2 in Spark Java Application

I am trying out Spark Programming examples using Java 1.8 in Eclipse Luna and have the following code -
JavaPairRDD<String, Integer> counts = ones
.reduceByKey(new Function2<Integer, Integer, Integer>() {
#Override
public Integer call(Integer i1, Integer i2) {
return i1 + i2;
}
});
List<Tuple2<String, Integer>> output = counts.collect(); //Compilation Error
I am using M2Eclipse to build and create the jar and using spark-submit to execute the jar in my local. The jar is working and printing the correct output but Eclipse always shows the above mentioned line as a compilation error - The type Tuple2 is not generic; it cannot be parameterized with arguments <String, Integer>
Even the programming examples referred in the Spark webpage uses the same notation for Tuple2. https://spark.apache.org/docs/0.9.0/java-programming-guide.html
I am not able to understand why Eclipse is showing it as a compilation error since the return type of the collect call is a List<Tuple2<String,Integer>>
Any help is greatly appreciated.

As mentioned by #Holger in the comments, 2 scala-library jars were added to the build path. Removed the earlier version and compilation errors disappeared.

It helps on my problem on IntelliJ Idea, too. I called a function in which a parameter is a generic type with Tuple2 as a parameter. It always show an error but I can pass the compilation. It confused me for several days. After removing several dependent sharded-jars(in which it contains something related scala-libiary), the error disappeared.

Why can't you directly cast type in java?

In the code snippet below, why would lines 1 & 2 be fine and line 3 cause a compile error? Aren't the first two lines functionally equivalent to the third?
Loader loader = getLoaderManager().getLoader(0);
PatientLoader patientLoader = (PatientLoader) loader;
patientLoader = (PatientLoader) getLoaderManager().getLoader(0); // ERROR!
Throws this:
java: somepath/Patient.java:99: inconvertible types
found : android.content.Loader<java.lang.Object>
required: com.example.package.PatientLoader
PatientLoader indirectly extends Loader<>.
I come from a C# background and in C# this would not be a problem, so maybe I'm missing something about the Java type system.
PatientLoader extends AsyncTaskLoader<Cursor>. And anyone familiar w/ Android SDK would know AsyncTaskLoader<> extends Loader<>.

It has nothing to do with the placement of the parenthesis.
This problem has to do with Generics:
E.g. Compilation failure:
Loader<Object> loader = getLoaderManager().getLoader(0);
PatientLoader ch = (PatientLoader)loader; // Will show compile error (Cannot cast from Loader<Object> to PatienLoader)
But this will compile fine:
Loader<?> loader = getLoaderManager().getLoader(0);
PatientLoader ch = (PatientLoader)loader; // Compiles fine.
The difference is the <Object> generic versus the <?> generic declaration.
The problem is that getLoader(int) is defined to return a Loader<D>. This means that 'getLoaderManager().getLoader()' in the statement below gets interpreted as a Loader<Object> and not a Loader<?>.
PatientLoader ch = (PatientLoader)getLoaderManager().getLoader(0); // Compile error.
I think this is a 'bug' in the SDK. The method getLoader(int) should have been defined to return a Loader<?> and not a Loader<D>.