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

161–170 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#161

Post by pvg »

nobleach wrote: post #160
pvg wrote: post #158

Earlier quoted context omitted.

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…

The point was 'if you don't want to feel embarrassed by things you post in flamethreads and have moderators berate you, don't start flamethreads', that is all.

Take a look at the top comment in the thread for a) an actual substantive criticism of the article b) a link to a much, much better survey article on the same topic.

Re: Better Java – Resources for Writing Modern Java

#162

Post by dang »

nobleach wrote: post #157
dang wrote: 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?

We're always happy to help with that, but can you please email hn@ycombinator.com about it? And thank you for the polite response—I really appreciate it.

Re: Better Java – Resources for Writing Modern Java

#163

Post by GhotiFish »

izzle49 wrote: post #4

Please don't use Java 8's default methods in interface's to do multiple inheritance, and code reuse. Prefering this over 'Util' classes is bad as it is inheritance over composition. The default methods were designed to facilitate easier interface migration

Inheritance over composition. I know what these words mean, but I don't see your meaning.

Also, I don't think that's what default methods are for. The new StreamUtil libraries uses default interfaces. It's not migrating anyone, but the default methods describe intrinsic properties about the classes that inherit the interface. A predicate can be in sequence of another predicate, for example.

Re: Better Java – Resources for Writing Modern Java

#164

Post by harryh »

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.

The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.

Re: Better Java – Resources for Writing Modern Java

#165

Post by harryh »

userbinator wrote: post #95
harryh wrote: post #68

Earlier quoted context omitted.

Given that the Option type has existed in programming languages other than Java for decades I don't think it makes sense to call it a "typical Java" thing. I can see how a C/Asm programmer wouldn't like it though. Very different mindsets. :)

The difference is that other languages which originally had the Option type don't have null, so it's the only option. I meant it's typical of Java to take features from other languages, resulting multiple slightly-different-but-incompatible ways to achieve the same thing.

I certainly agree that Java would be a much better language if NULL could be eliminated completely. Backwards compatibility though...

sigh

Re: Better Java – Resources for Writing Modern Java

#166

Post by tsotha »

>Java 8 has a nice stream and lambda syntax. You could write code like this:

  final List filtered = list.stream()
    .filter(s -> s.startsWith("s"))
    .map(s -> s.toUpperCase())
    .collect(Collectors.toList());
>Instead of this:

  final List filtered = new ArrayList();
  for (String str : list) {
    if (str.startsWith("s") {
      filtered.add(str.toUpperCase());
    }
  }
>This allows you to write more fluent code, which is more readable.

I don't agree. The second snipped is far more readable. This seems like an effort to use lambdas just to be using lambdas.

Not only that, but the non-lambda version is far easier to maintain. When you get exceptions in code that has the form

  this().that().theOther()
it's generally not obvious where the problem is.

Re: Better Java – Resources for Writing Modern Java

#167

Post by cam- »

harryh wrote: post #164
asveikau wrote: post #113

Earlier quoted context omitted.

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

The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.

A NullPointerException is unchecked as well. I would say about 40% of our code is checking for null to avoid NPEs especially with APIs. You have to protect yourself and cannot take nothing for granted.

Re: Better Java – Resources for Writing Modern Java

#168

Post by cam- »

zmmmmm wrote: post #69
vbezhenar wrote: post #26

Earlier quoted context omitted.

Another problem with struct approach is inconsistency. Sometimes you want a computed property and you use non-trivial getter. Sometimes you want to do some work in setter. And then client's code will look terrible: point.x * point.x + point.getY() * point.getY(). There are other problems: binary incompatibility; non-trivial refactoring when I need to introduce a getter or setter. Java really need lightweight property…

The lack of simple property syntax is probably the main reason I keep using Groovy now that Java 8 has arrived. Yes, state is evil. But there are still plenty of situations where you are just schlepping data around and generating thousands of lines of boilerplate to achieve simple data transfer is such a pointless and ugly hack.

For DTOs we don't user mutators. Just public member variables. It is the only way to keep business logic out of them. That being said, I wish Java has some object/struct syntactic sugar like Javascript Object Literals. They are so powerful.

Re: Better Java – Resources for Writing Modern Java

#169

Post by cam- »

lmm wrote: post #133
mabbo wrote: 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.

JMock at least blows up if you don't mock something. Powermock and Mockito will let it pass. It is a shame JMock's API is so wordy.

Re: Better Java – Resources for Writing Modern Java

#170

Post by cam- »

trbvm2 wrote: post #20

Dependency Injection (frameworks) -1 Use constructors. This makes perfectly testable classes and is vastly simpler than encouraging more XML as code. Any proper dependency injection framework should work quite well with regular constructors.

Dependency injection is brilliant for testing. Prior to DI you often has to have two constructors, one for prod, one for testing. DI took that away.
Post reply on HN