Byte Integer type param interfaces
Brought to you by:
bonniot
Menu
▾
▴
#79 Byte Integer type param interfaces
set() converts Integer to Byte?
\Nice\Test>java -jar t.jar
set 1 class java.lang.Byte
get 1 class java.lang.Integer
Exception in
thread "main"java.util.NoSuchElementException
at test.fun.get(I:\pls\Nice\Test\..\test:10)
at test.dispatch.get()
at test.fun.main(I:\pls\Nice\Test\..\test:17)
void main(String[] args){
HashPropertyMap<int, double> h = new
HashPropertyMap();
h.set(1, 2.5);
h.get(1);
}
public interface ReadablePropertyMap<K, V> {
V get(K key);
}
public interface ReadWritePropertyMap<K, V> extends
ReadablePropertyMap<K, V> {
void set(K key, V value);
}
public class HashPropertyMap<K, V>
implements ReadWritePropertyMap<K, V> {
private HashMap<K, V> data = new HashMap();
set(key, value){
let o = object(key);
if (o != null) println("set " key " " o.getClass());
data.put(key, value);
}
get(key){
let o = object(key);
if (o != null) println("get " key " " o.getClass());
let res = data[key];
if (res == null)
throw new NoSuchElementException();
return res;
}
}
Logged In: YES
user_id=536291
Nice compiler version 0.9.6 prerelease (build 2004.01.05,
05:42:10 UTC)
Logged In: YES
user_id=688815
Something is wrong with the code generated in the main
method and but I have no idea why it happens yet.
Logged In: YES
user_id=536291
void main(String[] args){
HashPropertyMap<int, double> h = new HashPropertyMap();
h.set(32767, 2.5);
h.get(32767);
}
gives:
\Nice\Test>java -jar t.jar
set 32767 class java.lang.Short
get 32767 class java.lang.Integer
Exception in thread "main" java.util.NoSuchElementException
at test.fun.get(I:\pls\Nice\Test\..\test:10)
at test.dispatch.get()
at test.fun.main(I:\pls\Nice\Test\..\test:17)
Logged In: YES
user_id=688815
In your examples the codegeneration is wrong but even if this
case is fixed, the problem caused by new Integer(1).equals
(new Byte(1)) returning false could still occur i fear.
Logged In: YES
user_id=536291
> new Integer(1).equals(new Byte(1)) returning false
I'm not even going to pretend that I understand what's
happening. From an "application programmers" perspective
the key - 1 - in these adjacent statements should turn out to
be the same thing.
h.set(1, 2.5);
h.get(1);
Meanwhile I'll make some progress using keys like 40003,
40004, ...
Logged In: YES
user_id=688815
I found an example where the codegeneration is correct but
the result is unexpected because of the java implementation
of the Object versions of the primitives.
int x = 1;
long y = x;
Set<long> set = new HashSet();
set.add(x);
println(set.contains(y));
Logged In: YES
user_id=688815
The difference in compiling the literals in the get an the set
method is caused by whether the instanciatedDomain in
CallExp.java is calculated or not.
Daniel I think this one is for you to fix.
Logged In: YES
user_id=88952
This bug has been fixed. The next release of the compiler will
include this correction. In the mean time, I encourage you try
the development version. It contains a version of the compiler
that fixes the bug. Please try it and reopen the bug-report if
you find any problem with it.
To know how to get an install the development version of the
compiler that fixes this bug, please read
http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/DevelopmentVersion
Thanks again for your help by submiting this bug report.
Daniel Bonniot