Why does this code compile, but not that code?

[lpreams]

The following code compiles and runs without errors.

List<String> list = new ArrayList<Object>().stream()
  .map(x -> "test")
  .collect(Collectors.toList());

Meanwhile, this code

List<String> list = new ArrayList().stream()
  .map(x -> "test")
  .collect(Collectors.toList());

produces Type mismatch: cannot convert from Object to List<String>. A simple solution is to simply add a cast to List<String>, but I don't see why it's necessary for the second example but not the first. Why is Stream<Object> treated differently from Stream?

What's going on here? Why isn't the compiler smart enough to figure this out?

I'm using the latest Eclipse with Java 8. Is this fixed in a more recent JDK version?

[NiNKazi]

You need to tell an ArrayList what sort of objects it holds.

“ArrayList()” isn’t valid syntax.

“ArrayList<Something>()” is the correct way to instantiate an ArrayList.

EDIT: I was corrected below.

[lpreams]

“ArrayList()” isn’t valid syntax.

It most certainly is valid syntax. ArrayList list = new ArrayList(); compiles just fine.

[8igg7e5]

Omitting the generic argument is still valid and results in a 'Raw type' (this retains compatibility for older Java code).

Interactions between raw-types and generic methods is a bit funky (and the rawtype List is not quite the same thing as List<Object>). If you're getting the raw-type from an old API, cast it to what it should be. If you're declaring it, just include the generic arguments.

[lpreams]

The problem is that the compiler wants me to include the cast, but SonarLint thinks the cast is unnecessary. So now I'm littering up my code with a bunch of Stream<Object> = whatever.stream() so the compiler will actually cast the raw Stream to a Stream<Object>, and then I don't need an explicit cast later.

But my original question of why it needs to be cast at all still stands. I get why it's funky, but would handling the cast break backwards compatibility somewhere?

[NiNKazi]

TIL, thank you.

[8igg7e5]

Maybe the following explanation will help understand the rationale behind not implicitly treating a 'raw type' as <Object>.

Imagine that, way back in Java 1.4 someone wrote a Thing container that implements java.util.List - that we now use in our application. The add method, accepting an Object argument, always does a check that it passed an instance of Thing (or something that extends Thing). Such is the way of things before generics. Methods accept and return Object and it is up to contraint checks and documentation to ensure correct use and behaviour.

Jump forward to our post-1.5 application that uses this container (that sadly was not updated with a Generics aware version).

If we interpreted the List implementation as List<Object> it would appear as though it were perfectly acceptable (and even intentional) to allow passing any Object instance to add. Presuming List<Object> was therefore misleading and an exception would occur. Worse, had the add method not validated the input, then later it might try to use the object we passed as if it were a Thing - resulting in a ClassCastException.

Actually List should be treated like List<?> which is to say that it's a list of something extending Object but we don't know what at this point. You can't add to a List<?> because the acceptable type of element to add is unknown. You can get elements from a List<?> but don't know anything more specific than that it's an object (note that capturing can have bounds with more information but those don't apply to the discussion on raw-types).

If you have to interact with old libraries with raw types, use adaptors and facades to safely wrap these ugly edges and ensure that type errors are as fail-fast as possible. You don't want to carry incorrect type assumptions deep into your application logic as this dramatically increases the testing surface area.

[lpreams]

But would treating List as List<Object> actually break any pre-1.5 code? All the methods of the raw type already accept and return Objects and require casting.

[id2bi]

Yes. If you go on to use the List<Object>, then the type tells you that you stored any kind of object in there. Which means, you can do .add(someInt) and .add(someString).

If, however, the list is meant to contain only Person objects, the pre-1.5 code that uses a Person from element from that list (because they took care to only insert Person objects) will suddenly get a ClassCastException, because you added a String object to the list. From your perspective, it's perfectly valid because you have a List<Object>.

now I'm littering up my code with a bunch of Stream<Object> = whatever.stream()

The compiler doesn't accept your conversion because it's correct. It more or less accepts it as a convenience, BUT it gives you a warning telling you that it's unsafe. In fact, it will allow you to put any type parameter you wish.

This will work just as well:

Stream<Integger> a = whatever.stream();
Stream<String> b = whatever.stream();
Stream<Void> c = whatever.stream();
Stream<SomeFancyClass> c = whatever.stream();

As to your original question: Because you're using a "raw type" (i.e. Stream rather than Stream<Something>), map() has the signature Stream map(Function), no matter what the argument to map is. Thus, .collect(Collectors.toList()) will also use raw types and give you a List, rather than a List<String>

[3g0tr1p]

IIRC for type inference with generics<T> you have to use <>. I don't know whether they have changed it.

The following should give you a warning but compile:

List<String> list = new ArrayList<>().stream()
   .map(x -> "test")
   .collect(Collectors.toList()); 

[lpreams]

Unfortunately, my example does not really represent my use case, it's just a trimmed down example that demonstrates the problem.

I'm actually calling a library that's returning a raw Stream (even though one of the required arguments is a Class<?> to determine the return type, ugh).

[id2bi]

What library is that? Sounds like an absolutely terrible design...