[
https://issues.jboss.org/browse/ISPN-6085?page=com.atlassian.jira.plugin....
]
Sanne Grinovero edited comment on ISPN-6085 at 1/20/16 11:36 AM:
-----------------------------------------------------------------
+1 for [~dan.berindei]'s idea of accepting these are just estimates.
But if we accept that, we should also accept that it might have been set to size zero
(disabled the cache). I think it's safer to over-estimate than underestimate memory
utilization, so what about simplifying this code and ignore the autobox cache?
was (Author: sannegrinovero):
+1 for [~dan.berindei]'s idea of accepting these are just estimated.
But if we accept that, we should also accept that it might have been set to size zero
(disabled the cache). I think it's safer to over-estimate than underestimate memory
utilization, so what about simplifying this code and ignore the autobox cache?
Avoid using sun.misc.VM
-----------------------
Key: ISPN-6085
URL:
https://issues.jboss.org/browse/ISPN-6085
Project: Infinispan
Issue Type: Task
Components: Core
Affects Versions: 8.1.0.Final
Reporter: Sanne Grinovero
Assignee: William Burns
The function
{{org.infinispan.container.entries.PrimitiveEntrySizeCalculator.IntegerCacheConstraints.calculateMaxIntCache()}}
is using {{sun.misc.VM}}.
This class is being moved and "idden" in Java 9:
-
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037853....
Could we try avoiding the need for this, or explore alternatives?
One could use reflection to see if the class is available without loading it explicitly,
but that still needs some sensible fallback for the case in which the class isn't
available.
Even if this looks like a small detail, this completely blocks the possibility to test
Infinispan on Java 9.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)