Lombok makes Java cool again • Hacker News Board

Re: Lombok makes Java cool again

#101

Post by Terr_ » Fri, Feb 01, 2019, 1:41 AM UTC

Felz wrote: post #9

LeanderK wrote: post #2

I think java made some wrong decision, with bigggest one being very pragmatics generics-addition, resulting in trouble down the road like List not being possible. But I don't think checked exceptions are one of them ;) I don't like too much flexibility in a language that has strong types. If you undermine the type-system, why not code in python? But some additions of Lombok seem worthwile.

The problem with checked exceptions is that they constrain implementations by what possible failure states they could have. I.E. the implementations of an interface with a method in it that declares no exceptions will either never call anything that could throw a checked exception, it will internally handle its checked exceptions, or it will wrap them in an unchecked exception. In practice, the first is a straitjacke…

Try reading this aloud: "The problem with return-types is that they constrain implementations by what possible success states they could have."

Checked exceptions are (for the most part) the mirror image of checked returns! Both describe and circumscribe your expectations for what comes back from the method, the only difference is one is happier than the other.

They follow the same kinds of type-rules, and the real problem is entirely on the human end: It's harder to imagine failure scenarios, features are prioritized over error-handling, and people don't like to do it if they can avoid it somehow.

> What would've made them good would be a static analysis of some sort that could divine all possible exceptions thrown by a method call and its dependents based on its code

Again, ask yourself "why don't we already do this but with return types?" Probably because it's horribly impractical in most cases and and outright impossible in others. For example, when it comes to interfaces, abstract-methods, or overridden methods... All of those involves concrete implementations that haven't been made yet.

Heck, they might not get created until months or years after you ship your .class files. Then some random guy you've never met says: "Oh, hey, I can fix my problem by creating my own implementation based on their interface..."

So unless your compiler can literally see into the future, you've got to set down your type-expectations first.

> but in Java a class can always override another class

No, even if all classes were marked "final", you'd have the same problem when it comes to using interfaces.

Re: Lombok makes Java cool again

#102

Post by mattnewport » Fri, Feb 01, 2019, 1:43 AM UTC

barrkel wrote: post #94

mattnewport wrote: post #63

Earlier quoted context omitted.

Most of them to be honest :) Some languages do at least one thing particularly well, setting the standard in that regard. Some introduce or popularize new concepts that slowly see adoption elsewhere. Several make you think about programming in a different way. Some just have an overall elegance, unity, consistency or simplicity of design that make the whole greater than the sum of the parts. Languages that check at l…

Java popularised GC. GC wasn't taken seriously as an option for high performance code before Java, and it altered the mindset of the majority of programmers globally. Java's biggest mistake IMO is checked exceptions. Java is more notable for the things it left out than what it added. It was designed for success and achieved more than most of the languages you list. I don't love Java. However there are many cases in w…

I'd argue that GC still isn't taken seriously as an option for high performance code by people who actually write high performance code and Java is not the language of choice when performance is a primary goal. The lack of value types hurts it there even compared to other similar GC languages like C#.

Re: Lombok makes Java cool again

#103

Post by fogetti » Fri, Feb 01, 2019, 1:45 AM UTC

zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

I am sorry to disagree but if you think that the iterator or visitor pattern or the state pattern or abstract factories are only bound to Java than you have a very low skills/understanding of those patterns and you really don't understand their importance and/or applicability.

Re: Lombok makes Java cool again

#104

Post by twblalock » Fri, Feb 01, 2019, 1:49 AM UTC

bobthepanda wrote: post #61

twblalock wrote: post #17

Earlier quoted context omitted.

The @Builder annotation has some odd behavior if you want to add default values (it just hardcodes them and you cannot override them!) or extra builder methods. Actually, anything involving default values seems to be very brittle and difficult to work with -- especially when deserializing objects from JSON. The @Wither annotation results in methods that do not always make a copy, and sometimes use == instead of .equa…

IIRC @Builder.Default only makes them immutable if you also specify that the variable is final.

Yeah, but what if I want to build an object with @Value on it, which makes all variables final, and I want to specify a default value to be used only if the user does not provide one to the builder? That's not possible.

A builder is just a fancy alternative to a constructor. It is possible to set the value of a final field in a constructor, and it is also possible to have another constructor in the same object that sets a default value for that field. I expect the same flexibility from a builder.

For example:

  public class Person {
      private final String name;

      public Person(String name) {
          this.name = name;
      }

      public Person() {
          this("Bob");
      }
  }

Now you can get immutable Person objects:

  Person p1 = new Person();
  Person p2 = new Person("some other name");

But if you do this with Lombok:

  @Value
  @Builder
  public class Person {
      @Builder.Default("Bob")
      private String name;
  }

You cannot do this:

  Person p = Person.builder().name("Some other name").build();

The name is stuck at the Builder.Default value. In that sense it is not a default, rather it is the only possible value. A default is supposed to be something that can be overridden.

I could use @Data instead of @Value but then the resulting Person objects would be mutable which I don't want.

