Live data from Hacker News

JDK 9 release schedule

mail.openjdk.java.net

111–120 of 161 posts

Re: JDK 9 release schedule

#111
post #100

Earlier quoted context omitted.

If you want less typing, then you definitely want Lombok ( https://projectlombok.org/ ). At JavaOne this year, they also showed a proposed shortcut for data object (@Data in Lombok). public class something(String name, int age) { ... }

I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?

That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain.

Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like:

  @Data
  public class something {
    String name;
    int age;
  }
Lombok generates:

  public String getName() { ... }
  public void setName(String name) { ... }
  public int getAge() { ... }
  public void setAge(int age) { ... }
  public boolean equals(Something other) { ... }
  public int hashcode() { ... }
  public String toString() { ... }

Re: JDK 9 release schedule

#112

Earlier quoted context omitted.

I really don't understand why people love properties so much. Getters and setters are elements of bad style to me - like global variables or gotos. A language like Java (or indeed C#) - specifically designed for huge teams and enterprise programs - shouldn't provide syntax sugar for writing getters and setters.

I agree that setter properties are often a code smell, but getter properties are nice for calculated fields. As a very simple example, consider the following (C#): class Circle { public Circle(int radius) { Radius = radius; } public int Radius { get; } public int Diameter => Radius * 2; }

Diameter is a nice example of a getter property. However you could change radius to simply

    public int Radius;

Re: JDK 9 release schedule

#113
post #100

Earlier quoted context omitted.

If you want less typing, then you definitely want Lombok ( https://projectlombok.org/ ). At JavaOne this year, they also showed a proposed shortcut for data object (@Data in Lombok). public class something(String name, int age) { ... }

I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?

I believe a similar argument could be made against using any 3rd party library. At some point who ever is maintaining your code will have to understand its dependencies at some level.

For lombok specifically, other languages have these types of features built in which of course people need to learn in order to use it.

I agree it isn't a perfect solution, but java is in dire need of boilerplate reduction features like this and lombok fills this need well.

Re: JDK 9 release schedule

#114
post #109

Earlier quoted context omitted.

"Calls to mutate state, such as changing the name field, should be rare." Says who? For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse. It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers. So, the quantity of the item keeps mutating. How do you propose to deal with the above? Tell the warehouse people that…

a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.

> a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.

Yeah I want to say that for us developers, "rare" is not something that we can code, without some serious sophistication.

More likely we code "if" and it is either "yes" or no".

To capture "rare", we need some serious tools - statistics, analytics etc etc. That is way beyond the regular developer toolset.

Re: JDK 9 release schedule

#115
post #111

Earlier quoted context omitted.

I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?

That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain. Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like: @Data public class something { String name; int age; } Lombok generate…

The real win is when you do Effective Java chapter 1 immutable objects with @Builder. I worked at a Big Dumb corp that eschewed lombok, and required full test coverage of getter, setters, builders, toString, equals, and hash mehtods, and 100% javadoc coverage for all methods (even private methods). It was insanity, and carpal tunnel inducing. Lombok would have reduced the workload by 90%.

Re: JDK 9 release schedule

#116
Been coding Java for close to 20 years. Can anyone show me what's being done in the language to bring on newcomers, or did that ship sail 10-15 years ago?

Some ideas that would bring people back:

* Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named.

* Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.

* Similarly be able to generate the JavaScript front-end code that use those JS client libraries with easily writable/pluggable generators so that it can generate Angular 1.x, 2, ReactJS, Bootstrap, etc. in "best-practice" ways that can be updated frequently as the community changes.

* Simultaneously provide the option to serve very similar pages using straight HTML, degrading even to the point that a text only browser could use the site easily.

* Easily define responsiveness of pages.

* Support multiple 3D, 4D, etc. interfaces with customizable inputs to be forward-compatible without overdoing complexity (i.e. it's really pluggable).

* Similarly support generation of almost any kind of service integration, with easy pluggable authN/R.

* Easily scalable.

* Relational, noSQL, versioning DB (noms) support.

* Make fun books for kids and a site where they can share what they've written, write games, build things, etc.

* Make it integrate with every browser, even some older versions, operating systems.

* Make it compile low-level vs. byte code so it's fast as shit.

Re: JDK 9 release schedule

#117

Earlier quoted context omitted.

It would probably look exactly like setName(newName). For me a better question is - why is the name being changed? What high level goal are you trying to accomplish that truly needs you to to directly mutate internal fields, after the object has already been created? Could the object - or system of objects - have been designed with a higher level interface, so that the outside world didn't have to concern itself with…

Things change? Consider a trivial to-do list. You can click on the 'completed' checkbox. So the 'completed' field has chaged. Or, you can say ooops I mistyped the label. So you change the label. Is there anything wrong with that?

I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects.

I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".

Re: JDK 9 release schedule

#118

Been coding Java for close to 20 years. Can anyone show me what's being done in the language to bring on newcomers, or did that ship sail 10-15 years ago? Some ideas that would bring people back: * Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named. * Easily write and design interfaces that generate both/either back-end or matching integrated front-end cod…

Thanks for the bullets. This is a good list but some of the points like "Easily scalable" and "DB support" are not cheaply available in any runtime and require careful attention to detail as well as domain-specific thinking. IMHO, the JVM already does a lot of heavy-lifting in this regard.

Re: JDK 9 release schedule

#119
post #111

Earlier quoted context omitted.

That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain. Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like: @Data public class something { String name; int age; } Lombok generate…

The real win is when you do Effective Java chapter 1 immutable objects with @Builder. I worked at a Big Dumb corp that eschewed lombok, and required full test coverage of getter, setters, builders, toString, equals, and hash mehtods, and 100% javadoc coverage for all methods (even private methods). It was insanity, and carpal tunnel inducing. Lombok would have reduced the workload by 90%.

Yes! ... And there are a lot of stages between a fully immutable object @Value and @Data (described above). The @Builder is so much better than most but you can also easily create a POJO with a portion of its fields immutable too (a combination of @NonNull, @Getter, @Setter and @RequiredArgsConstructor).

Re: JDK 9 release schedule

#120

Earlier quoted context omitted.

Things change? Consider a trivial to-do list. You can click on the 'completed' checkbox. So the 'completed' field has chaged. Or, you can say ooops I mistyped the label. So you change the label. Is there anything wrong with that?

I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects. I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".

> I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects.

I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".

I do not understand your point. First you claim that we should not mutate the field, then you claim that we should mutate the field.

Which one is it? Mutate or not?

Post reply on HN