Live data from Hacker News

Java 9 features announced

jaxenter.com

151–160 of 228 posts

Re: Java 9 features announced

#151
post #125

Earlier quoted context omitted.

Well, the answer depends on the function, the purpose. I suppose he's saying that you should encapsulate with the object. For example, you have an OrderLine object, you don't `o.setStatus(CANCELLED)`, you `o.cancel()` etc.

That examples makes sense, but what about Strings and other types? I'm not sure you can do the same thing for a User object with name, age etc. I'd love to not have getters/setters but I have yet to see a replacement for all get/set scenarios.

The parent would have the `User` type as a value type, with read-only final fields.

Re: Java 9 features announced

#152
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?

The problem with getters and setters is that the code for them is nearly identical, yet they have to be written in nearly every single class:

  // Sorry if there are any mistakes, I have not
  // written any Java code for quite some time.
  public class Point
  {
    private int x;
    private int y;
    .
    .
    public int getX()
    {
      return x;
    }

    public int getY()
    {
      return y;
    }

    public void setX(int newX)
    {
      x = newX;
    }

    public void setY(int newY)
    {
      y = newY;
    }
  }
Look at how long the class definition is for something so basic!

In Common Lisp there are two ways to define classes/structures, defstruct and defclass. Defstruct[0] automatically automatically defines everything for you:

  (defstruct point  x y)
will define the procedures make-point, point-x, point-y, (setf point-x), and (setf point-y). The cool thing is that they are all procedures. It easily change the class definition without changing the code that uses it. There are also some additional options for defstruct to specify default values, how to print the structure, as well as what prefix to use (the default is the name of the structure, 'point' in this case).

Defclass[1], while much more verbose than defstruct, is much more powerful:

  (defclass point ()
    (x :writer set-x :initarg :x)
    (y :reader get-y :initarg :y)
    (z :accessor z))
will define procedures, set-x, get-y, z, and (setf z). Set-x and (setf z) are the setters, while get-x and z are the getters. To construct a point that is defined this way, one has to use the procedure make-instance which will take keyword parameters[2] :x and :y, for x and y respectively.

  [0] http://www.lispworks.com/documentation/lw445/CLHS/Body/m_defstr.htm
  [1] http://clhs.lisp.se/Body/m_defcla.htm
  [2] http://www.gigamonkeys.com/book/functions.html

Re: Java 9 features announced

#153
post #82

Earlier quoted context omitted.

Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?

IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g: class Rectangle { num left, top, width, height, right bottom; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…

Amusingly, your Dart solution is exactly what Groovy does, which is where this whole thread started.

Re: Java 9 features announced

#154
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

Why not just declaring the fields public and access them directly? Is there anything I am missing?

What if you only want a getter? The `final` keyword is too restrictive.

Also, it breaks encapsulation, because your internal storage should be changeable without ruining your external surface area.

Re: Java 9 features announced

#155

> improved support for multi-gigabyte heaps I've heard this thrown around before, but what this actually mean? Is it just some optimizations to the garbage collector?

Work on G1 GC. Now it can deal better with humongous regions (can collect them in mixed cycles, not just at the end of a slow and expensive full marking cycle), had a lot of fine tuning work done, and all in all, it seems to me that Oracle allocated/allowed/encouraged JVM GC developers to participate on the hotspot mailing list. ( http://mail.openjdk.java.net/pipermail/hotspot-gc-use/ )

And see also: https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JD...

Re: Java 9 features announced

#156
post #145

Earlier quoted context omitted.

Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested. For example, with protocol buffers you end up doing things like. AlbumCollection collection = user.getPreferences().getFavorites().getAlbums().toBuilder().addAlbum(album).build(); Favorites favorites = user.getPrefernces().getFavorties().toBuilder().setAlbumCollection(collection).build(); Pref…

This seems like a perfect example of a pattern applied in the wrong way. The builder pattern is supposed to be used to construct new instances (in other languages named parameters make it pretty redundant). I could perhaps understand allowing people to batch up changes but when you're forced to switch to a builder and back again to make a change to one field you've definitely got a poor design. The example seems part…

His example is creating new instances. It just happens to be creating them from existing instances. Basically a clone and change kind of operation.

You are right that normally you'd want the addFavourite method but in his example he is dealing with generated code which has a tendency towards verbosity.

You could add the method if Java allowed extension methods...

Re: Java 9 features announced

#157

Earlier quoted context omitted.

> Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. Others have noted that in many contexts in C# there is a difference, so clients do need to know. As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal ca…

> Others have noted that in many contexts in C# there is a difference, so clients do need to know. Which is why C# added automatic properties. You get the expandability without breaking clients or having to read/write extra code. public int Foo { get; set; }

Which becomes even more useful over a field when you can do:

    public int Foo { get; private set; }

Re: Java 9 features announced

#158

Earlier quoted context omitted.

It seems that it is almost in prototyping stage, the usual suspects have already written a sketch of a future proposal: http://cr.openjdk.java.net/~jrose/values/values.html

Awesome! Thanks. I don't know much about the path from idea to standardized feature with the JVM. Is there hope for it in Java 9 or is this much farther out in the future? Probably first and more importantly, what is the chance for this even ever happening?

"the path from idea to standardized feature" Guy Steele was asking for value types in 1998 (http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)

Re: Java 9 features announced

#159
post #2

The lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.

Amen to that, brother. JSON is a huge pain point for Java. No wonder so many Java folks keep defending XML--at least it's malleable in their home language.

Re: Java 9 features announced

#160

Earlier quoted context omitted.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients ne…

Python has a solution to this. There are decorators that allow you to access methods as if they are properties:

    class Foo(object):
        def __init__(self, bar):
            self._bar = bar

        @property
        def bar(self):
            return self._bar

        @bar.setter
        def bar(self, value):
            self._bar = value
Post reply on HN