While writing some java code I run across an Exception that I did not recognise, the java.lang.VerifyError. Some googling indicated that this is often an jvm/javac bug and I'm curious if my case is.
The lines I suspect are
private Pair<Integer/*used size*/,Pair<K,V[]>[]>[] map=(Pair<Integer,Pair<K,V[]>[]>[])Array.newInstance(Pair.class,63);//good start number
and
map[b]=new Pair<Integer,Pair<K,V[]>[]>(7,(Pair<K,V[]>[])Array.newInstance(Pair.class,7));
but I'm far from certain.
Is this a compiler bug or is my code at fault.
Those lines are workarounds for the failure of array creation for arrays of generics that I found somewhere.
Code attached.
package osm2spacebook;
import java.util.Iterator;
import java.lang.reflect.Array;
import java.util.NoSuchElementException;
public class MultiMap<K,V> implements Iterable<K>{
private int num_keys;
@SuppressWarnings("unchecked")
private Pair<Integer/*used size*/,Pair<K,V[]>[]>[] map=(Pair<Integer,Pair<K,V[]>[]>[])Array.newInstance(Pair.class,63);//good start number
@SuppressWarnings("unchecked")
private int bucket(K key){//position in bucket
int h=key.hashCode();
int b=h%map.length;
if(map[b]==null)
map[b]=new Pair<Integer,Pair<K,V[]>[]>(7,(Pair<K,V[]>[])Array.newInstance(Pair.class,7));
return b;
}
private int position(K key){//position within bucket
int b=bucket(key);//IMPORTANT this must use the buket function to obtain this otherwise it is a race
for(int i=0;i<map[b].v1;i++)
if(map[b].v2[i].v1==key)
return i;
if(map[b].v1==map[b].v2.length)
map[b].v2=java.util.Arrays.copyOf(map[b].v2,map[b].v1*2);
return map[b].v1++;
}
public V put(K key,V value){
Pair<K,V[]> m=map[bucket(key)].v2[position(key)];
for(int i=0;i<m.v2.length;i++)
if(m.v2[i]==value)
return value;
m.v2=java.util.Arrays.copyOf(m.v2,m.v2.length+1);
return m.v2[m.v2.length-1]=value;
}
public V[] get(K key){
V[] v=map[bucket(key)].v2[position(key)].v2;
return java.util.Arrays.copyOf(v,v.length);
}
public V[] remove(K key){
throw new UnsupportedOperationException("Not implemented"); //TODO
}
public V remove(K key,V value){
throw new UnsupportedOperationException("Not implemented"); //TODO
}
public boolean contains(K key){
return position(key)<map[bucket(key)].v1;
}
public int numKeys(){
return num_keys;
}
public Iterator<K> iterator(){
return new Iterator<K>(){
int bucket=0;
int position=0;
public boolean hasNext(){
while(bucket<map.length){
if(map[bucket]!=null)
if(position<map[bucket].v1)
return true;
else
position=0;
bucket++;
}
return false;
}
public K next(){
if(hasNext())//positions cursor on next element if any
return map[bucket].v2[position++].v1;//updates position after read
else
throw new NoSuchElementException();
}
public void remove(){
throw new UnsupportedOperationException("Remove not supported in multimap iterator du to ambiguity");
}
};
}
}
and the Pair class this depends on
package osm2spacebook;
public class Pair<T1,T2>{
public T1 v1;
public T2 v2;
public Pair(T1 t1,T2 t2){
v1=t1;
v2=t2;
}
}
Full error message
Exception in thread "main" java.lang.VerifyError: (class: osm2spacebook/MultiMap, method: position signature: (Ljava/lang/Object;)I) Incompatible object argument for function call
at osm2spacebook.SqlOutput.<init>(SqlOutput.java:64)
at osm2spacebook.OsmImport.<init>(OsmImport.java:142)
at osm2spacebook.OsmImport.main(OsmImport.java:280)
Line 64 of SqlOutput is the following
private MultiMap<Integer,Integer> edge_index=new MultiMap<Integer,Integer>();
A VerifyError usually means that you loaded in a class file that is somehow malformed or which references another class file that has changed in a way that causes the code in another class file to no longer be valid. For example, if you compiled a class file that referenced a method in some other class, then independently modified and recompiled the second class after altering that method's signature, you'd get this sort of error.
I'd suggest doing a clean build and seeing if this issue goes away. If not, check whether you're using up-to-date JARs and source files.
For the unfortunate soul out there who runs across this issue... I've solved it twice now, 2 different ways (probably same underlying solution). I hope this saves you from the days I spent researching and beating head on wall...
My Project: SBT 0.13 / Lift 2.5 / Scala 2.10.2
1st SOLUTION: I upgraded from SBT 0.11 / Lift 2.4 / Scala 2.9.2 to SBT 0.13 / Lift 2.5 / Scala 2.10.2. This was hell to get all the dependencies updated properly (took a day or 2), but it worked.
2nd SOLUTION: I had no more-recent version to which I could upgrade, so I found another option: running an SBT clean didn't do the trick, so I went further and renamed (effectively deleting as far as SBT knew) all intermediate/derivative object folders (just added a '.archived' to their names) in the project folder structure (to force SBT to rebuild/populate everything from scratch), ie.
After that, SBT re-downloaded what it needed, rebuilt the contents of those folders, and everything worked. And as mentioned earlier, I believe this would have worked the first time also. I believe the upgrade did nothing other than create a scala_2.10.2 folder to populate freshly with intermediate/compiled objects, similar to me renaming the 'target' folders.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With