Streams in Java 8

http://download.java.net/jdk8/docs/api/java/util/stream/package-summary.html

by bra-ket • 12 years ago

94 81 12 years ago

download.java.net

bra-ket• 12 years ago

also https://blog.codecentric.de/en/2013/10/java-8-first-steps-la...

dclara• 12 years ago

Thank you.

Randgalt• 12 years ago

So cool.

pron7• 12 years ago

While lambdas and streams (along with default methods, or traits) are certainly the most important features of Java 8, I'm particularly interested in the pluggable type systems[1].

These are pluggable, orthogonal (intersection?) types, that can even be introduced or inferred for code that has already been compiled without them. I'm not a type systems expert by any means, but I haven't seen anything like it in any other language, certainly not a mainstream one.

There are currently Java 8 type systems for nullability, immutability and more.

[1] http://types.cs.washington.edu/checker-framework/

overgard12• 12 years ago

Yay. They finally caught up to C# 6 years later.

[Edit: to the haters -- where am I wrong other than that I'm making fun of your favorite language?]

discardorama• 12 years ago

(I did not downvote you)

Such jingoism adds nothing to the discourse. Someone can as easily find something in Java 1.5 that C# still doesn't have. So what does that prove? Nothing.

overgard12• 12 years ago

Someone can as easily find something in Java 1.5 that C# still doesn't have.

Like what?

alkonaut2• 12 years ago

Stream<T>, IntStream, LongStream, DoubleStream?

You can't make this stuff up.

EDIT: what I'm trying to say is: why his remark is inflammatory and unnecessary, it's also wrong. This API is perhaps the single worse example of why java makes API's look worse than C#, and there is nothing to be done about it until the JVM stops erasing types.

pron7• 12 years ago

Java's type erasure, while once considered a disadvantage, is now being recognized as one of the reasons other statically typed languages can be ported to the JVM. If Java reified types, it would make interoperability with other type systems extremely hard.

kelseyfrancis2• 12 years ago

Can you clarify your comment? I don't understand how those four types could be avoided with reified generics.

barrkel4• 12 years ago

Type erasure has ups as well as downs. For one, it means you can write runtime polymorphic code when you don't care about static types - something that requires extra effort and a non-generic base type in .net. Any time you pass an object through a runtime polymorphic "hole" (e.g. a location of type java.lang.Object / System.Object), you lose the ability to pass along type parameters. In .net, if you don't have that abstract base class / interface, your only fallback is reflection. In Java, you've got List<?> or whatever it is.

smoyer• 12 years ago

According to TIOBE, it looks like C# stands no chance of ever catching Java. (End of troll feeding)

What I find really interesting about your comment is that I always thought C# was the closest equivalent to Java there was, and that I'd be happy using it if I was developing in the Microsoft eco-system (I gave up on QuickBasic/VisualBasic). It would make more sense if you were sniping at a language you felt was inferior if that language was also signicantly different than Java.

P.S. I didn't downvote you either

overgard12• 12 years ago

Preface: I am not a microsoft fan, or even really a C# fan, but: having used both languages C# is nothing like java except in the most superficial of ways. I'm just amused that the caretakers of java took half a decade to adopt a lot of proven useful features. I wish they'd steal more.

lowboy3• 12 years ago

To answer your question, your comment is just snark that doesn't contribute to the conversation. That's probably where you went wrong.

overgard12• 12 years ago

You can accuse me of trolling, but I think the fact that java took this long to adopt these pretty basic features isn't besides the point, it IS the point.

rbanffy2• 12 years ago

Does C#/.NET have a fully supported runtime for any operating system that can delete (or rename) an open file? ;-)

Quick advice: if you have a valid point, you should state it in a form more conducive to debate. I agree with you Java has some quirks "more modern" languages don't, including C#, which started its life, more or less, as a replacement to Microsoft J++ after Sun successfully made a painful point Microsoft could not "embrace, extend and suffocate" Java just because they wanted to.

overgard12• 12 years ago

Does C#/.NET have a fully supported runtime for any operating system that can delete (or rename) an open file? ;-)

Yes.

Thank you for the quick advice, I'll be sure to ignore it. Because I don't care.

rismay2• 12 years ago

Java has come a long way. Why not just merge with Scala?

pron7• 12 years ago

Because Scala has a very different (I would say completely opposite) philosophy than Java. In a paper outlining Java philosophy[1], the very first thing James Gosling has to say about the language is this: "It was not an academic research project studying programming languages: Doing language research was actively an antigoal."

When describing the design of language, again, the very first thing Gosling says is, "Java is a blue collar language. It's not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea."

So: no research, no PhD, only proven stuff and nothing new. Regardless of your opinion of Scala (I don't like it), I think it's not controversial to say that Scala is on the exact opposite side of the spectrum.

[1] http://dfjug.org/thefeelofjava.pdf

runT1ME2• 12 years ago

Except your argument is invalid because java has continued to add features and keywords to address its flaws.

It is moving towards scala, just at an incredibly slow rate.

barrkel4• 12 years ago

And the one major non-proven thing that it included - checked exceptions - is perhaps the most problematic feature.

jebblue3• 12 years ago

This hurts my eyes, it doesn't look like Java, what would this look like in Java:

     int sum = widgets.stream()
                      .filter(b -> b.getColor() == RED)
                      .mapToInt(b -> b.getWeight())
                      .sum();

talklittle• 12 years ago

    List<Widget> filtered = filter(widgets, new Filter<Widget>() {
        @Override public boolean keep(Widget w) {
            return w.getColor() == RED;
        }
    });

    List<Integer> weights = mapToInt(filtered, new Mapper<Widget, Integer>() {
        @Override public Integer map(Widget w) {
            return w.getWeight();
        }
    });

    int sum = sum(weights);

jebblue3• 12 years ago

Nice, thanks! Now _that_ I get.

overgard12• 12 years ago

Seems too short. Maybe you could split it into 5 files? You don't even have a factory. Much less a factory factory. This code will never cut it in the enterprise world.

Jayschwa• 12 years ago

  int sum = 0;
  for (w : widgets) {
    if (w.getColor() == RED)
      sum += w.getWeight();
  }

barrkel4• 12 years ago

    sorted(Comparator<? super T> comparator)

Eurgh. Why isn't this a projection to a comparable type (or better, a projection to a tuple of comparable types, for use with lexicographical ordering)?

Say you have class Country { int population; int name; }. You want the names of the top 3 countries by population:

    countries.orderByDesc(x -> x.population).limit(3).map(x -> x.name)

But instead, you must do something like:

    countries.sorted((x, y) -> Integer.compare(y.population, x.population).limit(3).map(x -> x.name)

It gets much uglier when you want a lexicographical ordering by several attributes.

jargonjustin• 12 years ago

Java's Comparator type is more general (you don't necessarily need to project the type for comparison) and an existing abstraction. It's not hard to introduce a combinator to transform the representation as a library, as in:

    countries.sorted(by(x -> x.population)).limit(3).map(x -> x.name)

where `by` looks something like:

    <S, T> Comparator<T> by(Projection<S, T> projection);

    interface Projection<S, T> {
       Comparable<S> project(T value);
    }

barrkel4• 12 years ago

Sure; and you'd have to import the thing that contains 'by'.

It's still ugly, and would prevent e.g. a radix sort being used when projecting an integer as the sort key, or American flag sort for strings.

javafu24• 12 years ago

It already exists in the API. Your type Projection is a Function, and by is called comparing in interface Comparator.

so one can write: ``` contries.sorted(comparingInt(Country::getPopulation)). ... ```

bhauer• 12 years ago

Streams are among my favorite Java 8 additions.

More about the goodies in Java 8: http://www.techempower.com/blog/2013/03/26/everything-about-...

blueblob• 12 years ago

This is really cool, that they are making parallelization easier but does anyone else feel like every time they add new syntax to java it becomes harder and harder to read?

wtetzner• 12 years ago

I think the lambda syntax makes it considerably easier to read.

tsotha• 12 years ago

It makes reading java more like reading lisp, which is a different way of thinking entirely. Personally I think it's a mistake to put functional programming into an OO language - it makes code harder to maintain as there are too many ways to do the same thing. C++ has become virtually unusable as a result of all the different languages they've mashed into it, and I'd hate to see java go down the same road.

frankzinger• 12 years ago

"C++ has become virtually unusable..."

Geez, the C++ hate is unbelievable. I use it every day, and it's a great language. No way is it "virtually unusable". Some of the criticisms are justified, but the way people carry on about it is just absolutely beyond overblown.

zmmmmm• 12 years ago

The one feature that Python has that regularly makes me jealous when I'm using other languages is the generator / iterator mechanism. It's possible to write code that is composable and modular in a functional way, and automatically scales to massive data with minimal memory use because the streaming mechanism is built in to the language at the ground level. I hope this is bringing the same to Java for real and that this is not just syntactic sugar on top of regular collection operations.

ygra• 12 years ago

From the docs: »•Possibly unbounded. While collections have a finite size, streams need not. Short-circuiting operations such as limit(n) or findFirst() can allow computations on infinite streams to complete in finite time.»

So they can't just take collections here and pretend they're streams (but you can obtain streams from collections).

But nice to see that the days of writing explicit loops just to filter a collection in Java are over. That being said, I still like Python's or C#'s syntactic enhancements to write generators/IEnumerables. The Spliterator in Java doesn't sound as easy to use and seems more aimed at low-level library code instead of user code. In the latter case you'd probably just get the stream from a collection again instead of creating it yourself. (You can apparently base it on a normal iterator, though, but the docs warn about it having bad performance in parallel scenarios.)

coldtea2• 12 years ago

However, there are good reasons to prefer a reduce operation over a mutative accumulation such as the above. Not only is a reduction "more abstract" -- it operates on the stream as a whole rather than individual elements -- but a properly constructed reduce operation is inherently parallelizable, so long as the function(s) used to process the elements are associative and stateless.

I've read this kind of thing everywhere, but is there any language/runtime/compiler that DOES DO this, or is it mostly a case of "an adequately advanced compiler" syndrome?

Especially for examples as the simple accumulation (addition) above, it seems especially difficult for the runtime to judge how to break down, what the parallelization overhead would be etc.

berdario• 12 years ago

If I haven't misunderstood you, Clojure does: http://clojure.com/blog/2012/05/08/reducers-a-library-and-mo...

Also, this talk that I found on HN some time ago explains some of the gory details behind the idea: http://vimeo.com/6624203

coldtea2• 12 years ago

* If I haven't misunderstood you, Clojure does*

Yes, that's an example of what I was talking about, and I know you can also do it with Apple's Grand Central Dispatch API.

But is Clojure's stuff implicit or do you explicitly ask for the parallel thing to happen?

What I'm asking is essentially: sure, a reduce/map/filter/etc can potentially run in parallel. But does that ever happen automatically when using common API's for map/reduce/etc, or do you have to explicitly tell it to do so?

And if it happens automatically, how does the scheduller knows it's a good idea to run stuff in parallel? For some tasks the overhead might even make the time needed worse.

mark_l_watson• 12 years ago

I have been experimenting with lambdas and streams for several months - great additions to the language.

The one thing that I really hope for a future release of Java is a better literal syntax for dealing with maps and JSON.

Streams in Java 8

Related Stories