Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Java – A Guide to Java 8

github.com

Post reply on HN
Print view View original

121–130 of 203 posts

Re: Modern Java – A Guide to Java 8

#121

Post by leothekim »

mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

Hear hear. A couple more features that'd be nice:

- An `public Optional or(Optional other)` so if optA is empty, then `optA.or(optB)` would return `optB`

- A `toStream` method on `Optional` (I believe this is coming in Java 9) or have a `Stream.flatMap` signature that flattens `Optional`s without needing to call `Optional.toStream` (Scala does this, arguable if this is an acceptable munge of Monadic types, but it's really convenient)

Re: Modern Java – A Guide to Java 8

#122

Post by pjmlp »

haxeny1 wrote: post #112
pjmlp wrote: post #64

Earlier quoted context omitted.

Good luck with your experiments. Many of us in the 90's jumped into Java, in spite of its issues, because it made it more pleasing to write cross platform code, than using C or C++ with CORBA/COM across OSes with compilers that were still playing catchup with the standards.

I never understood the following : Eiffel had a better syntax, better support for core issues, Void type, design by contract, multiple-inheritance and an intermediate virtual machine for portability although the most common target was C code. To name a few. I was using Eiffel in a small side project just about when Java released their 1.1.4 (a version before the object serialization library, iirc). It was a sticking…

I agree with you.

Before Java was known to the world, I already knew plenty of languages with closures, value types, GC,AOT compilation to native code, ...

But they all suffered from two problems, not being from known companies with geek credit and being commercial.

Java was from Sun (geek credit) and was free (as in beer), hence why it got adopted.

I think it would been great if Eiffel had got a decent market share,instead of just the DBC ideas.

But if I remember correctly they went after the enterprise, so the language was out of reach to many developers given what they used to charge for.

Re: Modern Java – A Guide to Java 8

#123

Post by RyanZAG »

jinst8gmi wrote: post #114
RyanZAG wrote: post #110

Earlier quoted context omitted.

I think jbooth is talking more about forced verbosity such as Map customerMap = createCustomerMap(); where in other less verbose languages you find val customerMap = createCustomerMap(); Always seeing the definition of a value in the current function context is actually very nice for maintainability, but does give Java the reputation of being overly verbose. Stuff like getters/setters on all values in a class are awf…

I agree with you, up to a point. I find Ruby code pretty awful to make sense of with very little type information. Type inference with explicit return types for methods strikes a nice balance between verbosity and readability. I think Scala, Kotlin and to some extent C# do a better job of this than Java. There are also many less favourable cases where you see things like: Customer customer = new Customer(); String st…

Agreed, but:

  Animal customer = new Cat();
It makes it clear how the new object will be used. It does come up quite frequently, especially with Collection and List. Nobody was saying it is not verbose and can lead to boilerplate. The assertion is that when viewing a large code base, you are always sure of the type of value you are dealing with on a local level. If all of your objects are well defined, you don't even need to look at how the class is created (a billion getters and setters? irrelevant to the local function) as you only need to deal with the local function.

Re: Modern Java – A Guide to Java 8

#124

Post by LoneWolf »

grokys wrote: post #117
mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

I'm not so up on Java, could someone explain why they chose "->" for lambdas instead of the "=>" that C# and ES6 use, as those languages seem to me like they would be the first place to look for inspiration.

While I don't know the reason i like it because for me is easier to type -> than => (portuguese keyboard, TBH dont know the difference from english)

Re: Modern Java – A Guide to Java 8

#125

Post by WaxProlix »

grokys wrote: post #117
mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

I'm not so up on Java, could someone explain why they chose "->" for lambdas instead of the "=>" that C# and ES6 use, as those languages seem to me like they would be the first place to look for inspiration.

AFAIK that's actually non-standard. Haskell and (more importantly, maybe) C++11 use the single-line arrow (->), as do Erlang and various ML dialects (interestingly, F# uses the single-line notation, too, while C# does not). Probably other languages as well.

Re: Modern Java – A Guide to Java 8

#126

Post by kodablah »

mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

I believe this use is a real overuse and is definitely abusing. Sure, use optional as a return type when clarity is needed, but otherwise don't do all of this when you could use a simple conditional ala:

    String foo = defaultValue;
    if (parameter != null && ...) {
      foo = doAAndB(parameter);
    }

Re: Modern Java – A Guide to Java 8

#127

Post by rcurry »

lomnakkus wrote: post #63
manyxcxi wrote: post #57

Earlier quoted context omitted.

I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Only now with the most recent features is it really likely that you'll run into some one-liners and magic functions. Now, if you were talking about frameworks/app servers and not being able to figure out which levers and knobs to push to get them to behave, I would agree wholeheartedly. I'm not saying Java is good lo…

> I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Not bad_user, obviously, but excessive verbosity can be antithetical to readability. (As can excessive conciseness.) It can make the overall structure and meaning of the code hard to discern, even though can clearly tell where what gets assigned to what variables, etc.

The thing that always kills me on new Java projects is wading through these enormous hierarchies of folders full of interface classes just to find one actual line of implementation code. Of course, right after that one line of implementation code there's an invocation of some other interface class that then leads me on the next goose chase to find line 2. I think it's not so much a problem of verbosity as it is this sort of "Enterprise FizzBuzz" mentality that crept into Java over the years. Some of this IOC stuff gets so far out of hand that I feel like I'm in the House of Mirrors at the local carnival when I first start trying to walk through a new code base.

Re: Modern Java – A Guide to Java 8

#128

Post by mavelikara »

mark_l_watson wrote: post #80

This is a really nice write up! Java 8 is such a huge improvement over previous versions. One thing it still lacks is a better literal format for defining maps, etc. I just self published a book that uses Java 8 ( https://leanpub.com/powerjava if you will pardon a plug) and to be honest I got some pushback from a few people who like my books as to why I didn't use Clojure, Haskell, etc. To be honest I do prefer Cloju…

Mark, I am sure you know this, but I am posting this for the benefit of others who might not.

For literal maps, I tend to use double brace initialization style. It is more verbose than languages with direct literal support for maps and creates an extra anonymous class, but it keeps the map in a single syntactic construct. For lists, I use Arrays.asList(a,b,c) style; if you static import the method it reads nicely as-list-a-b-c.

Re: Modern Java – A Guide to Java 8

#130

Post by masklinn »

mkobit wrote: post #108
stephen wrote: post #103

For 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(...

Pretty much all languages with generics will have that kind of declarations, the only question is how many type parameters they'll go up to. In C# Action goes up to 16[0] while Rust's tuple go to 12[1] and GHC goes to 62[2] (intending 100, but a comment notes declaration of a 63-wide tuple constructor segfaults)

[0] https://msdn.microsoft.com/en-us/library/dd402872(v=vs.110)....

[1] https://github.com/rust-lang/rust/blob/master/src/libcore/tu...

[2] https://downloads.haskell.org/~ghc/7.2.2/docs/html/libraries...

Post reply on HN