Why is assert used in the Integer.valueOf method for the Integer class?

Question

I delved into how the Integer class actually uses cached objects, and I found the code below in the Integer.valueOf method:

 public static Integer valueOf(int i) { assert IntegerCache.high >= 127; if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); } 

My question is:

• What is the use of assert IntegerCache.high >= 127; I read that assert provides an efficient way to detect and fix error programs . But this is runtime code, so why would anyone use assert?
• And when will he throw an AssertionError in this scenario?

Answer 1

The purpose of the statements is to establish invariants and document the implementation. This is confirmed by the fact that when you enter the valueOf method, the value of IntegerCache.high guaranteed to be at least 127. It is better to write a statement instead of a comment, because assert will also be checked by the JVM when the corresponding command line option ( -esa ) is -esa .

Usually this statement will never be thrown because IntegerCache.high initialized as follows:

 int h = 127; String integerCacheHighPropValue = sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high"); if (integerCacheHighPropValue != null) { try { int i = parseInt(integerCacheHighPropValue); i = Math.max(i, 127); // Maximum array size is Integer.MAX_VALUE h = Math.min(i, Integer.MAX_VALUE - (-low) -1); } catch( NumberFormatException nfe) { // If the property cannot be parsed into an int, ignore it. } } high = h; 

This code ensures that the value is at least 127. Thus, a statement can be IntegerCache.high if you modify IntegerCache.high (using reflection and setAccessible(true) ) or if the JDK is changed in the future and the error is introduced into IntegerCache.high code initialization. That's why there are claims: catching bugs.

Answer 2

JLS requires that the integer cache be in place for integers from -128 to 127.

Currently, Oracle's implementation provides this, but nothing more, so the cache ceiling may be expanded at some point in the future (unlikely in practice, but it will be fully in the specification).

However, it can never be less than 127, otherwise the implementation will no longer comply with JLS - and this will be a pretty big deal, therefore (I believe) why the assert statement exists!

As the bi-cyclope noted in the comments, it can also be modified by the user by passing the VM argument, another (and perhaps more convincing) reason that confirms the statement.

Also note that the assert statement will be skipped if it does not work with -ea , so there is no overhead for this check under normal use.

Answer 3

The cache, usually for -128 ... 127, may be increased, which may be the reason: it should not decrease. And since the code will work even without a cache, the statement may be soft: talk about a performance defect during development. Because statements do not affect production code.

Answer 4

Looking at

http://www.docjar.com/html/api/java/lang/Integer.java.html

I see this comment

  /* * WARNING: This method may be invoked early during VM initialization * before IntegerCache is initialized. Care must be taken to not use * the valueOf method. */ 

If they used valueOf in parseInt , then when parseInt is called at the start of VM initialization, the high value will actually be zero.

I'm not sure what problems might arise, but apparently someone thought it was worth it to protect.

• what is the use of assert IntegerCache.high> = 127; I read that assert provides an efficient way to detect and fix programming errors. But this is runtime code, why would someone use assert?

Protection against code called during VM initialization calling the valueOf method.

2. And when will an AssertionError be thrown in this scenario?

If you run java with the -ea parameter (allow statements), and there is some initialization code that calls valueOf, the JVM will crash almost immediately due to AssertionError. Hopefully the Java team will check this stuff and fix the violation code before releasing it into the wild.

Unlike other statements of the answer that the high will always be greater than or equal to 128, it seems that there are times when it is equal to zero (not counting the reflection).