New Features of Java 7: Simplified varargs method invocation
Java 7 new feature Simplified varargs method invocation This is one of the simplest changes of all-it moves a warning about type information
For a very specific case where varargs combines with generics in a method signature.
Put another way, unless you're in the habit of writing code that takes as arguments
A variable number of references of type T and does something to make a collection
Out of them, you can move on to the next section. On the other hand, if this bit
Code looks like something you might write, you shoshould read on:
public static
Collection
doSomething(T... entries) {...}
Still here? Good. So what's this all about?
As you probably know, a varargs method is one that takes a variable number
Parameters (all of the same type) at the end of the argument list. What you may not
Know is how varargs is implemented; basically, all of the variable parameters at the end
Are put into an array (which the compiler automatically creates for you) and they're
Passed as a single parameter.
This is all well and good, but here we run into one of the admitted weaknesses
Java's generics-you aren't normally allowed to create an array of a known generic
Type. For example, this won't compile:
HashMap [] ArrayHm = new HashMap <> [2];
You can't make arrays of a specified generic type. Instead, you have to do this:
HashMap [] WarnHm = new HashMap [2];
This gives a warning that has to be ignored. Notice that you can define the type
WarnHm to be an array of HashMap -You just can't create any instances
Of that type, and instead have to hold your nose (or at least, suppress the warning) and
Force an instance of the raw type (which is array of HashMap) into warnHm.
These two features-varargs methods working on compiler-generated arrays, and
Arrays of known generic types not being an instantiable type-come together to cause
A slight headache. Consider this bit of code:
HashMap Hm1 = new HashMap <> ();
HashMap Hm2 = new HashMap <> ();
Collection > Coll = doSomething (hm1, hm2 ); The compiler will attempt to create an array to contain hm1 and hm2, but the type
The array shoshould strictly be one of the forbidden array types. Faced with this dilemma,
The compiler cheats and breaks its own rule about the forbidden array of generic type.
It creates the array instance, but grumbles about it, producing a compiler warning
That mutters darkly about "unchecked or unsafe operations ."
From the point of view of the type system, this is fair enough. but the poor developer just wanted to use what seemed like a perfectly sensible API, and there are scarysounding warnings for no adequately explained reason.
Where did the warning go in java 7?
The new feature in Java 7 changes the emphasis of the warning. After all, there is
Potential for violating type safety in these types of constructions, and
SomebodyHad better be informed about them. There's not much that the users of these types of APIs
Can really do, though. Either the code inside doSomething () is edevil and violates type
Safety, or it doesn't. In any case, it's out of the API user's hands.
The person who shoshould really be warned about this issue is the person who wrote
DoSomething ()-the API producer, rather than the consumer. So that's where
Warning goes-it's moved from where the API is used to where the API was defined.
The warning once was triggered when code that used the API was compiled.
Instead, it's now triggered when an API that has the potential to trigger this kind
Type safety violation is written. The compiler warns the coder implementing the API,
And it's up to that developer to pay proper attention to the type system.
To make things easier for API developers, Java 7 also provides a new annotation
Type, java. lang. SafeVarargs. This can be applied to an API method (or constructor)
That wowould otherwise produce a warning of the type discussed. By annotating
Method with @ SafeVarargs, the developer essential asserts that the method doesn' t
Perform any unsafe operations. In this case, the compiler will suppress the warning.
CHANGES TO THE TYPE SYSTEM
That's an awful lot of words to describe a very small change-moving a warning from
One place to another is hardly a game-changing language feature, but it does serve
Revoke strate one very important point. Earlier in this chapter we mentioned that Project
Coin encouraged contributors to mostly stay away from the type system when proposing changes. this example shows how much care is needed when figuring out how different features of the type system interact, and how that interaction will alter when
Change to the language is implemented. This isn't even a particle ly complex
Change-larger changes wocould be far, far more involved, with potentially dozens
Subtle ramifications.
This final example extends strates how intricate the effect of small changes can be.
Although they represent mostly small syntactic changes, they can have a positive impact
On your code that is out of proportion with the size of the changes. Once you 've started
Using them, you'll likely find that they offer real benefit to your programs.
Reading Notes: The Well-Grounded Java Develope