Re: Lombok makes Java cool again

#105

Post by chii » Fri, Feb 01, 2019, 1:54 AM UTC

zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

> all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers.

i would think javascript is the language with which the mistakes wasted the millions in man hours, not java.

Re: Lombok makes Java cool again

#106

Post by stevehiehn » Fri, Feb 01, 2019, 1:57 AM UTC

Not sure I agree with the claim considering Lomboks been around for quite a long time.

Re: Lombok makes Java cool again

#107

Post by chii » Fri, Feb 01, 2019, 1:58 AM UTC

Tharkun wrote: post #51

mohaine wrote: post #12

My main issue with Java is all the annotation based programming. Some of these are nice and can make the easy case super easy but if you need go even slightly off the easy path you seem to quickly loose all the time gained on the easy path. i.e. @GET(url=" http://host/users/$userid" ) public abstract User getUser(String userid) isn't that much easier than the python requests version but much harder if you need to add…

> My main issue with Java is all the annotation based programming. That seems like an easy problem to solve. Don't use annotations. Snark aside, it can be a bit of a tricky balancing act. When there are more annotations than actual code, that's a code smell in my book and something needs to change. Separating concerns usually does the trick. I'm heavy on code generation, so anything that's boring enough to benefit fr…

why differentiate annotation from non-annotation code? they are both code, and they are both lines you have to maintain/debug.

Re: Lombok makes Java cool again

#108

Post by kodablah » Fri, Feb 01, 2019, 2:00 AM UTC

rufugee wrote: post #96

kodablah wrote: post #7

Earlier quoted context omitted.

> auto generate sensible [...] 'hashCode' methods Unless you're using arrays. They went with "predictable" over "sensible" here. > is flawless from my experience As a heavy Kotlin user, I'd say it's far from flawless (not sure if you mean interop or the entirety of the language, but applies to both). I'm often creating and starring YouTrack issues. But yes, it's still a highly recommended alternative to Java.

As someone considering using Kotlin for my next project, your comment is interesting. Care to share what flaws you've uncovered?

Assuming it's for the JVM, you should definitely choose Kotlin for your next project. Most of the flaws I find are for advanced usage (e.g. interop, coroutines, etc) or tooling (e.g. gradle issues, dokka) or just general advanced language use. I don't keep a running list of issues (I made one back in the day [0] but not all of it is still applicable), but nothing would keep me away from the language. It made a lot of right decisions.

0 - https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db11...

Re: Lombok makes Java cool again

#109

Post by jcrites » Fri, Feb 01, 2019, 2:03 AM UTC

zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

The remark about design patterns is not accurate. Design patterns did not originate with Java and aren't specific to that language. The classic book "Design Patterns: Elements of Reusable Object-Oriented Software", by the 'Gang of Four', was written in and about C++. It was published in 1994 and predates Java.

"Design Patterns", both as a book and a concept, is about the recurring patterns found in object-oriented software; it is about the problems that lead to those patterns, and the solutions to them. Although the book itself is rather dated, the patterns described in it remain relevant to most modern languages. Some of those patterns include: Builder, Singleton, Proxy, Decorator, Iterator, Visitor, Prototype (c.f. JavaScript prototypes), Observer, Chain of Responsibility, and more.

Many languages employ these patterns in the design of their standard library. E.g. the Iterator pattern shows up in a large number of language libraries (Python, Ruby, JavaScript, Swift, Rust).

If you search for "Design Patterns in X", for programming language X, you can find quite a lot of literature about how to employ them in any language. For example, see "Python 3 Patterns, Recipes and Idioms" [1], which describes how to employ many design patterns in Python, or "Design Patterns in Ruby" [2]. A lot of modern literature for many programming languages relies on these patterns either implicitly or explicitly.

Most of these patterns do not exist because of language weaknesses, although I would agree that this is true for some of them, such as the Visitor Pattern. Use of the Visitor Pattern is often better replaced with pattern matching in programming languages that have it. However, this isn't true for all of the patterns (e.g. Chain of Responsibility, Facade, Proxy); and even the Visitor Pattern remains relevant to many languages, especially dynamic languages that do not support pattern matching.

Many of these structural concepts were not new, in the sense that they did not originate with the book; but the GoF took the time to assign names, characterize them, and describe the trade-offs involved in using them.

[1] https://python-3-patterns-idioms-test.readthedocs.io/en/late... [2] https://bogdanvlviv.com/posts/ruby/patterns/design-patterns-...

Re: Lombok makes Java cool again

#110

Post by jayd16 » Fri, Feb 01, 2019, 2:10 AM UTC

joneholland wrote: post #42

jayd16 wrote: post #29

Earlier quoted context omitted.

>custom dynamic header Its just: @RequestHeader("Header") added to the param list.

How do you add that dynamically?

What do you mean? Like, look for any header? You can just grab them all from the request context.

>@Context HttpHeaders headers

I'm not sure if there's some kind of regex support or anything like that. Looping through the headers seems simple enough.