Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JDK 9 release schedule

mail.openjdk.java.net

Post reply on HN
Print view View original

91–100 of 161 posts

Re: JDK 9 release schedule

#91

Post by usrusr »

erl wrote: post #15
geodel wrote: post #5

Earlier quoted context omitted.

Here is the list: http://openjdk.java.net/projects/jdk9/

I appreciate changes that make it easier to monitor and debug applications. Looking forward to some small goodies that I haven't heard much about before: http://openjdk.java.net/jeps/228 - Add More Diagnostic Commands. For example more insight into JIT:ed methods and the code cache. http://openjdk.java.net/jeps/158 - Unified JVM Logging. Logging from the JVM, e.g. GC logging and classloader logging, are configured an…

> http://openjdk.java.net/jeps/259 - Stack-Walking API. Efficient API for walking the current call stack.

Oh, nice! At any given moment in time, how many server CPUs are burning cycles to create a full StackTraceElement array, just because the logger is set up to provide the convenience of call site information with every write?

Re: JDK 9 release schedule

#92

Post by breischl »

fauigerzigerk wrote: post #81
breischl wrote: post #75

Earlier quoted context omitted.

I would argue that the distinction is actually a good thing. If you're working with a reasonably well-designed library, then the fact that something is a method instead of a property tells you it might be doing some serious (or just slow) work. Whereas in Java calling getX() might do just about anything. And if the implementation of a C# property changes in any of the ways that would make it a method, that probably d…

The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me. And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle…

I think disguising a simple function call as a variable access is sensible. But yes, people can disagree on this. I think the C# and Java designers are probably all smart people who thought about this a lot more than the two of us. :)

>>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?

I just quickly re-read that page, but I don't see what you're referring to here.

Re: JDK 9 release schedule

#93

Post by st3v3r »

lacampbell wrote: post #82
chrisseaton wrote: post #78

Earlier quoted context omitted.

What would a high level message for changing the name of some object look like, if not setName(newName)?

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…

Let's say I have an object representing a file in the file system, and I'm writing a file browser. I give the user the ability to rename the file.

Re: JDK 9 release schedule

#94

Post by st3v3r »

djsumdog wrote: post #62
dmux wrote: post #47

Earlier quoted context omitted.

Are people manually writing getters and setters? Every Java IDE I've used has the ability to generate them for you.

Code generation is a design smell. You shouldn't need it, and it makes the code terrible and less readable. Use Lombok, not the IDE.

"Code generation is a design smell."

What do you think Lombok is doing?

Re: JDK 9 release schedule

#95

Post by usrusr »

jjoonathan wrote: post #43
pjmlp wrote: post #32

Earlier quoted context omitted.

> Scala, Groovy, Clojure, JRuby, etc. I am yet to work in a Java project where I am allowed to use any of them. Regarding the properties I really don't get what is the big deal. No one used to complain about C++ properties, that besides having to write accessors and mutator methods, one needs to declare them on the header files as well. Or the first version of C# properties isn't much shorter than how it is done in J…

> isn't much shorter than how it is done in java The savings in screen space and visual cortex neurons doesn't come from the one or two properties that need logic, it comes from the dozen avoided /** * Gets the foo * @return the foo */ public Foo getFoo() { return foo; } /** * Sets the foo * @param foo */ public void setFoo(final Foo foo) { this.foo = foo; }

A compiler switch that makes trivial comments on accessor methods a compile error, now that would be something I could support!

Re: JDK 9 release schedule

#96

Post by nine_k »

agentgt wrote: post #84
djsumdog wrote: post #62

Earlier quoted context omitted.

Code generation is a design smell. You shouldn't need it, and it makes the code terrible and less readable. Use Lombok, not the IDE.

When I see some one complaining code generation being design smell I gag a little at this hackneyed Fowler expression. I'm curios what do you think lambok does?

It does code generation. What id does not is _source_ code generation. That is, you never see the code Lombok generates, never have to maintain it, and never have a chance to break it by editing. You can see it as a macro substitution.

OTOH IDE-generated code is "normal" source code, adding boilerplate to your "real" code, not tracking changes in it automatically, and perfectly breakable.

Re: JDK 9 release schedule

#97

Post by st3v3r »

pjmlp wrote: post #29
michaelt wrote: post #25

Earlier quoted context omitted.

The vast majority of projects, at my employer. I personally upgraded several hundred JVMs running several dozen services - upgrading was simple and almost entirely painless. In addition to benefiting from the new features, being up-to-date is good for recruiting. You tell someone they'll be working with Java 6 and (in the absence of other evidence) they'll assume it's a legacy product suffering from chronic under-inv…

> they'll assume it's a legacy product suffering from chronic under-investment. Or Android.

Presumably they'd know that they applied for an Android job.

Re: JDK 9 release schedule

#98

Post by lacampbell »

st3v3r wrote: post #93
lacampbell wrote: post #82

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…

Let's say I have an object representing a file in the file system, and I'm writing a file browser. I give the user the ability to rename the file.

I would say that at that point, it ceases to be a simple setter method (or set property). It's not a simple case of mutating some element of a data structure of filenames as strings. There'd be some validation and error handling involved. It's a perfectly valid high level message to send a file object.

As an aside, I'd probably make a method called "rename" that does this, as opposed to something like "setName".

Re: JDK 9 release schedule

#99

Post by clusmore »

lacampbell wrote: post #58
djsumdog wrote: post #26

Earlier quoted context omitted.

Am I missing properties? Dear god it's 2016, with Java8, and we still don't have real, language-defined properties? I mean you can use Lombok (and if you're not, you should be!), but that's something that really need to be built into the language. C# has them, Python has them, Ruby has them .. even other JVM languages like Scala have them! I'm really glad I get to do Scala development full time. Even with all the rec…

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;
  }

Re: JDK 9 release schedule

#100

Post by smoyer »

merb wrote: post #8
jwn wrote: post #4

Earlier quoted context omitted.

Looking at http://openjdk.java.net/projects/valhalla/ , I don't see a whole lot of value compared to JDK9. What's your basis for wanting 10 so badly?

well as others already pointed out, value types. this changes the way how the JVM uses Memory in certain ways and might be a huge improvement for a lot of stuff. specialized generics. this is a huge one, too, less boxing is always a win. JEP-286 less typing. Maybe Project Panama and maybe a even better AOT. Compared to what JDK 9 brings, this is huge. JDK 9 brings a Module system which was already possible (and a lot…

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) {
    ...
  }
Post reply on HN