| Java 1.8 and ExtendProperties [message #1744671] |
Thu, 29 September 2016 07:57  |
Eclipse User |
|
|
|
Hi Epsilon Team,
I am currently evaluating whether i can use epsilon in a java standalone application while using a java 1.8 jdk as a runtime environment.
I found out that everything seems to be working fine, except the extendedProperties.
I am using ExtendProperties rather excessivley ( > 400k set properties in total) and everything is fine while using a 1.7 jdk.
When using java 1.8 however, your Cache implementation in the ExtendedProperties returns wrong properties for certain objects if the number of properties exceeds a certain (unknown) limit.
I have attached a minimal example that shows the effect.
I have a simple model with 300k entities.
Each entity has a single attribute, that is unique accross the model.
I set an extended Property for the first 150k that is a copy of that attribute and perform a check afterwards that prints all entities (within the first 150k) to the console whose extendedProperty value does not equal the attribute value.
The list is empty when using java 1.7 (as expected) but contains 4 entries when using java 1.8.
My first guesses are that something must have changed regarding java garbage collection ( you are using weak references in your Cache implementation) or regarding your hashCode generation ( see your IdentityBasedWeakReference Implementation).
When using my own implementation of your ExtendedProperties class that uses this collection
protected LinkedHashMap<Object, LinkedHashMap<String, Object>> properties = new LinkedHashMap<Object, LinkedHashMap<String, Object>>();
instead of your Cache implementation, i get the correct extended Properties in java 1.7 and java 1.8.
Can you please check the example and explain the use of your Cache Implementation?
Greetings
Sebastian
[Updated on: Thu, 29 September 2016 07:59] by Moderator |
|
|
|
|
|
|
|
| Re: Java 1.8 and ExtendProperties [message #1745040 is a reply to message #1745020] |
Tue, 04 October 2016 08:24  |
| Eclipse User |
|
|
|
You're right: EObject uses the default hashCode, hmm. (We force this anyway because Epsilon with more things than just EMF, anyway.)
It might be because LinkedHashMap uses the hashCode() plus the equals() method: the hashCode is used to go to a bucket and then it loops through the linked elements in the bucket testing with equals. At least, this is what the JDK8 source code suggests:
final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
if ((tab = table) != null && (n = tab.length) > 0 &&
(first = tab[(n - 1) & hash]) != null) {
if (first.hash == hash && // always check first node
((k = first.key) == key || (key != null && key.equals(k))))
return first;
if ((e = first.next) != null) {
if (first instanceof TreeNode)
return ((TreeNode<K,V>)first).getTreeNode(hash, key);
do {
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
return e;
} while ((e = e.next) != null);
}
}
return null;
}
So in this case, the issue might have been in our IdentityBasedWeakReference wrapper, which originally implemented equals(...) as hashCode() == other.hashCode(). I'm pretty sure I tried replacing it with direct object comprison and it didn't help, but I'll look again into it. Perhaps the fix was easier than I thought  .
As for Epsilon 1.4, it's coming soon: the release review is underway. Hopefully it should be ready within October.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04012 seconds
Home