Java7 new features simplified varargs method invocation
This was 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, unless you ' re in the habit of writing code, takes as arguments
A variable number of references of type T and does something to make a collection
Out of them, you can move over to the next section. On the other hand, if this bit of
Code looks like something your might write, you should read on:
public static <T> collection<t> dosomething (T ... entries) {...}
Still here? Good. So, what's this?
As you probably know, a varargs method was one that takes a variable number of
Parameters (all of the same type) at the end of the argument list. What is not
Know is what varargs is implemented; Basically, all of the variable parameters at the end
is put into a 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 of
Java ' s generics-you aren ' t normally allowed to create an array of a known generic
Type. For example, this won ' t compile:
Hashmap<string, string>[] arrayhm = new hashmap<>[2];
You can ' t make arrays of a specified generic type. Instead.
Hashmap<string, string>[] warnhm = new hashmap[2];
This gives a warning that have to is ignored. Notice that you can define the type of
WARNHM to is an array of hashmap<string, string>-you just can ' t create any instances
Of that type, and instead has to hold your nose (or at least, suppress the warning) and
Force an instance of the raw type (which are array of HashMap) into WARNHM.
These Features-varargs methods working on compiler-generated arrays, and
Arrays of known generic types not being a instantiable type-come together to cause
A slight headache. Consider this bit of code:
hashmap<string, string> hm1 = new hashmap<> ();
hashmap<string, string> hm2 = new hashmap<> ();
collection
The compiler would attempt to create a array to contain HM1 and HM2, but the type of
The array should strictly be one of the forbidden array types. Faced with this dilemma,
The compiler cheats and breaks its own rule is about the forbidden array of generic type.
It creates the array instance, but grumbles about it, producing a compiler warning
That's 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 is 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 a
Potential for violating type safety in these types of constructions, and
SomebodyHad better is 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 evil and violates type
Safety, or it doesn ' t. In any case, it's out of the API user ' s hands.
The person who should really was warned about this issue was the person who wrote
DoSomething ()-the API producer, rather than the consumer. So that's where the
Warning Goes-it ' s moved from where the APIs are used to where the API was defined.
The warning once was triggered when code this used the API was compiled.
Instead, it's now triggered if an APIs that have the potential to trigger this kind of
Type safety violation is written. The compiler warns the coder implementing the API,
And it's up to that developer-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 is applied to an API method (or constructor)
That would otherwise produce a warning of the type discussed. by annotating the
Method with @SafeVarargs, the developer essentially asserts that the method doesn ' t
Perform any unsafe operations. The compiler would suppress the warning.
Changes to the TYPE SYSTEM
That's a awful lot of words to describe a very small change-moving a warning from
One place to another are hardly a game-changing language feature, but it does serve to
Illustrate 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 what much care was needed when figuring out what different features of the type system interact, and how T Hat interaction would alter when a
Change to the language is implemented. This isn ' t even a particularly complex
Change-larger changes would is far, far more involved, with potentially dozens of
Subtle ramifications.
This final example illustrates how intricate the effect of small changes can.
Although they represent mostly small syntactic changes, they can have a positive impact
On your code, 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
Java7 new features simplified varargs method invocation
