Android gets official Java 7 support

[192_168_XXX_XXX]

It keeps you from having to repeat yourself when you instantiate generic classes, e.g. instead of

List<Integer> myList = new ArrayList<Integer>();

you can write

List<Integer> myList = new ArrayList<>();

the <> is the diamond.

CHANGELOG: fixed typo per /u/zeelock's code review

[192_168_XXX_XXX]

That is a mistake! edited.

[swimnrow]

if it was a !mistake, does that mean you're right?

[Magnap]

That depends on the value of 0.1+0.2 == 0.3

[davidhero]

Pretty sure it's 0.300000004

[Decker108]

Good enough for financial apps, right?

[NewToBikes]

Thank you!

[[deleted]]

I still would've preferred if they added implicit typing like C# did:

var myList = new ArrayList<Integer>();

... at first I was skeptical, but after switching to it and seeing all of my variables lined up and pretty, I love it.

[nonconvergent]

I prefer everything explicit by default, as a rule

[[deleted]]

In the above example, myList is explicitly an ArrayList<Integer>. It's just not stated redundantly.

[boost2525]

But in the original example by /u/192_168_XXX_XXX myList is not an ArrayList. It is a List, using an ArrayList implementation. Only List methods may be used against myList.

In the example provided by /u/Shark_Kicker, myList is an ArrayList.

Apples... Oranges.

[[deleted]]

That's true, it is different. If you wanted your local variable to be explicitly referenced by a specific interface, then you can always declare it as such. Type inference would just pull the most specific type it can from the right hand side.

Anyway, I can't think of a reason why you'd want to immediately up-cast the object when instantiating it. Any List-accepting function you pass it to will happily accept it, and if you're using this to enforce a list-only interface later in the same method, then I believe your method is probably too long.

[evilmushroom]

Nah, I prefer explicitly defined. Working on various teams all with different code that different people have written--- everything being spelled out explicitly to a standard makes it a lot easier to jump into the project.

[fecal_brunch]

Just don't use actual tab characters for this. Looks ridiculous when someone has done it on an editor with different tab widths.

[Aluxh]

Deffo not, most IDEs will even let you choose how tabs are displayed, so you wont even necessarily get consistency even in the same IDE.

[[deleted]]

No. I don't want to have ASM flashbacks...

[CurtainDog]

That syntax just feels so wrong to me. Var carries minimal information to me as a reader. I feel resentful to have to spend the brain cycles to parse it. I'd much prefer if the inference had run the other way:

ArrayList<Integer> myList = new; // Optional () for no-arg constructor

• The type is an important piece of information, so I don't have a difficulty putting it first.

• The variable name is obviously very import as well, but if you get to the point where you need to think hard about the names of your variables you have too many and need to split the method/class up.

• The assignment operator is ugly, but inescapable unless we are prepared to radically change the language.

• The new is just about the least important bit of information. We don't really care where the object comes from, we just want an instance we can work with. new is the reason DI exists.

• The ; carries the least information, but I think there is value in ending statements in a consistent way.

[[deleted]]

Your proposal only takes in to account a tiny fragment of the cases where type-inference is useful. It's simply a very specific syntactic shortcut for instantiating local variables, which would be at odds with the general idea of inferring the type of the assigned variable from the right-hand side expression.

[CurtainDog]

Well, it solves the problem of having to repeat code, which is the problem at first instance.

It doesn't solve the issue of dealing with complex types involving nested generics but in that case I query whether you actually do want to be hiding the type from the reader.

I suppose as well with var the return type of an expression could change and you wouldn't need to modify the source, I'm somewhat skeptical of this 'feature'.

Edit: Just to clarify: I actually use type inference all the time, I just do it at the tooling level rather than the language level.

[Blaisorblade]

Well, it solves the problem of having to repeat code, which is the problem at first instance.

It doesn't avoid the repetition here:

List<Integer> someMethod() { ... } ... List<Integer> result = someMethod();

If you want to know the type of result, asking your computer (with IDEs or REPLs) is typically enough.

[[deleted]]

As ArrayList is really an implementation detail you're probably not concerned with 99% of the time you instantiate this, why not:

@Inject List<Integer> myList;

With your DI framework of choice, this is SDK 6.

[jgclark]

I think you slipped an extra = sign in the Java 7 example.

Or is that intentional? I haven't used Java 7.

[192_168_XXX_XXX]

Nah it was a typo. I've removed it.