About Question enthuware.ocpjp.v8.2.1860 :

[mrmuiz]

I do not agree with this answer: IntFunction does not "avoid additional cost associated with auto-boxing/unboxing" by virtue of its own nature. It's developer's responsability making a good use of Function or IntFunction, both of them can cause auto-boxing/unboxing if misused

Code: Select all

		// bad use
		
		new IntFunction<String>(){
			@Override
			public String apply(int value) {
				return Integer.toString(value);
			}
		}.apply(new Integer(1));
		
		new Function<Integer,String>(){
			@Override
			public String apply(Integer value) {
				return value.toString();
			}
		}.apply(1);

or avoid it if properly used

Code: Select all

		// good use
		
		new IntFunction<String>(){
			@Override
			public String apply(int value) {
				return Integer.toString(value);
			}
		}.apply(1);
		
		new Function<Integer,String>(){
			@Override
			public String apply(Integer value) {
				return value.toString();
			}
		}.apply(new Integer(1));

I'd simply say that IntFunction accepts primitive integers.

[admin]

Yes, it is possible to write bad code while using IntFunction as well, but the whole reason it exists is to avoid boxing/unboxing cost when dealing with primitives. Otherwise, Function was enough.

The option has been updated to "It avoids additional cost associated with auto-boxing/unboxing while dealing with primitive ints."

I hope that makes it more clear.

thank you for your feedback!
Paul.