Live data from Hacker News

Better Java – Resources for Writing Modern Java

github.com

151–160 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#151
post #98

Earlier quoted context omitted.

When I get some time I'll update the OGMJ. I think the choice of tools mentioned is still very much up-to-date, it's just that some of the APIs used in the examples have been upgraded.

I really like OGMJ, it's definitely a great resource and I recommend it to many new Java developers; however, I disagree re: tools mentioned. After trying dropwizard for a few projects, the superiority of the spring-boot and its various ecosystems just blew me away. Also, while I appreciated Gradle, Maven is just much more supported through the entire eco-system. As a new comer to Java from C++/Python, it made a big…

> Maven is just much more supported through the entire eco-system

Could you give some examples? I haven't had much problem with Gradle support, and Gradle's essential advantages over Maven fat outweigh what little I have had.

Re: Better Java – Resources for Writing Modern Java

#152
post #133
post #61

95% agree with these opinions, but have a few disagreements, or perhaps the author had missed some great stuff. Two main ones: Mockito is, IMHO, much nicer than jMock. And Immutability is good, but 'final' is... complicated. I find it's often over used by people who don't know why they're using it.

jMock isn't great, but Mockito makes it too hard to understand which method you haven't stubbed; I find EasyMock with its explicit replay() step much easier.

I rather like Moxie for mocking:

https://github.com/pobrelkey/moxiemocks

Re: Better Java – Resources for Writing Modern Java

#153
post #142

Earlier quoted context omitted.

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

Lombok is also a non-standard dependency and there are costs with having to rely on it.

If the cost overweights the benefit you can delombok everything will works as before.

Re: Better Java – Resources for Writing Modern Java

#154

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…

This is great, thanks. I've also used something like this: https://gist.github.com/dwijnand/3741951

Re: Better Java – Resources for Writing Modern Java

#155
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.

I consider Jersey to be a good example of what is wrong with Java. Annotation driven APIs don't really lend themselves to composability - sparkframework, vertx or ratpack are much better ways of building REST apis with Java 8.

Re: Better Java – Resources for Writing Modern Java

#157
post #140

Earlier quoted context omitted.

You have won at the internet. I'm sure you're a joy to be around. I haven't seen the meaningful response that you've added. You really do seem like a troll. If that's not your intention, that's cool. If it is, well, hey, happy trolling dude! Edit* Yep, just checked your comment history, you're a troll. God why do people like you exist.....

Personal attacks are not allowed on Hacker News. Regardless of whether you think someone is trolling, a comment like this makes the thread obviously worse. Please don't.

Agreed, may I edit or delete this response?

Re: Better Java – Resources for Writing Modern Java

#158
post #140

Earlier quoted context omitted.

Personal attacks are not allowed on Hacker News. Regardless of whether you think someone is trolling, a comment like this makes the thread obviously worse. Please don't.

Agreed, may I edit or delete this response?

While you're reviewing these, you should probably take a look at your original post which got you in this thread of poo-flinging to begin with. It doesn't address the article at all. It just says 'grumble grumble, those Java people!'. It's content-free flame bait that produced predictable responses such as 'And those PHP people!' and 'I'm a Java person and you, Sir, are an ass'.

Re: Better Java – Resources for Writing Modern Java

#159
post #131

Earlier quoted context omitted.

Java was designed for TV set-top boxes, but that doesn't mean it's bad to use it on a server. If using a default method in an unintended way leads to clearer, more maintainable code, do it.

how would it lead to more clearer code? You would have many interfaces referencing an instance variable, each with different semantics for that variable. Interfaces cant have variables so they should not be used as traits.

One good use case I can see is where you want to add convenience "helper" methods to an interface that can reasonably have default implementations in terms of some other method on the interface (E.g. overloads to emulate default parameters). Or for methods that can be implemented in terms of another method, but might have a more performant direct implementation (e.g. Collection#get can be defined in terms of iteration).

I don't quite understand your point about instance variables. Instance variables are and should be encapsulated. An object that implements multiple interfaces must of course provide the correct semantics for all of them. But that's true whether an interface contains method implementations or not.

Re: Better Java – Resources for Writing Modern Java

#160
post #158

Earlier quoted context omitted.

Agreed, may I edit or delete this response?

While you're reviewing these, you should probably take a look at your original post which got you in this thread of poo-flinging to begin with. It doesn't address the article at all. It just says 'grumble grumble, those Java people!'. It's content-free flame bait that produced predictable responses such as 'And those PHP people!' and 'I'm a Java person and you, Sir, are an ass'.

But this is the point. Now you've felt the need to teach a lesson... which also has nothing valuable to add. I feel like any conversation on Java or newer Java does lend itself to my point. If we can't add any personal experiences to these stories, then why do we have a comments section? I know it's not just so we can post links to other facts. And no, I'm not stuck in this thread. I'm trying to do the fair thing and remove a response to a personal attack and name-calling (which was mine). I stand by my initial statement. I work in an environment where a ton of Java devs don't understand why the pesky front end people keep asking for these RESTful JSON APIs. "Why can't we just do some JSPs and give you an XML/XHR when you need a hint of dynamic-ness?"

This is what brings on personal attacks. The attitude in which you post. If you fail to see my original point, ask for clarification. It would have caused me to edit my original and change my tone.

Post reply on HN