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

111–120 of 203 posts

Re: Modern Java – A Guide to Java 8

#111

Post by raspasov »

lmm wrote: post #40
raspasov wrote: post #26

Earlier quoted context omitted.

What do you think is not quite right about errors in tranducers? When you use them with core.async channels you can supply an optional exception handler, which is quite nice. In terms IDEs, Cursive for IntelliJ is great, and it gives almost Java-like capabilities (with limitations inherent to more dynamic languages, of course).

I forget the exact behaviour, and maybe it's been improved. But I remember that it didn't map cleanly onto values - sometimes you want to continue after a single error, sometimes you want to bail out immediately, and the ways of doing this felt very ad-hoc.

I think you can do what you are describing with a channel https://clojure.github.io/core.async/#clojure.core.async/cha...

Re: Modern Java – A Guide to Java 8

#112

Post by haxeny1 »

pjmlp wrote: post #64
kriro wrote: post #32

I've always had some sort of mistrust of Java (neo-Cobol ohnoes!) but I'm liking it more and more. Mostly I've come around to the fact that static typing isn't as bad as my young self thought (and can in fact be quite cool). The verbosity and "enterprisy" and committee oriented feel are still a bit off putting but I've made a commitment to try some Java on a couple of weekends. Did a bit of research and there's actua…

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 point for me. Add to that, to program in java before IBM Visual Age was released was to using vi/notepad(++?) editors. Coming from Smalltalk env that was a bit of a shock. Eiffel commercial IDE from ISE was way better and its clever use of pick event on the mouse's right click to drop to compile/run targets was actually easier on my fingers, which is a side show, but good quality products demonstrate quality at unexpected places.

I am still programming in java in my day job, knowing fully well that Java was not my top five language choices. Eiffel's type system was a bit more advanced than Java even way back in those days, so not only was I stuck without an ide till VA for Java showed up or VisuallJ++ I also had to accept weak inheritance and design by contract models. Performance of course was not even close to an Eiffel compiled C code, which was probably addressed in later versions of java.

My point being, that just as Eiffel was something that was better and set aside by a few leading development shops, there must have been other languages that could/should have received a fair share in language evaluation by programmers, I dont necessarily mean limiting to Ruby, Python for example, despite them being excellent tools, they may fall short in an enterprise ecosystem. What happened at least I seem to think instead is a sort of groupthink to start coding in Java because of rubbernecking. All in all, I think that things could have been better if people paused to understand the Java language model and fixed in java 1.2/3, or some earlier version so we didnt have to wait till Java 1.8 to get these features. /rant.

Re: Modern Java – A Guide to Java 8

#113

Post by justinhj »

jinst8gmi wrote: post #11
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?

> Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine? If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Other than no new learning required I can't think of many reasons to pick Java as a first choice. Java tends to be popular because it's th…

There's an irony that your comment is in a thread about learning new features of Java 8

Re: Modern Java – A Guide to Java 8

#114

Post by jinst8gmi »

RyanZAG wrote: post #110
jinst8gmi wrote: post #74

Earlier quoted context omitted.

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(); 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 str = "I'm a String"
   SomethingOrOtherFactory factory = new SomethingOrOtherFactory();
which isn't any clearer than:

   val customer = new Customer();
   val str = "I'm a String"
   val factory = new SomethingOrOtherFactory()
Having a dozen getter/setters is generally a code smell, but having a dozen getters isn't.

Re: Modern Java – A Guide to Java 8

#115

Post by arjie »

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

Sort of like http://www.scala-lang.org/api/current/index.html#scala.Tuple...

Re: Modern Java – A Guide to Java 8

#116

Post by dschiptsov »

incepted wrote: post #91
dschiptsov wrote: post #33

Earlier quoted context omitted.

OK, what then is Java The point was that if one has a proper old-school computer science (to realize the crucial importance of first class procedures and the power of uniformity 20 years ago) all these modern features are coming for free, to which the code above is an illustration. But who cares. There is a whole industry which praised Java for almost two decades even without these "modern features". Any PL student o…

> Any PL student of a decent school, if he is not a hypocrite, would tell you that Java is the worst thing that happened to CS since MS DOS, That's why we don't listen to students to make this kind of uninformed claims. Java has flaws, for sure, but calling it the "worst thing since MS DOS" can only come from someone who lacks perspective and experience.

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?

Re: Modern Java – A Guide to Java 8

#117

Post by grokys »

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.

Re: Modern Java – A Guide to Java 8

#118

Post by incepted »

dschiptsov wrote: post #116
incepted wrote: post #91

Earlier quoted context omitted.

> Any PL student of a decent school, if he is not a hypocrite, would tell you that Java is the worst thing that happened to CS since MS DOS, That's why we don't listen to students to make this kind of uninformed claims. Java has flaws, for sure, but calling it the "worst thing since MS DOS" can only come from someone who lacks perspective and experience.

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.

Re: Modern Java – A Guide to Java 8

#119

Post by rcurry »

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 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 defense contractor, but that you'd probably never see out in the more general software development world.

Re: Modern Java – A Guide to Java 8

#120

Post by ygra »

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.
Post reply on HN