UnmodifiableCollection causes UnsupportedOperationException in MethodSimulator #65
Comments
|
Some more info after more trial and error: @SuppressWarnings("unchecked")
public List<Subscription> findAll(final Integer userId, final Integer type, final String code) {
Criteria c = currentSession()
.createCriteria(FollowingEntity.class)
.add(Restrictions.eq("userId", userId));
System.out.println(type);
System.out.println(code);
if (type != null) {
c.add(Restrictions.eq("type", type));
} else {
c.add(Restrictions.ne("type", 0));
}
if (code != null) {
c.createCriteria("company")
.add(Restrictions.eq("stockCode", code));
}
return ((List<FollowingEntity>) c.list())
.stream()
.map(Subscription::new)
.collect(Collectors.toList());
}This has the exception. Change the first if statement block to the following c.add(Restrictions.eq("type", 1)); // works fine
c.add(Restrictions.eq("type", type.intValue())); // nope
c.add(Restrictions.eq("type", (int)type.intValue())); nope
c.add(Restrictions.eq("type", null)); // works fine
c.add(Restrictions.eq("type", "0")); // works fine
c.add(Restrictions.eq("type", type.toString())); // nopeThis works if (type != null) {
if (type == 1) {
c.add(Restrictions.ne("type", 1));
} else if (type == 2) {
c.add(Restrictions.ne("type", 2));
}
}Avoiding the unbox of Integer, and using int throughout the code does not have this issue either. |
|
Perhaps the problem is here instead. |
|
For the time being, I am making UnmodifiableElement return new HashSets instead of Collections.unmodifiableSet. Unsure of what the side effects may be, but for the time being I just need the spec to be generated. |
|
Unfortunately I can't reproduce the error... Could you please provide more in that example, including imports and hibernate deps? Or alternatively edit the systemtest project. |
|
Will try. Like I said, it may have something to do with Hibernate's handling of unboxing integers / ints. |
The root cause of the exception stems from the usage of null constants being passed into methods. The arguments are treated as Object then in the bytecode are converted to their required concrete types through the Load instruction, which leads to the UnsupportedOperationException thrown by the UnmodifiableCollection.
|
@sdaschner please see the branch diff i have posted for reproduction of the error I have experienced. Problem not with Hibernate, but with "null" arguments to methods. After a bit more debugging, the UnmodifiableElement seems to be pushed from a SizeChange instruction in simulateSizeChange (MethodSimulator.java:245). I wish I knew more about the bytecode instruction set, but I think this is about as far as I can diagnose. Like I said, my hack right now is to simply make UnmodifableElement return a clone rather than a UnmodifiableCollection. |
|
Just to provide as much info as I can, here's the expressions I managed to extract when the error occurs in the test project. List of Instructions - the LOAD instruction is where error occurs. Relevant Instance Variables |
The root cause of the exception stems from the usage of null constants being passed into methods. The arguments are treated as Object then in the bytecode are converted to their required concrete types through the Load instruction, which leads to the UnsupportedOperationException thrown by the UnmodifiableCollection.
|
Deployed in a new |
|
Legend =) |
@sdaschner really bad one for me. I don't know why it doesn't like the code I'm writing, and I need this to work. :'(
I can't really see this being a problem with Lombok. Could be Hibernate.
The text was updated successfully, but these errors were encountered: