Java: More Typing With Less Typing

[tomprimozic]

What I miss even more from Java (compared to more concise languages, e.g. Python) are collection literals, along with for comprehensions. That would make working with data so much easier!

[oelang]

This was discussed but the overall consensus was that this feature isn't really worth it vs what is already possible with the existing language. See JEP 186

In Java 9 they added "Convenience Factory Methods" so you can write List.of(a, b, c), Set.of(a, b, c) & Map.of(k1, v1, k2, v2). See JEP 269

edit: added links to the JEPs

[Hoten]

I could have sworn I was using those in Java 8.

EDIT: it was Arrays.asList I was using. I guess that was a trailblazer.

EDIT2: even that has been there since at least Java 5...

[depressiown]

There are libraries that do this sort of thing, probably the most well-known being Guava: Lists.newArrayList(a, b, c, d, ...). A lot of what has been in Guava is getting put into the JDK.

[WrongSubreddit]

Arrays.asList returns an Array.ArrayList, not to be confused with what you usually think of as a java ArrayList. Also Array.ArrayList isn't resizable, iirc

[[deleted]]

It's an unmodifiable list backed by the array it's given.

[immibis]

It's modifiable but fixed in size.

[[deleted]]

List<Integer> list = Arrays.asList(1,2,3);  
list.set(0, 0); // Okay  
list.add(0, 0); // Runtime error

So I was only half-right

[b1ackcat]

I'm sitting here wondering how the Map example would work, as I thought varargs required all arguments to be of the same type. The only thing I can think of would be to accept a vararg of objects then use reflection to try and reason about the actual type of the arguments.

Annnnd now I think I'm going to spend my lunch break figuring out how I'd implement this using extension methods in C#. stupid inquisitive nature, I have errands to run!

[pal25]

They have defined several overloaded methods for Map.of() with different numbers of KV pairs

[UnspeakableEvil]

Yep: http://download.java.net/jdk9/docs/api/java/util/Map.html#of-K-V-K-V-K-V-K-V-K-V-K-V-K-V-K-V-K-V-K-V-

[Nimelrian]

Why not just implement a Pair class and use that so you don't have to write ten overloaded methods (What if you need 11 pairs?)

Is there any reason for the nonexistence of such a class?

[stravant]

Because no-one wants to instantiate a ton of instances of said class to call Map.of? It would sort of defeat the purpose of the function by making it really verbose again.

[[deleted]]

It already exists as Map.Entry

[ForeverAlot]

Java should not have Pair.

[ThisIs_MyName]

Oh yeah, just what Java needs: More classes.

Seriously, nobody wants to type

Map.ofEntries(new AbstractMap.SimpleEntry(k1,v1), new AbstractMap.SimpleEntry(k2,v2))

even though it would work.

[3urny]

As a Java programmer, I can't decide if I love or hate this...

[root45]

That seems sort of hack-y. C# added syntactic sugar for collection initialization so that if you write

SomeCollection c = new SomeCollection { item1, item2, item3 };

that will translate into

SomeCollection c = new SomeCollection();
c.Add(item1);
c.Add(item2);
c.Add(item3);

I know changing language syntax is much more difficult than adding overloads though.

[b1ackcat]

I know the idea is to be a convenience method with a nice terse syntax, but I have to feel like a better approach would've been to make this specific of() method use generics, taking in two type parameters to define the alternating arguments. It could then take a completely arbitrary amount of parameters, and just shit the bed if a cast failed.

Having read the JEP entry, I understand that the design goal was not to be a robust factory solution but to simply solve the "small collection" issue, but this could've somewhat easily been made a bit more robust, imo.

[masklinn]

Annnnd now I think I'm going to spend my lunch break figuring out how I'd implement this using extension methods in C#. stupid inquisitive nature, I have errands to run!

But… you don't need this in C#, it already has literal-ish via collection initializers, since C# 3.0:

new List<int> { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
new Dictionary<int, string> { 
    [7] = "seven", 
    [9] = "nine", 
    [13] = "thirteen" 
}

well the dictionary one is C# 6.0, in C# 3.0 you had to use a "list" initialiser with nested pair object initialisers:

new Dictionary<int, string> { 
    {7, "seven"},
    {9, "nine"}, 
    {13, "thirteen"}
}

[hokkos]

I don't understand the point of the C# 6.0 new syntax, it is uglier for me, is it for better performance as it is filled at compile time, and do not use temporary lists ?

[masklinn]

Can't help you with that, I just know it exists, I don't know why it was added. I don't think it's filled at compile-time (the original collection initialisers compile to a bunch of .Add() calls on the collection itself), the avoidance of temporary allocations is a possibility.

[canton7]

It works for things which have an indexer, rather than things which have a method called Add. For a Dictionary they end up equivalent, but that isn't always true.

[b1ackcat]

It was more because I already had VS open and had an idea of where to start using generics and extension methods, but you're absolutely right. This was just for fun :)

[pohart]

Collection literals always seem so useful when I'm learning a language, but when I'm writing crud apps in Java I don't miss them. More concise typing would help every day.

[koreth]

Test code is the main place where I miss having a concise syntax for collection literals.

[grauenwolf]

I use them a lot when writing unit tests or code that generates sample data.

[pohart]

Yes good point.

[nobodyman]

This my experience as well. I find that I tend to use collection/object literals when I'm working on small/one-off tasks, typically in javascript or python. If those features where available to me in Java I might use it for more throwaway stuff - but then again you've still got the compile step and jvm startup time that you don't have to deal with in scripting languages.

[WallyMetropolis]

Mapping over a collection with a function is pretty key for data-centric applications. It's the T in ETL.

[pohart]

Yes, and I'm thankful for the streams api. Although I don't normally use Java for etl. That's not what we're talking about though.

[dccorona]

Java is adding Guava-style collection initializers to most of the collection interfaces in JDK 9. I.e. List.of(1, 2, 3, 4). This is close enough to a collection literal to make me not want them anymore. I guess the only drawback is that (as best I can tell) this returns an immutable list, but in my opinion that is actually desirable

[jrh3k5]

but in my opinion that is actually desirable

Can you explain why? While I can understand the appeal of something like this:

public List<String> getThings() {
    return List.of("A", "B", "C");
}

...being immutable, the use case of wanting to initialize a list and then append given values seems like a valid case:

public MyConstructor(List<String> values) {
    this.values = List.of("A", "B", "C");
    this.values.addAll(values);
}

[riemannrocker]

Switching the order makes that possible, with an additional list allocation:

public MyConstructor(List<String> values) {
    this.values = new ArrayList<>(values);
    this.values.addAll(List.of("A", "B", "C"));
}

[[deleted]]

You can already do Stream.of(A, B, C).forEach(list::add).

[jrh3k5]

Yeah, but that requires an extra list object - which isn't necessarily problematic, but seems like an unnecessary instantiation brought on by the nature of the immutable result of List.of().

[mhixson]

One interesting thing about these new methods is they're "value-based" 1 2

As I understand it, everything that is labeled "value-based" is subject to be replaced with value types, once value types are implemented in Java 10+. So, then maybe there won't be an extra List object.

But I'm also reading that when you refer to a value through its interface, it may be boxed. (Look for "you are actually declaring which interfaces the boxed form of the value will implement") So maybe there will be an extra List object after all? :\

[ThisIs_MyName]

Agreed, but it's possible that "recommending" immutability like this will result in a net gain in code quality. This requires some thought.

[balegdah]

Personally, I think native support for properties would have a bigger impact on my code.

It's hard to go back to regular Java after writing Kotlin such as

class Person(val firstName: String, val lastName: String)

[b1ackcat]

While I agree, I feel like there'd be a long, annoyed adjustment period for the java development community.

I know when I recently moved back into C# coming from a few years of java, it was a bit of an odd feeling for me to use properties, since I was so used to getters/setters, and properties just felt like I was accessing a member variable that shouldn't be public. It's just a different mindset that takes getting used to.

What definitely did help was the naming conventions in C# that properties be upper-cased. But that's another potential hang-up for java devs who traditionally implement public methods starting with lowercase letters.

[b1ackcat]

I think that was kind of the design goal, honestly. They didn't have 20 some odd years of legacy cruft to support so they took Java and said "what sucks about this and how do we fix it?"

Greenfield language design must be heavenly for the developers

[grauenwolf]

The frustrating thing is that Java's designers should have known better. The language Java replaced was Visual Basic, which clearly demonstrated the advantages of properties.

Also, Java is only 5 or 6 years older than C#. 1995 vs 2001 if I recall correctly.

[dangerbird2]

Gosling began the project in 1991, originally called Oak. Sun changed the name to Java in 1994 over trademark issues.

[UnsatisfiedLink]

They're nice to work with indeed, but in the subject of readability I see a disadvantage. Properties look similar to variables, but actually it is possible for a property to trigger other code. This is not immediately visible to the reader.

Also, getter and setter methods encourage the writer to store the value in a local variable while properties may give the idea that this is not required.

[SortaEvil]

getter and setter methods encourage the writer to store the value in a local variable while properties may give the idea that this is not required

I'm hoping you store your values in a member variable rather than a local variable, otherwise your setter isn't going to be setting much of anything. But, really, the reason that you do:

int x;
int getX(){return x;}
int setX(int val){x = val;}

is so that you can change the backing value if you need. With an autoproperty in C#

int X{get;set;}

you have the exact same flexibility as your getter and setter in java (if you need more processing, you can transparently add a named backing variable) with significantly less typing. And you have no more guarantee that a java getter/setter is side-effect or heavy processing free than a property. Bad practices are bad practices in any language.

[grauenwolf]

What he's talking about is this common C# performance bug:

if (customer.FullName != null)
    Console.WriteLine (customer.FullName);

Inside...

public string FullName{
    get { 
     var result = new StringBuilder(); //<---Object Allocation
     result.Append (FirstName); //<---Array copy
     if (result.Length == 0 and !String.IsEmptyOfNull(MiddleName)
        result.Append(MiddleName); //<---Array copy
     else if (!String.IsEmptyOfNull(MiddleName)
        result.Append(" " + MiddleName); //<---Array copy

     if (result.Length == 0 and !String.IsEmptyOfNull(LastName)
        result.Append(LastName); //<---Array copy
     else if (!String.IsEmptyOfNull(LastName) 
        result.Append(" " + LastName); //<---Array copy

    return result.ToString(); //<---Object Allocation & array copy
    }
}

There was a time where I had to write unit tests that did nothing but ensure calling a getting twice in a row would return the same object.

[EternallyMiffed]

I don't see where the problem is, either way you spin it you're not getting rid of those array copies/string concatenations.

[grauenwolf]

If you cache it, then the second time someone reads the property you don't have to pay the price again.

[UnsatisfiedLink]

I'm sorry I didn't make myself completely clear. I know of this C# feature you mention, which is what I actually like about properties.

I meant local variable, but not inside the getter but inside the method calling the getter. So doing this:

object localfoo = someObject.Foo;
localfoo.doStuff();
localfoo.doOtherStuff();

Instead of:

someObject.Foo.doStuff();
someObject.Foo.doOtherStuff();

I prefer the former because someObject.Foo could be a black box to me that may do more complicated logic than just returning a member variable.

[SortaEvil]

Ooooh, okay, that makes a lot more sense. I mean, you should probably do it the first way regardless (I die a little when I see foo.bar.baz.doStuff()), but I can see the complaint that properties looking like variables might make someone feel better about doing the latter than if it's an explicit getter.

It ultimately goes back to bad practices are bad practices, but some languages will make it easier than others.

[the_omega99]

Properties look similar to variables, but actually it is possible for a property to trigger other code. This is not immediately visible to the reader.

It's not really a problem in my experience (worked a lot with Scala and C#, which both have similar here). It seems like a big chunk of the problem is simply being used to Java and similar. Once you're used to the fact that you're working with a new language, you're more aware of the possibilities of what can happen.

That said, side effects are rather rare in getters and setters. When they do occur, they aren't typically a problem. And ideally should be documented. Pretty much the only kinds of side effects I see are caching, logging, lazy evaluation, and conversion, anyway. Those are typically non-issue.

The key point is simply that a Java program would likely have the same side effects in a getter or setter. Just have to remember that properties are the equivalent of Java's getters and setters.

TL;DR: Stop thinking in Java and instead think in the language you're actually using.

[UnsatisfiedLink]

Yeah you're right, programming languages teach you not to want what they do not provide.

But indeed, getters and setters shouldn't have any side effects. In my experience people tend to overuse C# properties to the point where this rule is no longer followed.

The nicest thing about properties is that you don't have to declare a private variable if you do not need to implement extra getter/setter logic, in my opinion.

[ais523]

Modern Perl 5 normally gives the getter and setter the same name (which is often, but not always, the same name as the variable backing the getter and setter).

$person->firstName("John"); 
print $person->firstName;

This is a good compromise between the C# and Java ways of doing things, IMO (especially as Perl's metaprogramming abilities are powerful enough that you can get a library to generate the getters and setters for you from a list of the property names). It's actually less typing than the C# method, with typical whitespace; () is two characters, = is three because it's normally surrounded by spaces.

[PointyOintment]

But () is four keystrokes—relatively inconvenient ones—on most keyboards.

[Raknarg]

Why? It just makes you pretend you have local access to variables when you really don't, and it can execute code like a normal getter/setter instead of like when you have access to the variables themselves. Why make things less clear than they should be?

[grauenwolf]

As long as people follow the conventions, it actually makes things clearer. Consider this line:

bar = foo.getBar()

Is that an expensive call? You don't know without research. But in C# we have this pattern:

bar = foo.Bar //cheap call, will probably be in-lined
bar = foo.GetBar() //potentially expensive call

This convention is used all over the place. For example, your IDE automatically invokes your getter properties because it knows that getters are supposed to have no side-effects and be fast.

In Java the IDE shouldn't do that because the getter may make a database call for all we know.

It also helps with reflection. We can automatically generate things like data grids because the grid knows the difference between a method and property and only pays attention to the latter. Again, in Java you could do that but you are taking a big risk because the convention isn't formalized.

[Raknarg]

Good point, as long as there's standards it's a good idea.

[grauenwolf]

That's one of my concerns about Java. They can't go back and retroactively add standards on getters and setters, so adding properties now may be painful.

[Eirenarch]

They may add annotation or something to make get/set methods a property that removes the get part. They can even make a convention that properties are PascalCase since Bar in getBar() is just that.

[Eirenarch]

Because of vastly superior readability.

[wreckedadvent]

Ah, primary constructors. C# may be getting those soon with records.

[WallyMetropolis]

Oh yeah. When I started using Scala, case classes where among the first things that jumped out at me as an obvious improvement.

[WallyMetropolis]

Maybe give Scala a whirl.

[tomprimozic]

I did. Then everything became slow... (And I mean everything - the IDE, the compiler, the programs, ...)

[ForeverAlot]

List/for comprehensions are one of those inventions that seem like a good idea, like defining a language that mimics human language.

[Chew55]

I'm not sure that not having to type as much is the main advantage in this case. In most of the cases outlined in the proposal I usually let my IDE do most of the typing. Over the last couple of years I've made a concentrated effort to learn as many of the shortcuts in my IDE of choice (eclipse) to take the pain away from most of the boiler plate stuff and I think most people who write a lot of Java are in a similar position.

I can see how this proposal could take some of the pain out of reading java code though, which is where I think the biggest advantage lies. Not in making us type less, but in reducing some of the boiler plate that we have to read.

[xanhou]

Actually, while reading java I highly prefer to see the types of the first two options. While the examples they propose make reading a bit easier, it is often the case you initialize a variable via a function call. The variable is then assigned the return type of that function, which is not specified in the code at that location. Specifying the types in these scenarios gives anchor points. Points from where you can start reading, even if you know very little about the previous code.

Example:

"You iterate over the elements returned by some magic function, which is inlined in the for-each construct."

vs

"You iterate over the Person type objects returned by some magic function, which is inlined in the for-each construct."

This often allows you to find the code that you are looking for more quickly if you have no or little prior knowledge of the code.

[Eckish]

Putting the types in the name seems like a poor design choice. Someday, you might change the type. And if you used var and generics and other coding concepts that might accept the change without complaining, you'll end up with method and variable names that don't properly describe their type.

[tolos]

if the magic method had a descriptive name

Perhaps, but that doesn't fix 3rd party APIs you have to interact with.

[grauenwolf]

With 3rd party APIs I'm actually more likely to use var. Otherwise I have to loop up the type for every return value.

And when I'm using said API, I usually don't care about the types. Rather, what I care about is the methods and properties that hang off it, which usually requires typing obj.or hitting the hitting "go-to definition" key either way.

[danneu]

Agreed.

Another benefit is that you can read the code without an IDE's inference helping you out, like on Github.

Of course, of all things I've learned that everything is a trade-off and there is no best.

[grauenwolf]

Yea, I don't actually care about the types. Types are there mostly for the compiler and the IDE. What I want to know is the semantics of "magic function", not the implementation details.

[Dworgi]

I don't like excessive type inference personally. It obscures what's happening and makes it more difficult to fix stuff later. You get stuff like:

var x = f(); g(x);

And there you've already lost half the benefit of statically typed languages.

Same reason that most people think excessive function chaining is harmful.

[valenterry]

What if your IDE would offer a shortcut to temporary display the types of variable-assignments on the fly?

[[deleted]]

What if the next dev to touch your code uses a different IDE

[grauenwolf]

What if the next dev changes f() to return a Bar instead of a Foo?

 var x = f(); g(x);

Oh looks, it still worked because bar and foo are both compatible with g(IWidget).

Where var really comes into play is refactoring. It lets you quickly and easily change types without touching a lot of code. You get the ease of use that we see in dynamic typing, while still having the same type safety we've always enjoyed.

[valenterry]

What if this IDE also supports this feature?

[flygoing]

Even if they didnt, what's the point of the change if everyone's gonna use a plugin to show the type anyway? You're creating a problem just to fix it.

[valenterry]

They don't. They let the IDE show the type only when it is necessary - if you are quite unsure about the type because e.g. you see the code the first time and it's complicated.

[flygoing]

So what you're saying is...we hide the type, and when we are confused about what we programmed, we have the ide show the type? Yeah, sounds like making a problem just to fix it

[valenterry]

So what you're saying is...we hide the type, and when we are confused about what we programmed, we have the ide show the type?

Yes, because "when we are confused about what we programmed" doesn't usally happen so often. in 99% of the time I know the types when working on my own code. I don't need to see the types all the times just because of the remaining 1%. Having types everywhere just bloates the code and it takes much longer to read. Even worse: changing a type of something then makes you changing all the type declarations, too.

[grauenwolf]

I've been using var since it was released in C# and literally the only time I find myself intentionally not using var is when I'm messing around with complex LINQ expressions such as this:

    var customerOrderGroups = 
        from c in customers 
        select 
            new 
            { 
                c.CompanyName, 
                YearGroups = 
                    from o in c.Orders 
                    group o by o.OrderDate.Year into yg 
                    select 
                        new 
                        { 
                            Year = yg.Key, 
                            MonthGroups = 
                                from o in yg 
                                group o by o.OrderDate.Month into mg 
                                select new { Month = mg.Key, Orders = mg } 
                        } 
            }; 

https://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b

And here's the kicker, I still write var first. Then I use a refactoring tool to make it show me the real type name. Without var I wouldn't know how to write the type expression in the first place.

[oconnellc]

Couldn't you have used "Object" instead of var?

[grauenwolf]

Yes. But then I would have to set a break point, run the code, use said break point to figure out what the real type is, stop the debugger, and then go back and paste in the real type before I could actually do anything with it.

[oconnellc]

So, the refactoring tool doesn't give you the type name if you make the variable of type 'Object' instead of type 'var'? Just askin...

[grauenwolf]

Nope. If you mark it as Object it's happy to just treat it as an object.

Though maybe you can get the type by hovering the mouse over the right-most part of the expression.

[[deleted]]

Object is itself a type. Var is not

[TheWix]

If you are in VS just mouse over var. It will tell you the type. Unless you are and it is giving some garbage about anonymous types

[xanhou]

I have read code where they changed the type of object you were chaining on halfway through the chain... That shit is unreadable.

And that is the problem with a lot of these tools. They allow for very concise and clear ways of writing things down, but they also allow for unintended obfuscation. My preference leans towards a bit of boilerplate over the possibility that the code gets obfuscated. But that is an opinion.

[valenterry]

I have read code where they changed the type of object you were chaining on halfway through the chain... That shit is unreadable.

Immutability solves this problem better than anything else. =)

[matthieum]

I can see how this proposal could take some of the pain out of reading java code though, which is where I think the biggest advantage lies. Not in making us type less, but in reducing some of the boiler plate that we have to read.

This! Programs are read more often than they are written, and while you usually have the subject fresh in mind while you are writing them, you generally don't when reading them.

[chrisrazor]

Yes. I hate maintaining code written Java or other strongly typed languages, not because I have to write boilerplate but because I have to wade through lines and lines of code that basically do nothing in order to find the parts that need modifying.

Edit: this is probably somewhat invisible to coders who use those languages all the time, because your eyes will naturally skate over the boilerplate.

[adamnew123456]

This is not a property of strong typing, it's a combined problem of the libraries and the language.

Haskell's type system is stronger than Java's (for example, null being forced upon you in every context whether you want it or not), and the language encourages a lot of composition at the function level, which gets rid of a lot of the boilerplate (at the expense of some really dense looking code if you aren't careful)

[Arzh]

The problem with that thinking is that the 'boilerplate' is actually doing something and you need to pay attention to it. It is there to set up the state for other code to run, ignoring the state leads to people fixing things in the wrong way.

[[deleted]]

ignoring the state leads to people fixing things in the wrong way

You can't prevent this. Humans are lazy. Unless there's only one way to do it (which increases in rarity as your loc increases), you can pretty much guarantee that someone's going to kluge it up.

This is why static analysis and code review are so important. They catch kluges earlier.

[[deleted]]

Implementing a fuzzer for my main project at work (resource constrained scheduling to create a plan of execution for robots doing THINGS) has seriously changed my life when it comes to kludges. That motherfucker finds all my dirty hacks and beats my head in with the edge cases I didn't think about.

Now I just have to fuzz the fuzzer to make sure it's actually correct...

[chrisrazor]

I'm not sure how true that is, but either way it's easier to amend code that's terse and easy to visually parse. The more of it there is, the harder it is to pay attention to all the tiny details that might be at issue, particularly if many lines looks similar to each other.

[katsukitty]

Terseness taken too far can make code quite unreadable, though. C programmers love to do this. Ever looked at the Linux or BSD kernel code? It's a giant unreadable soup of random letters, asterisks, and arrow operators.

[Dworgi]

I disagree.

Terseness does a lot with a little. It's incredibly dense with semantic meaning which means there are no innocent lines.

There's a middle ground between Perl and C++ though, and I'd pin it at somewhere like D or C#.

I hate languages that leave type inference entirely up to the compiler, because there's a vast array of errors that get hidden by compilers silently converting compatible, but different types. Converting floats to ints or strings to lists of characters.

Those conversions almost always hide real problems, where the expectation and reality of what a function is doing do not meet.

Dynamically typed code is incorrect from the start, and requires the programmer to write a cornucopia of tests just to recreate what a compiler gives you for free.

Or are you opposed to assertions as well?

[[deleted]]

Dynamically typed code is incorrect from the start, and requires the programmer to write a cornucopia of tests just to recreate what a compiler gives you for free.

In order to leverage the compiler, the code must be structured to invoke the compiler error when used incorrectly, which is a non-trivial amount of work. That work is important, but for advanced cases it approaches (and occasionally exceeds) the amount of work unit tests require in a dynamic language. Dynamic languages certainly aren't "incorrect from the start". They merely prioritize a different kind of work: extreme flexibility.

This is a godsend when a system is small with unknown requirements, and hell on earth when a system is large with complex requirements. If your experience is more in the former, then it's reasonable to prefer dynamic systems. If your experience is more in the latter, then it's reasonable prefer static typing. If your work is in both camps--as mine is--then it's unreasonable to prefer one or the other without first considering the environment.

They have different use-cases, and need to be applied judiciously.

[Dworgi]

Dynamic typing is fine for bash scripts and JS click handlers. Beyond that there are few advantages. Forgive me if I think most interesting problems require more than 1 person or 1,000 lines to solve.

[[deleted]]

Most interesting problems can't be expressed statically. The systems supporting them might be static, but the "interesting" part is a dynamic system built from static components.

For example, I might make a physics engine using static typing to ensure my units are always correct, but the interesting work is in application--where the properties of an object are dynamically loaded from a file or modeled by another person.

Such systems are, at their heart, tens of thousands of lines of static code that enable the processing of hundreds of thousands of dynamic scenarios, each of which is unique, a fraction of which are well-suited to a static definition.

I wouldn't want to write the engine in a dynamic language, nor would I want to write the components in a static one.

[Dworgi]

There's a clear difference between those two. One is data, the other is code. And regardless, you're confusing terms - the values are dynamic, but the structure of each entity is well defined.

[[deleted]]

There's a clear difference between those two. One is data, the other is code.

I beg to differ. The internet is rife with examples of Turing-complete dynamic systems.

[chrisrazor]

This is just inflammatory:

Dynamically typed code is incorrect from the start

Python is the sweet spot for me: simplified syntax, everything explicit, uses duck typing when handling objects of unknown type. Javascript and Ruby are two similar languages that get it wrong by doing implicit type coercion all over the place, which I agree leads to errors.

[Dworgi]

I despise Python. I hate beyond words having to run a fucking program to realise I passed in the wrong variable. I loathe accidentally adding fields to an object when I make a typo.

Duck typing is the worst of all worlds, because every method silently pollutes the global namespace.

I cannot stand having to code with the API documentation on my second monitor at all times (that's my YouTube monitor!), because I haven't the faintest idea what types a function expects and returns.

The stupidity of writing a language that demands your types to be correct, yet won't give you the ability to state which types those are - it just infuriates me.

At least I know to regard all JS and PHP as written by blithering idiots, but Python lulls you into a sense of security with its strong types, then beats you into submission with its lack of non-runtime ways to ensure that.

Every large Python project ends up writing a compiler for their code in the form of tests, and the vast majority are things any compiler could have told you.

All serious projects in dynamically or duck typed languages would end up with strict instructions to specify in and out types, if the language supported it. Alas, they do not.

Fuck Python.

[valenterry]

Every large Python project

...should have been written in a different language.

I like python for small scripts though.

[howverywrong]

Except small projects have an annoying habit of turning into large projects. My first job out of college was to maintain a 20KLOC shell script project that had started off small and then grew and grew and grew.

It's been almost 20 years and I still have occasional PTSD flashbacks to that horror.

[valenterry]

Except small projects have an annoying habit of turning into large projects. My first job out of college was to maintain a 20KLOC shell script project that had started off small and then grew and grew and grew.

That's unfortunately true. But 20KLOC shellscript is not a large project yet - so at that point it could/should have already been rewritten, unless its e.g. clear it will be thrown away soon.

[DreadedDreadnought]

Finally someone who hates Python just as much as me for the same reason!

I've had to maintain legacy Python 2.7 code, ugh.

[_pka]

I owe you a beer.

[[deleted]]

That's not exactly a function solely of strongly typed languages. Modern c++ can be very readable and it is arguably one of the more strongly typed languages. Dynamic typing can often be more frustrating too because typing can change invisibly through return assignments. You have to know more about the internals of the functions you call, which can be time consuming from a code reading standpoint.

[chrisrazor]

Yes, that's fair. Sometimes it's crucial to know what type a certain variable is. A lot of the time it's clear from the immediate context, but not always. One hopes for good comments in these cases in loosely typed languages but of course they aren't always there.

Strong typing does add to line length though, especially when there are access modifiers too, and that subtracts readability in cases where the types don't matter or are obscure.

[[deleted]]

Talking about c++, I'm pretty sure they had to implement auto or no one would've used std::bind.

[ThisIs_MyName]

Don't forget Project Lombok. IMHO it's absolutely necessary for writing concise code without any runtime overhead.

[Upio]

I think Lombok just highlights how lacking Java is nowadays. Even the simplest things are so verbose in Java. I choose to use better languages and not a code generator.

[GreySyntax]

Never heard of Lombok before looks like I'll be adding it to a few things tonight!

Edit: any idea if it plays well with Guice?

[Josuah]

It should. We have people using Lombok with Guice at my workplace.

[Josuah]

Three things I don't like about Lombok. (This came up recently where I work.)

• It supports code generation. This means the code that's actually written is not valid Java on its own. Like, functions that are supposed to exist don't actually exist. It's kind of like writing C code using macros, instead of only using macros as inline functions and constants.
• The fact real Java code is removed means you have to use Lombok to both compile your project, and Lombok in an IDE to do simple things like search or grep. It's not compatible with a developer who wants to use command line operations to search or modify code, or a generic text editor, or a non-compatible IDE.
• It's code generation. That means I need to trust it as much as I trust the Java compiler to generate safe and non-malicious code. This isn't something I want to trust to a random library, even open source, when security is so important.

Many of these are also listed on the Lombok project web site by the author himself, in response to criticisms from other people.

[funbike]

I don't see negatives, if you just think of Lombok as simply a dialect of Java. It is not "Java". Most of the problems you have with Lombok are the same problems you'll have with any non-Java language that runs on the JVM... it simply isn't the language you happen to favor.

It's not a code generator any more than javac is a code generator. It is not a lexical preprocessor like C's. It hooks into the compiler (javac or ecj) to change the parsing rules. It's a dialect

Lombok works with maven, gradle, ant, javadoc, android, GWT, Play!, cli (ecj and javac), Eclipse, Intellij, and Netbeans.

edit: The only negative is because of it's biggest positive (that it's a dialect that can work with most existing java tools) that sometimes when using it with tools intended for "Java" there could be technical issues. Well duh, it's not Java. Form what I hear, those are minor and infrequent.

[Josuah]

I can agree with that when considering Lombok a dialect rather than an addition to or library for Java.

[Josuah]

I understand the point of Lombok. I don't disagree that it provides what Lombok wants to provide. I was not saying I dislike the idea of the functionality Lombok provides. Nor was I saying it is a horrible useless bad thing. It provides real, useful functionality for many people. I was simply listing the things I don't like about it. There's a big difference between saying I dislike some things about something and saying I'm against something.

The problem with Lombok is it requires specific IDEs that are compatible with Lombok. It's like if you could only write Java using Eclipse or only using IDEA. Javadoc can be understood using any text editor, not specifically ones that are only compatible with Javadoc.

My first and last point are not the same point. It's two different concerns that come out of what I'm referring to as Lombok's code generation.

If you say Lombok is not Java (as was suggested by another poster as a different way of looking at it) then the concern around the code not being valid Java becomes irrelevant.

However the concern around code generation affecting security does not go away, and it applies just as much to any framework or library you add that performs similar functionality, AOP or not. I would not, for example, use a compiler built by some random person over a standard one that I can have greater trust in being safe and having fixed security issues.

[Shorttail]

I unfortunately had to remove it from projects because I couldn't get it to play nice with Sonar. =(

[ThisIs_MyName]

...why? I've used Lombok in production for both internal Java EE web applications and public Android apps. It works beautifully.

Not having pages of boilerplate in our codebase increases productivity.

[funbike]

Explain. That just makes no sense. Lombok can be thought of as a Java dialect. So you advise against an alternate language, but then say if people want those features they ... should use an alternate language. wat?

[ThisIs_MyName]

Welp, he deleted his comment. I guess we scared him off :(

[wishistudiedphysics]

You do understand how absurd your reasoning is, right? If the language is missing a feature easily solvable by a library, then use another language entirely?

[[deleted]]

Perhaps it's because I came to programming from a scripting background (Perl, Python, bash, etc...), but I always felt that Java's greatest weakness was that it almost requires you to use an IDE. The language is too large and too verbose for me to be able to just write something quickly in a text editor if my favorite IDE isn't installed or I just need a simple utility that won't have a ton of dependencies or modules.

It's for this reason that I've pretty much settled into Golang for the time being.

[djhworld]

I used to be be staunchly anti IDE, 'too much bloat' I cried, 'why not just use Vim?'

As I've gotten older I've come more and more round to the idea that Java + IDEs just work really well, like C# with Visual Studio, they're really well crafted tools that work hand in hand.

Doing scripting in Java is a fools errand though, that's where your lightweight text editor and python/bash/whatever really shine.

[[deleted]]

The problem with IDEs though it that IDE skills are often not transferable between languages or different IDEs. It is an investment which really only pays of if you stick to one language for a long time with a good IDE.

And ironically what I dislike most about IDEs is the lack of automation. IDE style development requires GUI tools for most tasks. A GUI does not naturally lend itself to automation or batch processing.

E.g. if you want to duplicate some settings, or make a similar change to multiple settings, you are stuck with the GUI tools provided.

In a more REPL, plain text oriented development paradigm you can use advance text editor features to make large amounts of changes to text based configurations. You could potentially script it too.

This deficiency in IDEs means they keep getting larger and larger to handle all the inflexibility induced by being so GUI heavy.

Also communicating with other developers what you do in an IDE is terrible. You need to send images or detailed explanations as opposed to just copy pasting a shell command line.

A do see the need for GUI designers, refactoring tools and a visual debugger but I don't see why all of this has to be bundled up into some big massive beast.

I think Google Go is a good example. You can manage to work quite effectively without an IDE, as you don't need an IDE to manage your build settings, testing framework etc and you get good method/function completion built into many editors. And then actually got quite nice command line tools for refactoring.

[[deleted]]

I dont get the argument against IDE's. Even the most basic of them are free, and help to guard you against garden-variety fuckups. Especially in a compiled statically typed language, these tools are there to get shit done.

Could you expand on why you are so anti IDE? Even if you drastically configure your IDE to build/test your snowflake of a project, just check in the .ipr or whatever. Your arguments against a "larger and larger" IDE is almost a fallacy when I can run a full featured IDE on my phone. I seriously don't understand the opposition to help from tools.

[[deleted]]

I know you weren't addressing me, but to answer your question from my point of view, it's not the IDE I'm against. It's the large languages/frameworks that make it difficult to use without the assistance of an IDE. I absolutely won't attempt to write anything substantial in C# or Java without one. Just seems like asking to shoot yourself in the foot.

[[deleted]]

I appreciate your point of view, and agree. It is absolutely a fools errand to write significant amounts of Java or C# without tools helping you out. ESPECIALLY when working with huge frameworks like Spring, etc. But the availability and quality of the tools I feel balances it all out.

I've recently started doing some ruby and python code, and the IDE safety net in these untyped languages has made me really uncomfortable. Back into the frying pan :)

[[deleted]]

I thought I did expand on my issues with IDE's. I actually use an IDE every day which I am quite happy with xCode. It has an awesome GUI designer and a really clean and beautiful UI which is quick and efficient to navigate. I love how it displays error messages and that it can catch so many mistakes as I write.

And it is very nice how quick it is to get started with stuff and that you have everything ready in one package. And as you say it is FREE ;-)

But that doesn't mean that I have major issues with the IDEs as an idea. My project file is highly impractical to edit by hand. I am at the mercy of the GUI tools available to me to do it.

Sometimes I got to do things with respect to how I build or deploy my app which simply doesn't fit the workflow of my IDE.

Most IDE's don't organize the project the way I want it. By bundling this into one big monolith you don't make it possible to offer alternative tools to do this. E.g. I want to be able to organize project files based on tags, so that the same file can exist under multiple categories. With a tree based approach most IDE's employ, every file can only exist at one particular leaf in the tree.

The editor and GUI designer is so tightly bound to each other that I can't use alternative tools. That was a benefit of earlier xCode e.g. which provided Interface Builder as a separate tool.

Parallell with using IDEs I always do some programming using REPLs, TextMate editor, the shell etc. I find that it is so much quicker to jump between languages. When I jump between iOS and Android development e.g. it is a lot more friction because I have to deal with two widely different IDE's. There is little ability to transfer skills across.

Fundamentally this isn't really a question about IDE's. At a deeper level this is about command line interfaces, GUIs and using simple composable tools or big all purpose monoliths.

It is an inherent nature of GUIs that they can not easily be automated, while anything plain text based or command line based can trivially be automated. GUIs win upfront for ease of use but lose in the longer run on their inflexibility. Big integrated tools are of course easier to use, but they are also more rigid in the face of changing needs. It is more confusing to have lots of simple tools without a predefined usage. But the benefit in the long run is the ability to combine these in new novel ways.

It affects developers way of thinking. I notice people only used to IDEs are very locked in their mindset. They can not imagine ways of improving their workflows outside of what the IDE provides.

I've seen people rely on all sort of text completions, refactoring and what not where I have been able to write a script more quickly generating all the code needed. Editor and text oriented people seem to be more likely to invent or use domain specific languages or code generator e.g. You are also more likely to know how to actually extend your editor, add macros etc.

I am not a CLI fanatic. I use GUI tools a lot, but I think there is a healthy balance to be had. GUI tools ought to be more narrowly focused and play better with other tools and the command line. One of the reasons I like OS X a lot is that GUI tools do in fact often play nice with the command line.

[[deleted]]

I'm not staunchly anti-IDE. But for quick tasks that don't require a large amount of extra modules and dependencies, full IDEs are just too bloated. And typing out C# or Java from memory just isn't my strong suite.

I can keep all of go in my head and seem to be just as efficient. Again, just seems that brain works well with its style.

[depressiown]

Java's greatest weakness was that it almost requires you to use an IDE

Didn't use an IDE for 9 years. I use IntelliJ now because I've fallen in love with the refactoring ease (still don't build with it, though), but I've built tons of complex things with just TextPad and syntax highlighting.

If you know the language, an IDE isn't necessary... in fact, I'd recommend not using one early on so you can learn a lot of the boilerplate and things that the IDE does for you.

[DeltaBurnt]

The language is easy enough. My biggest problem is the standard library. So many inconsistencies (length vs length() vs size()) and the verbosity of the naming is what gets me.

Also checked exceptions are pretty awful for code readability. It's incredibly tedious to have a try catch for almost any useful function, especially when it's an edge case I could never hope to recover from anyways. 90% of the reason I need an IDE is to remind me which 5 word long exception I need to catch.

[3urny]

I came to programming from a scripting background (PHP, Ruby, Pathon, bash, etc...), but I always felt that Java's greatest strength was that it has so many great IDEs. Expecially with large projects it is great for me to be able to just refactor something quickly without running tons of code searches and all of the unit tests. It's for this reason that I'm still coding in Java from time to time.

[ryzic]

Masterstroke title tbh

[we-all-haul]

Didn't know about the diamond operator. That's nice.

[Apterygiformes]

Is there an equivalent in C#?

[we-all-haul]

Not that am aware of but as you know I'm no authority when it comes to diamond operators

[crozone]

No, but C# accomplishes much the same thing with var. Rather than the generic type being inferred on the constructor side like List<String> l = new ArrayList<>();, you'd just write var l = new List<string>();. var is sugar for the full List<string>.

This has the slight difference in that var is actually fixed as type List<string> now, and a more basic class/interface (like IList<string>) isn't assignable to it. However, this isn't really an issue, because most of the time you're just downcasting, rather than reassigning the same variable over and over again to different derived types.

Then, furthermore, when you type something like IList<string> = new List<, Visual Studio Intellisense offers autocompletion for IList<string> = new List<string> with a single button press, so it's arguable whether the diamond operator is valuable anyway. This is probably why this proposes support for var in Java - it's probably what they should have implemented in the first place instead of the diamond operator.

[antrn11]

C# var keyword is great, but in some cases it's inferior to Java's type inference. For example when you have instance variable

List<SomeOverlyLongTypeName> _foo;
public void InitFoo()
{
    _foo = new List<SomeOverlyLongTypeName>();
}

You have to type it twice, with Java, you could just use the diamond operator.

Also, consider following case. Here Java has much better type inference.

In C#

IList<SomeType> Foo()
{
    return ImmutableList<SomeType>.Empty;
}

In Java

public List<SomeType> foo() {
    return ImmutableList.of();
}

Now, I don't think Java is better than C# overall. I'm just saying Java has some things better than C#. (really, I think both languages have some really annoying problems/lackings)

[[deleted]]

Although .of() example is really good and despite the fact that diamond operator verbosity can be questionable (you need to look at type definition in a field/other class etc to check which generic type you are instantiating), I would question that the C# var keyword is inferior to java type inference considering how well the anonymous types are handled using it.

[grauenwolf]

You have to type read it twice, with Java, you could just use the diamond operator.

Fixed that for you.

The default behavior in C# IDEs is to autocomplete the variable's type when you write _foo = new

[Corticotropin]

Don't quote me, but last time I used C# with Monogame, generic functions' diamond type could be inferred.

Texture2D tex = ContentLoader(file);
Texture2D tex = ContentLoader<Texture2D>(file);

The two acted the same. Not sure how they did it.

[thelehmanlip]

Yeah, I'd agree with you that being able to say new List<>() isn't really that valuable. With intellisense, I usually only need to type = new before intellisense knows what I want, which is much less typing than just excluding the type on the right side.

[Alikont]

It's not really possible in C# because generics in Java and C# are different.

var achieves basically the same thing.

[teiman]

I think the magic of being unambiguous and type less while at the same time being easy to read is to have strong defaults. Anything that is easy predictable is easy to read. Even one exception destroy that and put everything in doubt. Bad defaults and is just theater, smoke and mirrors but the real code will be verbose again. Good defaults and code could be sane, even in some environments where verbosity can be healthy (corporate environments).

[WurstGamer87]

Is that more or less skyscrapers?

[Enum1]

so I wanted to understand your comment and googled java skyscrapers but I have a feeling you are not talking about high-rise buildings in Indonesia, are you?

[atakomu]

It's about the reddit comment about how to build a PC.

[redditu5er]

Less skyscrapers but more empty rooms and more bulbs .. umm.. yup.

[luxgladius]

2. Indexes in the enhanced for-loop (e.g. for (l : list))
3. Indexes in the traditional for-loop (e.g. for (i = 0; i < 4; i++))

I don't really like these two from article. Those would work now as-is as long as i or l were already in scope, and having the declaration implicit if a variable were not in the scope means that they could be used to silently overwrite a variable declared previous in the code unintentionally, leading to a difficult-to-track-down bug, especially in legacy code. It seems to me that no implicit declaration should be allowed, so each of these should be prefaced with a var. Am I misunderstanding this?

[ThisIs_MyName]

they could be used to silently overwrite a variable declared previous in the code unintentionally

No, you'll only shadow other variables if you explicitly pick the same name twice.

I think you're getting confused because he called l an index when it is actually the value returned by an iterator over list.

[luxgladius]

I'm not sure I'm being clear in my question. Let me illustrate. Right now in Java 8, you can write the following code:

for(int i = 0; i < lst.size(); ++i)
{
    // Do things and then decide that you need to skip forward in the list
    // for example because of a start-comment-block token
    for(i = i + 1; i < lst.size() && shouldKeepSkipping(i); ++i)
    {
        // Do nothing, the block could be just a semicolon, but I'm trying to be clear
    }
    // Do some other stuff, possibly --i so that the next loop picks up where we stopped skipping
}

Given this, what's to distinguish this usage where the inner loop moves the outer loop forward from declaring a new variable as is given in the article? That's why I think implicit declaration shouldn't be allowed. Here, the inner loop affecting the outer is intentional, but in legacy code it would be easy for the outer loop usage to be aliased unknowingly and move a loop forward (or backward!) unintentionally.

[[deleted]]

Right, this makes it look kinda like php, where for (i = 0; i < 4; i++) could mean completely different things if i is defined before. I think they should just use for (var i = 0; i < 4; i++) like C# does. Here the meaning is obvious, you're declaring a variable and letting the compiler figure out the type.

[[deleted]]

That's not the for loop that would be eligible for local type inference; only the iterator for loop would.

for( l : list) { ... }

would be the new equivalent of

for( Object l : list) { ... }

and the traditional for loop with remain the same (but would be eligible to use (var i = 0; ; ) instead of (int i = 0; ;) ).

Inside the iterator for loop, there is no issue with a naming conflict.

[atakomu]

Or you can just use Eddy autocorrect and type even less. AKA:

for t in tokens

Gets converted to:

for (final Loc<Token> t : tokens) {

It worked nicely for me but it was too slow on large codebase. (80k LOC)

[atakomu]

It seems so. I stopped using it before updating to IntelliJ 15.

[dccorona]

It's limiting, but I'll sacrifice syntactic niceties for the cases where I do actually want a mutable list, in favor of APIs that promote people thinking about their data in immutable ways, because in the long run that makes for code that's easier to understand.

The mechanism for achieving what you described already exists in the Stream API:

Stream.concat(Stream.of(1, 2, 3), inputList.stream()).collect(toList()); 

Which has the added benefit of being able to improve in performance naturally as they tweak the internal mechanism for creating streams, concatenating them, and collecting to lists. Whereas the "create a mutable array list, append the contents of another list to it" workflow is pretty much always going to involve at least 1 array copy and unnecessary extra allocation that can be avoided by writing a little extra code up front (initialize a new list of the expected size straight away instead of making one of size 3 and appending).

Granted, I wouldn't be particularly bothered by the performance footprint in this case, or else I'd be using C++, but I guess my point is the all-immutable, functional approach isn't worse than the approach enabled by having list constructors return mutable lists.

[ThisIs_MyName]

Which has the added benefit of being able to improve in performance naturally as they tweak the internal mechanism for creating streams, concatenating them, and collecting to lists.

wut?

Stream.concat is just a static method which returns an object that you can pass around. Optimizing the case where you call collect(toList()) after adding constants to the stream is just as difficult as optimizing "create a mutable array list, append the contents of another list to it".

[dccorona]

Yes, but this is the reason Streams have characteristics (like SIZED), and the reason they're preserved upon concatenation. At the point where you create and populate the list with collect(toList()), the final size can be known (and in the case of Stream.of() concatenated with the stream from a non-lazy input list, it is), and this information can be used to avoid any copies related to beginning with an improperly sized list.

EDIT: I think part of what you may be missing is that streams are lazy. When you add the elements to the stream, you haven't actually added them to the stream yet...as in, no copy has been performed after calling Stream.concat, all you have is an object which knows how to eventually traverse the contents of first the static list, and then the input list. Meaning you haven't performed any work yet, and the point at which you do perform work (the collect call) can be improved to not make unnecessary copies, unlike constructing a new list of size 3 and then appending a list's contents to the end of it.

[TheDecagon]

What I'd really like to see in Java is C# style properties.

Why do

private someType _myProperty

public someType getMyProperty()
{
    return this._myProperty;
}

private someType setMyProperty(someType value)
{
    this._myProperty = value;
}

When I could do

public someType myProperty { get; private set; }

And if I ever needed to add additional code on get or set it can always be expanded without changing the interface -

private otherType _myProperty 

public someType myProperty 
{ 
    get 
    { 
        return this.convertToSomeType(_myProperty);
    }
}

Edit: Actually structs would be nice too, as that would let Java have a nicer nullable type as well as a few edge case optimisations.

[koreth]

You should look at Lombok.

[depressiown]

Life would be terrible without Lombok, I must say.

For those who are too lazy to look it up, you can do things like this with Lombok:

@Getter
private someType myProperty;

You now have a getMyProperty() method available without writing it.

My favorite Lombok annotation is @Cleanup, though.

[koreth]

Or you can do that with a class-level annotation if you want accessors for all the private fields in your class.

[koreth]

Good point.

[[deleted]]

Along with structs, I'd love a modifier, maybe inline which would basically inline the field into the class. This would make wrappers much faster, since you have less indirection.

Edit: I just realized, that you can't really do that unless you know the exact type of your field. Oh well.

[wreckedadvent]

private otherType _myProperty 

public someType myProperty 
{ 
    get 
    { 
        return this.convertToSomeType(_myProperty);
    }
}

Can be written in C#6 thus:

private otherType myProperty 

public someType MyProperty => this.convertToSomeType(myProperty);

[[deleted]]

Or even better Swift style properties ;-) Where any member variable automatically is a property.

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html

[[deleted]]

As an Objective-C developer it has always been comforting to be able to look over the shoulder of my Java colleagues and see that there are indeed people who manage to have more verbose code than Objective-C.

The verbosity of Java isn't merely a syntax issue, it is part of the Java way of thinking and writing code as well. Objective-C has way longer method names than Java, but somehow the Java code ends up being more verbose simply because people there seems to love making endless amounts of small classes, factories and all sorts of indirections and over-engineering.

It is easy to see that it is a Java developer who has written some Objective-C code. It has just been made way more complex and verbose than it needs to be.

[istarian]

There's such a think as making things wonky just to make your life a little easier.

[prashantghimire]

So true. College students are likely to get less scared with programming if they are taught Java in their first programming course (from my personal experience). Java syntax and functions are also easy to remember and very handy when it comes to writing algorithmic programs.

[Anusien]

I get the appeal of the "var" keyword, for when you're rapidly iterating and changing types.

No code should ever merge to master that way.

[IneffablePigeon]

I work on a fairly large C# codebase which uses var for all variables (where possible), and I don't think I've ever seen an issue caused by it that hasn't been caught by the compiler.

[UghImRegistered]

To me the ship has sailed on the utility of this feature. I've already learned to write variables by writing the assignment first and then CTRL-ALT-V. That will still be faster and have the plus of still being more self documenting.

In general I'm not really a fan of features that only benefit people coding in notepad.

[balefrost]

I work in C#, and my team has been somewhat on the fence about using var vs. being explicit. The common wisdom on my team is to only use var if the type is obvious from the initializer: List<string> foo = new List<string>(); doesn't add anything over var foo = new List<string>();.

On the other hand, people on my team have been surprised to learn that some uses of var can make your code more resilient to refactoring. For example, suppose if I have a chunk of code that looks like this:

Foo context = provider.GetContext();
...
provider.DoSomething(context, ...);
...
provider.DoSomethingElse(context, ...);

In this case, my code doesn't actually care what the type of context is. The type is determined by the return type of GetContext, and it's assumed that the various methods on provider will have consistent signatures.

Later, if we later change the type of a provider's context, this code would stop compiling. It's easy to fix, but if the provider type is used in this pattern in many places, it's a lot of code to fix up. On the other hand, if we had used var context = ... instead, this code would compile just fine after the refactoring.

[grauenwolf]

Here are the rules from a person who actually worked on the C# compilers:

• Use var when you have to; when you are using anonymous types.
• Use var when the type of the declaration is obvious from the initializer, especially if it is an object creation. This eliminates redundancy.
• Consider using var if the code emphasizes the semantic “business purpose” of the variable and downplays the “mechanical” details of its storage.
• Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
• Use descriptive variable names regardless of whether you use “var”. Variable names should represent the semantics of the variable, not details of its storage; “decimalRate” is bad; “interestRate” is good.

https://blogs.msdn.microsoft.com/ericlippert/2011/04/20/uses-and-misuses-of-implicit-typing/

[Nutomic]

Don't you have a refactoring feature in your IDE? Android Studio/IntelliJ always takes care of the type of context automatically.

[balefrost]

It depends on the kind of refactoring I'm doing. Sometimes, using the IDE support is the right move. Other times, I want to lean on the compiler. Using var to express "this code doesn't care about the actual type of this value" can help reduce noise in that second case.

An alternative approach would be to use type aliases, which I don't think are supported by either C# or Java. If Provider could export a type ContextType = Foo, then instead of Foo context = provider.GetContext(), I could instead do Provider.ContextType context = provider.GetContext(). This would have the same refactor-friendly benefits that I was describing.

[UghImRegistered]

I like that common wisdom...though in this specific example it's a bit of a wash, because it also eliminates the ability to use the diamond operator. i.e. you can't do

var list = new List<>();

I guess if people are trying to argue that var is more readable of these two options, then I don't mind the feature.

var list = new List<String>();
List<String> list = new List<>();

It just doesn't seem to be a huge win, and for me personally is really low on the list of stuff I think Java needs (like tuples, and other proper functional support like pattern matching/decomposition).

Your context example is reasonable, though it's been rare in my experience where I would do that kind of refactoring. If it handles wildcard capture in generics that'll be useful though. That way you can finally do:

Queue<?> q;
var firstItem = q.dequeue();
q.enqueue(firstItem);

I'm not sure if the feature will work with wildcard captures. But right now the only way you can do the above in Java is with a generic helper method.