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

Java 9 features announced

jaxenter.com

Post reply on HN
Print view View original

221–228 of 228 posts

Re: Java 9 features announced

#221

Post by unclebucknasty »

wtetzner wrote: post #219
unclebucknasty wrote: post #198

Earlier quoted context omitted.

> If you have classes which require constant mutable access to internal state, your design is probably flawed. How do you account for value objects in that statement? Are you saying there should be no such thing?

There's no reason value objects need to be mutable. In fact, they shouldn't be mutable. They're just data. Why would you need to mutate them?

Well, in the strictest since, I suppose a "value object" is technically one that is immutable by definition. So, to your point, I should clarify that here I'm instead speaking more loosely of an object that is chiefly comprised of data elements vs. behaviors.

So, a common use case might be loading data from a DB, changing several fields, then writing updates back to the DB.

Re: Java 9 features announced

#222

Post by Paradigma11 »

rybosome wrote: post #121
necubi wrote: post #35

Earlier quoted context omitted.

This is solved in a more general way in Java 8 via monadic optionals. The basic idea is to wrap your nullable objects in an Optional , which then both forces you to deal with the possibility of the value being absent and gives you good tools for doing so. Your example, with Optional, looks like this: T obj = ...; Optional.of(obj).map(T::some).map(U::other).map(V::methods).getOrElse(null); Not quite as clean syntactic…

This is kind of a pedantic distinction, but the behavior you've described is actually Functor behavior; I think Monads allow for Functor-like behavior as part of their definition (not sure, I'm neither a category theorist nor an experienced Haskeller), but their use is something a little bit different. Monads allow you to do two things: 1) Lift regular values into monadic ones in a generic way. Let's say that we have…

    Monad m1 = Optional.lift("hello");
    Monad m2 = List.lift("hello");
Shouldn't that be

    Option m1 = Optional.lift("hello");
    List m2 = List.lift("hello"); 
?

Re: Java 9 features announced

#223

Post by xpto123 »

suprgeek wrote: post #96

Fix the Modularity business properly! Please simplify and make a standard system that most people can get behind. While Jigsaw started out ambitiously, I attended some of the initial meetings and the scope was....awesome. Then it scaled back to a re-org of the rt.jar to make it easy to run on mobile devices (Ironically we are seeing the full circle - Java started out as a Set-top box language, then graduated to an en…

So the whole JDK will be based on modules that might or not be included in potentially different profiles (for example a Java ME equivalent?), or has that been dropped ?

I remember seeing something about that in a presentation a few years ago.

I think it's a good decision from Oracle to not include much more (compared to Jigsaw) in Java 9, given the huge scope of the Jigsaw change, which might probably be the change with the largest internal code impact so far ever done in Java, or at least one of the largest (if the plan to refactor the JDK for modules goes further).

Re: Java 9 features announced

#224

Post by mdaniel »

karianna wrote: post #201
mdaniel wrote: post #76

Earlier quoted context omitted.

There is an official JSON API: https://jcp.org/en/jsr/detail?id=353 But it is unclear how many of the existing implementations conform to it, and it definitely doesn't work toward your misguided One True JSON Implementation goal.

That's a Java EE API. I've been working with the Java SE and Java EE folks to make sure that a new version of that will sit on top of the core JDK 9 one.

How did you arrive at the conclusion that a set of interfaces is a JavaEE API?

Above and beyond the fact that in section 2.2 of the JSR it plainly states: "This JSR is targeted for Java SE 6 or higher and Java EE 7 or higher platforms."

Re: Java 9 features announced

#225

Post by mdaniel »

Alupis wrote: post #142
Afforess wrote: post #139

Earlier quoted context omitted.

I was curious myself. I dug up the original proposal to create sjavac, which is here: http://openjdk.java.net/jeps/139

Interesting -- finally bringing multiple-core/process compiling to javac. Although, I must admit, I have yet to work on a project where compile times were a major issue. I guess I'm just in the habit of typing "ant release" and getting some coffee ;)

It's unclear if you are poking fun, but one of the major features of Eclipse (and ejc, by extension) is the "compile on save", so there is no compilation step while working in your IDE (unless, of course, you desired one).

If that is a goal of the sjavac project, then the ability to compile in parallel the different branches of the dependency tree for a set of classes would make for a major upgrade in user experience.

Re: Java 9 features announced

#226

Post by karianna »

mdaniel wrote: post #224
karianna wrote: post #201

Earlier quoted context omitted.

That's a Java EE API. I've been working with the Java SE and Java EE folks to make sure that a new version of that will sit on top of the core JDK 9 one.

How did you arrive at the conclusion that a set of interfaces is a JavaEE API? Above and beyond the fact that in section 2.2 of the JSR it plainly states: "This JSR is targeted for Java SE 6 or higher and Java EE 7 or higher platforms."

We helped test out the RI and TCK - it was in the end up built for Java EE in mind (that's not to say someone couldn't provide a stripped down version that could work for SE - but I don't think anyone has or will).

Re: Java 9 features announced

#227

Post by MrBuddyCasino »

batbomb wrote: post #126
MrBuddyCasino wrote: post #114

Earlier quoted context omitted.

This only works well if we get named parameters, too (and maybe defaults). It is too easy to make mistakes with lots of subsequent constructor arguments of the same type.

We already have that, it's called the Builder pattern.

So for every class in Java, we just create a corresponding builder class, because we lack certain features in the language?

This is not a solution, this is a workaround.

Re: Java 9 features announced

#228

Post by bassman7755 »

Tloewald wrote: post #47
memonkey wrote: post #37

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?

The purpose of a getter or setter is to abstract the implementation out from the usage. Computed properties (e.g. C#'s ability to replace a concrete property with a virtual property without breaking any code) do this without requiring mindless implementation (boilerplate code) for the common case (a property that is exactly what it seems to be). As an added bonus, you don't need to write foo.getBar(), you can just wr…

The problem is that you cant add computed accessor methods to java without breaking code backwards compatibility. This is because a public fields and a public methods have different inheritance semantics - public field access does not trigger polymorphic resolution. Hence auto replacing it with a access method would break any code that relies on the static resolution of the public field (i.e. resolution by referencing type). To fair there probably isnt much code out there that would fall foul of this since there isnt any good reason to write code that relies on public field "hiding" by subclasses, but it would be technically non backwards compatible.
Post reply on HN