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

Better Java – Resources for Writing Modern Java

github.com

Post reply on HN
Print view View original

121–130 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#121

Post by reitanqild »

metaobject wrote: post #97
habosa wrote: post #77

Earlier quoted context omitted.

That's a shame. Java is my favorite language because it has the right balance of strictness (although Go is starting to take over for me). When written correctly, Java can be amazingly productive because you learn so much at compile time but the tools (IDEs) make it so that you can autocomplete away most of the verbosity.

What do you mean by: "you learn so much at compile time"? I'm a C and C++ guy, but I've done a tiny bit of Java a while ago.

A lot of mistakes are picked up before the devs can even compile their project. (Note that I did not say "you". I guess pro C and C++ coders are a lot more thoughful about their code and therefore don't that level of static checking.)

Re: Better Java – Resources for Writing Modern Java

#122

Post by speakeron »

zinxq wrote: post #6

I'm in agreement with the first few comments already - at least some parts of this advice is dubious. For one - some performance examples (specifically, integer array iteration) is 15 times slower with streams. Angelika Langer's analysis: https://jaxenter.com/java-performance-tutorial-how-fast-are-...

I would question these results. I ran the same code on a more modern processor (i7-3930K) for 1000000000 iterations and got these averages over 10 loops after a warm-up:

Array: 453 ms Stream: 887 ms Parallel stream: 120 ms

The array loop code is about twice as fast as the sequential stream (parallel stream blows both of them away). The array loop advantage will start to go away once you increase the complexities of what you're doing in the loop and, of course, the stream code is much more readable.

(Edit: I also tested IntStream().of() instead Array().stream() for the sequential stream test, the results were identical in both cases.)

Re: Better Java – Resources for Writing Modern Java

#123

Post by benjiweber »

jonhohle wrote: post #108

As a fan of immutable objects, I bemoan the builder pattern. The nice thing about constructors (or factory methods) is that you have a compile time guarantee that you have all required components to construct an object and validate its invariants. With a field oriented builder, only the documentation informs you whether you've met all of the conditions to construct an object. Also, a builder which mutates its own int…

You can create immutable "builder" with lambda chains. This also gives you the compiletime guarantee that you have specified the required fields (At the cost of flexibility and ease of adding new fields)

http://benjiweber.co.uk/blog/2014/11/02/builder-pattern-with...

Regarding your isPrefixOf - is there a significant benefit to that being in the standard library? You could define a isPrefixedWith("s") that returns a Predicate yourself.

Re: Better Java – Resources for Writing Modern Java

#124

Post by mahmoudimus »

hiram112 wrote: post #18

I've seen numerous posts lamenting the use of typical Java Beans. The problem with the struct approach is that numerous tooling / libraries expects beans with typical getter/setters - Jackson Json, Spring binding, etc. Yes it's possible with configurations and/or annotations to get around this, but IMO, saving a few lines of code in exchange for non-default behavior isn't a valid trade-off. Adding a dependency on Lom…

Lombock is one of the most valuable enhancements to Java. Without it, it would make Java development not as fun.

Re: Better Java – Resources for Writing Modern Java

#125

Post by benjiweber »

trbvm2 wrote: post #37
vbezhenar wrote: post #24

Earlier quoted context omitted.

Constructors have their problems. First: constructor calling is not readable because Java misses named parameters. It's fine when there are 2-3 dependencies, but not more. Second: circular dependency is not possible. So I prefer to use setter dependencies, as they don't have those problems.

I agree on the first. I'm only advocating for keeping the constructor as the DI entry point. A DI framework can then be used for the convenience they provide in wiring things up at main. Regarding the second: I think circular dependencies should be avoided whenever possible so I view the difficulty constructors create there as advantage rather than a problem. https://en.wikipedia.org/wiki/Circular_dependency#Problems…

By using a DI framework to wire up constructors you tend to use the compile-time checking that your app is wired correctly. Which is unfortunate. You only find out when you try to run it.

Perhaps things being too big to wire together manually is a smell that the application is getting rather large.

There are also other patterns that can be used to make manual dependency injection less of a pain. I wrote about some of them here

http://benjiweber.co.uk/blog/2014/09/13/frameworkless-depend...

Re: Better Java – Resources for Writing Modern Java

#126

Post by Peaker »

asveikau wrote: post #113
harryh wrote: post #39

Earlier quoted context omitted.

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.

An Optional type is more clumsy than null checks and null returns sprinkled everywhere??

Re: Better Java – Resources for Writing Modern Java

#127

Post by Peaker »

agumonkey wrote: post #44
harryh wrote: post #39

Earlier quoted context omitted.

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

In other paradigms (Lisps) null is a lot less than a billion dollar mistake, it seems it goes better with map/filter/fmap patterns. In imperative languages, data is tied to control, and null means segfault.

When some ELisp code crashes in my emacs with an error like:

  error: (stringp nil): not a string
I think it indicates Lisps suffer from this problem too...

Re: Better Java – Resources for Writing Modern Java

#128

Post by Peaker »

kilink wrote: post #28
kodablah wrote: post #3

"If you're using Java 8, you can use the excellent new Optional type. If a value may or may not be present, wrap it in an Optional class like this" While I agree with most things, overuse of Optional like this is an antipattern IMO. Having done a lot of Java 8 development, I find Optional is best for return types, but otherwise forcing callers to wrap values in Optional is unnecessary as opposed to something like Sca…

I'm also not a fan of passing Optionals into methods. Most of the time it's easier and cleaner just to write an additional method without that optional parameter.

It can grow cartesian though.

I think the best compromise is to declare a new data type for the argument, such as:

  data ExecutionDirectory = ExecuteInCWD | ExecuteInDir FilePath
And take an ExecutionDirectory instead of a `Maybe FilePath`.

Of course, you need light-weight data declarations for that.

Re: Better Java – Resources for Writing Modern Java

#129

Post by Joeri »

thejosh wrote: post #50
nobleach wrote: post #38

After working at two companies filled with Java devs, I don't think any of them will read this article. I can't speak for all Java devs obviously, but it seems unless the dev is a polyglot, they are just fine living in their Spring/SVN/J2EE/Java5 world. They have no idea what's going on in the software development world. I get so excited whenever I hear any of them mention Clojure or even Scala! They just live with t…

This is also how I feel with PHP Developers who work in development agencies or larger companies, either in a small team or by themselves (probably even larger teams, but no first hand experience with that). Basically they refuse to use version control (FTP their code to the live server), use a terrible dev system, non-existent or terrible staging environments or newer technologies such as composer or other tools whi…

On the flip side, the best practice for both Java and PHP is trending towards the same thing. Routes + DI + immutable types + fluent api's. Give it another decade and the only way to tell the difference will be the presence of $ characters.

Re: Better Java – Resources for Writing Modern Java

#130

Post by Peaker »

nobleach wrote: post #80
habosa wrote: post #77

Earlier quoted context omitted.

That's a shame. Java is my favorite language because it has the right balance of strictness (although Go is starting to take over for me). When written correctly, Java can be amazingly productive because you learn so much at compile time but the tools (IDEs) make it so that you can autocomplete away most of the verbosity.

Java as a language is totally fine! It has everything one might need. The culture totally sucks. Oracle leads the march toward what is the "standard". Jersey is a great leap out of this.

Java lacks higher-kinded parametric polymorphism.

Java also lacks the ability to say something like:

  class Foo implements ISerializable iff T implements ISerializable
So you end up having to work only with T's that are serializable, or not having the instance for Foo.

Also, Java lacks type-classes.

Java also lacks lazy bindings, and many other useful features one might need.

In short, Java is still very far from having everything one might need...

Post reply on HN