BufferedReader.lines

BufferedReader.lines is kind of interesting, letting you turn a BufferedReader into a java.util.Stream in Java 8. Here's some small experiments.

Print out the number of lines in a file:

public static void main(String[] args) {
    try (BufferedReader reader = Files.newBufferedReader(
            Paths.get("myfile.txt"),
            StandardCharsets.UTF_8)) {
        System.out.println(reader.lines().count());
    } catch (IOException ex) {
    }
}

Print out all the lines:

public static void main(String[] args) {
    try (BufferedReader reader = Files.newBufferedReader(
            Paths.get("myfile.txt"),
            StandardCharsets.UTF_8)) {
        reader.lines().forEach(System.out::println);
    } catch (IOException ex) {
    }
}

Print out the longest line in a file:

public static void main(String[] args) {
    try (BufferedReader reader = Files.newBufferedReader(
            Paths.get("myfile.txt"),
            StandardCharsets.UTF_8)) {
        System.out.println(reader
                .lines()
                .mapToInt(String::length)
                .max()
                .getAsInt());
    } catch (IOException ex) {
    }
}
Comments:

[quote] reader.lines().forEach(System.out::println); [/quote]

the last fragment of passing in a method from System.out class as a parameter to be invoked over a set of data in another class is amazing, this is what is being 'coded' again & again in various libraries in the name of functions and/or functors.

Is this feature generically available with any class & any method?

Posted by Samba Kolusu on February 03, 2014 at 09:51 PM PST #

I would also like to raise another pain point in Java : the plain old "System.out.println" --> why can't java create abstractions out of its internals? perhaps statically export all the commonly used functions from the important classes into "java.lang" package so that we can simply call println("); this feature, if implemented and allowed for user implementations as well, it will go a long way into making java compete with functional programming languages.

for example, i can export some of my important & commonly used static methods into a org.abc.xyz.lang package so that users of my library can directly call those methods without qualifying those with class names.

Posted by Samba Kolusu on February 03, 2014 at 09:51 PM PST #

Yeah, this is excellent. Brings some functional ways of dealing with data. I use very similar approach in my D applications, and I am glad I can finally do the same in Java.

Posted by Dejan Lekic on February 04, 2014 at 02:19 AM PST #

Thanks for these examples.
The last experiment prints out the length of the longest line, not the longest line. Is there a similar way to print out the longest line?

Posted by ric on February 05, 2014 at 03:15 AM PST #

>I would also like to raise another pain point in Java : the plain old >"System.out.println" --> why can't java create abstractions out of its >internals? perhaps statically export all the commonly used functions from the >important classes into "java.lang" package so that we can simply call >println(");

@Samba

Have you looked into groovy? That's exactly one of the things it gives.

Mark

Posted by guest on February 05, 2014 at 08:41 PM PST #

I answer my question (print the longest line). Is there a better way to do it?
reader.lines()
.max(( s1, s2) -> Integer.compare(s1.length(), s2.length())).get())

Posted by guest on February 09, 2014 at 11:44 AM PST #

Java provides "import static java.lang.System.println;" syntax allowing unqualified use of println (and in general any accessible static method named, or all static methods from a class using *).

Posted by guest on February 13, 2014 at 12:39 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
12
13
14
24
25
26
27
28
29
30
   
       
Today