Really like quite a few Lambda stuff in Java8, sadly once you need to touch any of the intrinsic types it gets ugly real fast. Wanted to do some byte manipulation with Lambda and I'd be creating a new Byte object for each byte I touched.
Modern Java – A Guide to Java 8
101–110 of 203 posts
Re: Modern Java – A Guide to Java 8
#102so... when is this coming to android?
Re: Modern Java – A Guide to Java 8
#103For people getting into Java 8, jOOL is a great, small library with a "Seq" class that fills in the gaps missing in j.u.stream.Stream:
E.g. if you're coming from groovy/Scala and wonder "why doesn't Stream have this method?", Seq probably either already has it, or the maintainer will be open to adding it for you.
So, use jOOL. It's great.
That said, I still cringe that we have to do "someCollection.stream()..." (or use fill-ins like jOOL) at all, because these methods aren't on j.u.List/etc. itself...
My naive impression is that the JDK designers fixated on making streams support parallelization (because fancy!), and so made some compromises on the API, when in reality 98% of collections are small/not parallel, and I assert a non-parallel, more complete API (e.g. more default methods directly on j.u.List/j.u.Iterable themselves) would have been a net-win to most programmers.
And the parallelized version could be a separate library/jar/something.
Re: Modern Java – A Guide to Java 8
#104Earlier quoted context omitted.
Thanks for your feedback. I've improved the section about maps to better reflect the capabilities of streaming maps: https://github.com/winterbe/java8-tutorial/blob/master/READM...
Thanks for your hard work here! Side note: http://winterbe.com looks quite similar to angel.co. Or does angel.co look quite similar to your website? :-)
Dunno. I wrote the whole css for winterbe.com from scratch. To be honest I don't find both pages like similar besides white background and gray subtitles. :-)
Re: Modern Java – A Guide to Java 8
#105Earlier quoted context omitted.
Yep, somewhere at Xerox PARC in the early 80's coll := ((1 to: 100) select: [:x| ( x * x ) > 3]) collect: [:x | (x * 2)].
What language is this exactly? I'd love to research a bit more. Just any search terms to point me in the right direction.
Smalltalk.
Re: Modern Java – A Guide to Java 8
#106Earlier quoted context omitted.
Besides null being a potential type for any reference and causing a ton of issues I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them. Enum types didn't exist in Java when the Comparable interface was implemented. That's why some API's look old-school by comparison because newer language f…
> I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them. My counterargument would be the popularity of annotation-based libraries in Java. An annotation is basically a place where the official type system has proven inadequate.
That's not entirely true, part of annotation's use case is metasyntactic: codegen, code analysis and just plain structured/extractable comments.
Re: Modern Java – A Guide to Java 8
#107Earlier quoted context omitted.
Yep, somewhere at Xerox PARC in the early 80's coll := ((1 to: 100) select: [:x| ( x * x ) > 3]) collect: [:x | (x * 2)].
What language is this exactly? I'd love to research a bit more. Just any search terms to point me in the right direction.
[deleted]
Re: Modern Java – A Guide to Java 8
#108For people getting into Java 8, jOOL is a great, small library with a "Seq" class that fills in the gaps missing in j.u.stream.Stream: https://github.com/jOOQ/jOOL E.g. if you're coming from groovy/Scala and wonder "why doesn't Stream have this method?", Seq probably either already has it, or the maintainer will be open to adding it for you. So, use jOOL. It's great. That said, I still cringe that we have to do "some…
That library has some fun/interesting generics declarations like this one (https://github.com/jOOQ/jOOL/blob/master/src/main/java/org/j...)
> static Seq> crossJoin(...
Re: Modern Java – A Guide to Java 8
#109Earlier quoted context omitted.
CompleteableFuture[1] is the closest we got for now in the JDK. [1] https://docs.oracle.com/javase/8/docs/api/java/util/concurre...
I just started using CompletableFuture last week. The way each method ties your lambdas together without a bunch of type boilerplate is really nice. I still don't have a great handle on all of its methods, though; e.g., what's the difference between get() and join()?
CompletableFuture implements Future, so the get method is an implementation of Future.get [1].
Anyway, the major difference is that Future.get throws 2 checked exceptions, InterruptedException and ExecutionException, while CompletableFuture.join does not throw any checked exception. Instead, it wraps any exceptions in CompletionException.
[1] https://docs.oracle.com/javase/7/docs/api/java/util/concurre...
Re: Modern Java – A Guide to Java 8
#110Earlier quoted context omitted.
Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really awesome when you have to read a bunch of code and half the people who wrote it are gone. Boring is better than clever when it comes to maintenance. They're conservative about adding features, so they've managed to keep the language pretty small, and the core co…
I don't really find it "actually really awesome" when I have to read through 6 screens worth of getters and setters in legacy Java code vs what it would have looked like in C# or Scala. In Scala or C# you're looking at the actual logic, not playing hide and seek with it amongst irrelevant boilerplate in Java. Java developers usually consider features which the language doesn't have to be bad or make code unreadable,…
I think jbooth is talking more about forced verbosity such as
Map customerMap = createCustomerMap();
val customerMap = createCustomerMap();
Stuff like getters/setters on all values in a class are awful though and are both a code smell and unnecessary. They break the OO principles and should not be there in the first place. It's good that Java makes those 6 screens worth of getters and setters awful - they are awful. For objects which are used solely for transfering state, check out Google's AutoValue ( https://github.com/google/auto/tree/master/value )
However if you do see a class that is 6 screens of just getters and setters then you know exactly which class you need to fix.