Modern Java – A Guide to Java 8 • Hacker News Board

Re: Modern Java – A Guide to Java 8

#131

Post by pjmlp » Mon, Nov 16, 2015, 5:53 PM UTC

mavelikara wrote: post #128

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-…

Which is a no-go in Android as it can prevent GC in some cases, because as anonymous inner class it holds a reference to its parent and you end up leaking Activities.

It is usually presented as anti-pattern in talks about Android performance.

Re: Modern Java – A Guide to Java 8

#132

Post by pjmlp » Mon, Nov 16, 2015, 5:55 PM UTC

rcurry wrote: post #127

lomnakkus wrote: post #63

Earlier quoted context omitted.

> 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…

Hence why IDEs with their code navigation tools rule.

Re: Modern Java – A Guide to Java 8

#133

Post by haxeny1 » Mon, Nov 16, 2015, 5:59 PM UTC

rcurry wrote: post #119

haxeny1 wrote: post #112

Earlier quoted context omitted.

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 developed a great interest in Eiffel after I read Bertrand Meyer's book "Object Oriented Software Construction" (which I still think is one of the all time great books on object-oriented programming), but I never found anyone else that was using it and the IDE was way too expensive for me at the time. It just seemed to me like one of those technologies you'd probably get to have fun with on some niche project at a…

I was one of those folks who actually bought the personal license. Over years, SmallEiffel came along and improved the ecosystem. Of course, now Eiffel has a community/enterprise model. In any event, I do think that they were pricing them out of the market. Defense contractors, seem to like ada more. The feature that I miss from Eiffel is the Expanded (allocated on stack feature). Even haskell has some #untyped to deal with boxing primitives. I thought that Expanded was a stroke of genius: bringing specification to implementation without the middleman(aka heap).

Re: Modern Java – A Guide to Java 8

#134

Post by dschiptsov » Mon, Nov 16, 2015, 6:01 PM UTC

incepted wrote: post #118

dschiptsov wrote: post #116

Earlier quoted context omitted.

Why, I have experience of re-instalation and restoring data from backup each time Business Objects JVM process segfaults, because there is no way keep track of state unless it shuts down property. How about this perspective?

Good for you but it doesn't make your previous statement any less of a preposterous hyperbole.

Tell us, please, what language comes to one's mind instantly afer reading this chapter below?

http://the-programmers-stone.com/the-original-talks/day-1-th...

Re: Modern Java – A Guide to Java 8

#135

Post by pjmlp » Mon, Nov 16, 2015, 6:02 PM UTC

jinst8gmi wrote: post #74

jbooth wrote: post #61

Earlier 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,…

The first time I saw properties was in Eiffel, afterwards adopted by Delphi, which eventually found their way into C# and to many other languages.

Comparing to the original implementation of properties in C# (not how they look now), the Java way wasn't that different.

They just copied what was common C++ and Smalltalk practice back then, whereas Anders obviously had his Delphi experience.

Not that they shouldn't eventually improve it.

Re: Modern Java – A Guide to Java 8

#136

Post by dschiptsov » Mon, Nov 16, 2015, 6:02 PM UTC

jdmichal wrote: post #97

dschiptsov wrote: post #70

Earlier quoted context omitted.

Yes, there are different forces in a play. Let's name it as The Law of a Decent Runtime, and The Law of Attention to Details, and The Law of a Bazar of Ignorant.)) The Law Of a Decent Runtime is very simple - evolving a decent runtime is very costly and time-consuming. It is also related to the second law and to the inverse of the third - which is a the Law of Dictature of The Most Competent . A decent runtime cannot…

Your Law of a Decent Runtime reminds me exactly of the "Lisp Curse": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

There is another good reading.)

http://the-programmers-stone.com/the-original-talks/day-1-th...

Re: Modern Java – A Guide to Java 8

#137

Post by kodablah » Mon, Nov 16, 2015, 6:02 PM UTC

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.

In addition to the other answers, I bet it's easier for a CFG to parse knowing that "->" can't also be "negate and greater than" (since negation is only a prefix op) whereas "=>" can easily be a fat arrow or greater-than-or-equal.

Re: Modern Java – A Guide to Java 8

#138

Post by mullr » Mon, Nov 16, 2015, 6:05 PM UTC

struppi wrote: post #4

escherize wrote: post #2

I personally jumped right into Clojure on the jvm without much Java experience. I've found it to be awesome. Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine?

Disclaimer: I personally prefer clojure, but earn most of my money as a consultant / coach helping clients develop Java code. For Java code, it's often easier to predict the performance characteristics of a part of the code. But you shouldn't trust your judgements anyway - instead use a profiler - so this is not really a reason. Speaking of performance: I once talked to someone working for Elasticsearch, and they tol…

Really high performance Java code tries to avoid any allocations on the hot paths, since that requires GC. This means a lot of in-place mutation on pre-allocated objects. (Lucene does this, for example) While this isn't impossible in Clojure, you do have to give up a lot of the immutable goodness that makes it such a pleasant development environment.

Re: Modern Java – A Guide to Java 8

#139

Post by pjmlp » Mon, Nov 16, 2015, 6:06 PM UTC

masklinn wrote: post #130

mkobit wrote: post #108

Earlier quoted context omitted.

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/…

Yes, the only way to avoid this is to do as C++ and D, accept variable number of types in the generics.

Re: Modern Java – A Guide to Java 8

#140

Post by pjmlp » Mon, Nov 16, 2015, 6:08 PM UTC

ygra wrote: post #120

konne88 wrote: post #85

> Default methods cannot be accessed from within lambda expressions. Why is that?

If I had to guess, it's because the lambda will be expanded at runtime to an anonymous interface implementation. Then either the runtime part is the problem or maybe they use a different, but compatible functional interface for the ad-hoc implementation, which then has no access to default methods on the one you're assigning to.

That is not how lambdas work actually work in the reference JVM.

They make use of invokedynamic, there is no expansion taking place as many think.

http://www.infoq.com/articles/Java-8-Lambdas-A-Peek-Under-th...