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

151–160 of 161 posts

Re: JDK 9 release schedule

#151

Post by int_19h »

fauigerzigerk wrote: post #66
int_19h wrote: post #54

Earlier quoted context omitted.

Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?

In Java you can be reasonably sure that whenever you need something from an object you call a method of its class. That's one thing you rarely have to think about in practice. Yes there are exceptions (sometimes painfully inconsistent ones) where fields are accessed directly, but at least that gives you some performance guarantees. It's generally not a big concern. In C# you do have to think about it all the time. Mo…

There's no actual syntactic load in practice. You look at the documentation page (or, more often these days, at autocompletion list), and see all members. Whether they are properties or methods is readily indicated, and in case of autocompletion, it'll also insert the parentheses for you for methods.

Semantically, the difference between properties and methods is the same as the difference between data and behavior. Are you saying that it's not a useful distinction to have?

Re: JDK 9 release schedule

#152

Post by int_19h »

pjmlp wrote: post #63
int_19h wrote: post #53

Earlier quoted context omitted.

The C# version was the same length 10 years ago. Now you would write: public Foo Foo { get; set; } and get the backing field for free.

Now write that with validation on set.

That'll be about as long as Java, sure. But most properties that are actually written in code don't need validation. In fact, most of them don't even have a setter. In C#, this means that I can do:

   public Foo Foo { get; }
or for a computed property:

   public int Foo => Bar + 1;
The real savings from property come when you use them, though - the extra pair of () doesn't feel like much, but when you start chaining properties, I find that not having () there significantly improves readability. Then, of course, Java also insists on `get` prefix by convention. So you have Java:

   foo.getBar().getBaz().blah()
vs C#:

   foo.Bar.Baz.Blah()
More importantly, the latter visually emphasizes the difference between accessing data and operating on it. You can see that "Bar" and "Baz" are data members, conceptually similar to "foo", whereas "blah()" is an operation.

Re: JDK 9 release schedule

#153

Post by dragonwriter »

int_19h wrote: post #57
whateveracct wrote: post #9

Earlier quoted context omitted.

Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore). What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very r…

Aside from backwards compatibility, what's good about type erasure for generics?

It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)

Re: JDK 9 release schedule

#154

Post by parasubvert »

snuxoll wrote: post #149
parasubvert wrote: post #146

Earlier quoted context omitted.

I work for Pivotal so I'm biased. But I'd take a long look at Sprint Boot in terms of "fun , productive , practical" Java: https://projects.spring.io/spring-boot/ In particular: - curated and tested open source library dependencies to the point that you can generate a single JAR for anything you might want to build on the server: http://start.spring.io/ - Annotations and APIs to make REST service development a breeze…

Spring Boot is awesome, thank you guys for your massive contribution. All of my co-workers are .Net guys and keep trying to say that Java is dead now that .Net Core is out, but I still haven't found a server-side solution better than Spring yet :)

Hey thanks ... .NET core is awesome too, they should check out http://www.steeltoe.io/ for our attempt to bring Spring love their way :p

Re: JDK 9 release schedule

#155

Post by snuxoll »

parasubvert wrote: post #154
snuxoll wrote: post #149

Earlier quoted context omitted.

Spring Boot is awesome, thank you guys for your massive contribution. All of my co-workers are .Net guys and keep trying to say that Java is dead now that .Net Core is out, but I still haven't found a server-side solution better than Spring yet :)

Hey thanks ... .NET core is awesome too, they should check out http://www.steeltoe.io/ for our attempt to bring Spring love their way :p

Cool, but much less useful than the full suite of Spring projects (which is why I love Spring in the first place, it's basically batteries included but everything remains modular so I can pick and choose what I want). .Net Core is a great stepping stone, but between deployment headaches (I can just run yum install java-1.8.0-openjdk to get a JVM and run a spring-boot app, .Net Core forces me to bundle the runtime right now) and the lack of a cohesive integrated suite of components keeps my heart with Spring (even if I'm forced to use .Net at work more often than not).

Re: JDK 9 release schedule

#156

Post by ohnoes2016 »

pron wrote: post #130
pjmlp wrote: post #40

Earlier quoted context omitted.

I know, but with the JVM having full support, that might eventually change in Java 11 lets say, after the experience how everything went. Brian did not state they will never do it. Also the other languages could take advantage of it anyway, even a reiffied version of Java for example.

