[infinispan-issues] [JBoss JIRA] (ISPN-6085) Avoid using sun.misc.VM

Dan Berindei (JIRA) issues at jboss.org
Wed Jan 20 11:19:00 EST 2016


    [ https://issues.jboss.org/browse/ISPN-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151279#comment-13151279 ] 

Dan Berindei commented on ISPN-6085:
------------------------------------

I think the {{java.lang.Integer.IntegerCache.high}} property is only used internally by {{-XX:AutoBoxCacheMax=<size>}} and is removed during boot by {{VM.saveAndRemoveProperties()}}, so it's not available via {{System.getProperty()}}.

We could use reflection to read the value from the {{Integer.IntegerCache}} class, or we could assume it's 127 and accept that our size estimate is going to be too high when {{-XX:AutoBoxCacheMax=<size>}} is used.

> 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.html
> 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)


More information about the infinispan-issues mailing list