Reified generics for reference types is a really, really bad idea. It solves a minor, itsy-bitsy-tiny problem, but pretty much ruins sharing of data structure among languages, because it bakes a specific variance model into the classes. For value types that's not a problem because they don't support subclassing anyway.

> For value types that's not a problem because they don't support subclassing anyway.

Could you please provide a reference for this? Even a broad one like "a post on the Valhalla mailing list during the past summer" would be very welcome.

I'm eagerly awaiting for this feature and not being able to extend user-defined value types would be a bummer.

Re: JDK 9 release schedule

#157

Post by snuxoll »

pjmlp wrote: post #135
snuxoll wrote: post #129

Earlier quoted context omitted.

Good thing Kotlin already supports reified generics (with the current caveat that they must be used in inline functions), Java the language is less important these days than the JVM having support for the feature.

Java the language is still very important, it is the systems programming language of the JVM. On my .NET projects we get a full installation from Visual Studio on the development machines. Which means C#, F#, C++ and VB.NET available. On my Java projects those machines have usually Eclipse + JDK. JARs are either vendored or make use of an internal Maven server. I am yet to be allowed to use anything other than Java (…

The joys of working for a company with in house developers, as long as I don't use something that would be extremely difficult to bring a new developer up to speed on (accounting for the necessity of said solution as well) I can generally make a case to use whatever.

I've got a mix of C#, Python, Kotlin and pl/pgsql code running in production right now and we've also for projects written in Node.js that are live as well. I've even got some F#!

Re: JDK 9 release schedule

#158

Post by pron »

ohnoes2016 wrote: post #156
pron wrote: post #130

Earlier quoted context omitted.

Reified generics for reference types is a really, really bad idea. It solves a minor, itsy-bitsy-tiny problem, but pretty much ruins sharing of data structure among languages, because it bakes a specific variance model into the classes. For value types that's not a problem because they don't support subclassing anyway.

> For value types that's not a problem because they don't support subclassing anyway. Could you please provide a reference for this? Even a broad one like "a post on the Valhalla mailing list during the past summer" would be very welcome. I'm eagerly awaiting for this feature and not being able to extend user-defined value types would be a bummer.

You'll have to search for a reference (I don't have one off hand), but obviously value types cannot possibly support subclassing. Why is that a bummer? That's how you'd want value types to behave and the only way they can[1] (without introducing explicit pointers and complex typing rules). Also, why would you ever want to subclass value types? It serves no purpose. Value types, however, will be able to implement interfaces, which, also, is exactly what you'd want.

[1]: For example, if B is a subclass of the value type A, what do you think would happen when you store a value of type B in an array of type A?

Re: JDK 9 release schedule

#159

Post by papercrane »

ohnoes2016 wrote: post #156
pron wrote: post #130

Earlier quoted context omitted.

Reified generics for reference types is a really, really bad idea. It solves a minor, itsy-bitsy-tiny problem, but pretty much ruins sharing of data structure among languages, because it bakes a specific variance model into the classes. For value types that's not a problem because they don't support subclassing anyway.

> For value types that's not a problem because they don't support subclassing anyway. Could you please provide a reference for this? Even a broad one like "a post on the Valhalla mailing list during the past summer" would be very welcome. I'm eagerly awaiting for this feature and not being able to extend user-defined value types would be a bummer.

The video I linked to above talks about the restrictions (8m20s) placed on value types:

  * They have no identity.
  * Because they have no identity == comparisons is based on their data.
  * They cannot have super classes or sub classes (they can implement interfaces though.)
  * They are immutable.
  * They cannot be null.
https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3Ar...

Re: JDK 9 release schedule

#160

Post by int_19h »

breischl wrote: post #92
fauigerzigerk wrote: post #81

Earlier quoted context omitted.

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…

I think it's a reference to this:

"The operation is a conversion, such as the Object.ToString method."

But this only pertains to the conversion of the object on which the property is defined. In other words, you should have methods like ToString or AsEnumerable, rather than properties like String or Enumerable, even though other rules would indicate property to be valid (idempotent, fast, no arguments). This rule is just an indication that properties represent conceptual attributes of an object; and the result of a conversion of an object to something else is not an attribute.

Post reply on HN