Value Types for Java – A sketch of proposed enhancements

http://cr.openjdk.java.net/~jrose/values/values-0.html

by pjmlp • 12 years ago

121 98 12 years ago

cr.openjdk.java.net

mnw21cam• 12 years ago

Very interesting. Would possibly improve the performance of some programs, as iterating over an array of value types will actually be sequential memory access, whereas iterating over an array of objects involves skipping everywhere over memory.

taeric7• 12 years ago

Does seem to go counter to a long standing culture of "let the VM decide" that has dominated in the JVM landscape for a while.

I will be curious to see how this affects code targeting android and friends.

pron3• 12 years ago

Not quite. Unlike C# structs, this is not a memory-layout choice, but a semantic choice. Value types have specific semantics: immutable, atomic, non-extendable etc. It is up to the VM to choose how to lay them out in memory, but an on-stack/inlined-in-array storage would be possible.

oddthink• 12 years ago

It's definitely encouraging. I don't know what the current state of the art is, but one of the main conclusions of the NIST Java Grande working group back in 2000-2003ish was that lack of a complex type was one of the big things holding Java back for numerical work.

There was a wave of excitement about doing numerics in Java around 2000ish, but it seems like everyone has since moved on.

mhw• 12 years ago

The linked article's title is "Value Types for Java". If you want to add some context to the article, as you presumably do by posting it with the title "Initial proposal for Java value types made public", can you do that by posting a comment? For example, your title makes me wonder:

* Has the proposal progressed beyond this 'initial' version?

* What were the circumstances that led to it not being public originally?

* What circumstances have led to it having been made public now?

bhouston4• 12 years ago

Only 14 years after it introduced with version 1.0 of C#. Java moves really slowly these days. Java lost a lot of credibility in the 3D visualization market in part because it is crazy inefficient to do 3D without value types. C# did very well there with the XNA tool did in part because it had value types and Java didn't.

I wouldn't have moved from Java to C# for desktop apps back in 2001 if Java had stated they would have adopted value types quickly, but they didn't.

History has moved on though and Java isn't really used for desktop apps at all now so this is a moot point. (And C# is on its last legs as well as a desktop development tool, except in large organizations...)

Downvoted to -1 for stating a fact. That has never happened before. Edit again, seems I've been upvoted again. Rollercoaster ride today.

IsTom• 12 years ago

"These days"? Really?

spicyj• 12 years ago

And C# is on its last legs as well as a desktop development tool, except in large organizations...

What's used instead?

daigoba66• 12 years ago

It probably depends on the market and use case. I suspect LOB software is mostly web based these days (easier to deploy, upgrade, and maintain). A lot of desktop software is still written in C/C++ for Win32. Although Microsoft would probably love it if developers starting coding to WinRT which, I think, works best with C#.

bhouston4• 12 years ago

We went back to C++ because C# just isn't supported on Linux well, and Windows is losing its once dominant position. If C# worked on iOS and Linux equivalently to Windows, then I probably would have stuck with it.

But now I do JavaScript + WebGL (which is admittedly slower than both C#, Java and C++): http://clara.io

reallyuthink• 12 years ago

Maybe you were downvoted for leaving a comment that had fuck-all to do with the topic? Maybe people just don't want to go in for yet another round of Java bashing?

pjc50• 12 years ago

Large orgs developing apps for internal use are pretty much the only people doing non-game desktop apps these days. They're still happy with it as an inheritor of Visual Basic, and if you're happy to be Windows-only it works very well.

I agree that Microsoft abandoning XNA development was a very disappointing decision, it was a pretty good tool.

dman• 12 years ago

What about the creative app industry - ie things like photoshop, indesign etc.

_random_3• 12 years ago

What stops XNA people from moving to MonoGame?

alkonaut3• 12 years ago

There is a huge industry doing e.g. CAD applications that will likely never be web based.

dllthomas• 12 years ago

The way language works, "stating a fact" is rarely just stating a fact. Pragmatics is interesting.

dang2• 12 years ago

I'm marking this subthread as off-topic.

Besides being mostly off-topic (not entirely, since it does talk about value types), this comment is arguably a middlebrow dismissal, since it dissmises a serious piece of work without engaging anything interesting in it, and for a superficial reason.

That reason (Java moves slowly) may be valid or may not be, but it isn't interesting in the HN sense of the word, because the route from the article to there is entirely predictable. Such comments get upvoted because they elicit the pleasure of recognition ("I've noticed Java moves slowly too!" or worse, "Yeah, Java sucks!"), and that is a reflex reaction, not a thoughtful one. We all do it—but if we're to have reflective discussions instead of reflexive ones, we need to inhibit it.

The larger problem here, though, is the dreadful subthread the comment spawned. HN threads are sensitive to initial conditions, and middlebrow dismissals lead to lowbrow rejoinders. It's the online comments equivalent of "B players hire C players".

All: please re-read what you're posting and reflect on it. If it goes on a tangent, make sure that tangent is not a predictable one. But if there aren't many comments in the thread, try not to go on a tangent at all—sensitivity to initial conditions means it may well derail the discussion.

scott_s• 12 years ago

I do want to point out that bhouston does have a nugget of useful insight in his post: Java lost a lot of credibility in the 3D visualization market in part because it is crazy inefficient to do 3D without value types. C# did very well there with the XNA tool did in part because it had value types and Java didn’t.

That's a very interesting point: the lack of this very feature closed Java off from an entire field. That implies that if this feature is implemented, it could open up that field to Java. (And, presumably, others with similar requirements.) I wish that bhouston had expanded on that subject.

This, I think, can make the difference between a middlebrow dismissal and an insightful contribution. Instead of framing a comment in terms of what is wrong, frame it in terms of "what would this enable"? You can still make the same fundamental points ("Java lost 3D visualization because it lacked this feature"), but the ensuing discussion can be very different. The post changes from a dismissal to the start of a discussion.

bad_user6• 12 years ago

Only 14 years after it introduced with version 1.0 of C#

After 14 years since C# was introduced, it still doesn't do escape analysis: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per...

Locke16895• 12 years ago

I've played around with it. It doesn't seem like a huge perf boost and would require a lot of dev work -- people who want value semantics use value types and the CLR can do better analysis then we can (e.g., across assemblies).

acqq4• 12 years ago

How will the exiting libraries handle that? Would they be able to store the whole "value objects" instead of just pointers to them?

That being said, not being Java programmer, I'd like to know what's the state of the libraries now? Do libraries handle the collections of the primitive types and the collections of the objects differently now, using the most efficient infrastructure, or is it something that you have to select as the programmer manually even now on case-by-case basis?

(edit: tried to adjust the terminology for Java)

taeric7• 12 years ago

I think the reality is that the vast majority of programmers don't find themselves in situations where the boxing of values causes obvious performance penalties. At least, not at the scale that shows up.

So, in general, most libraries just ignore collections of primitive types.

bhouston4• 12 years ago

It is hugely significant when doing 3D coding if you want to use the convenience of vector and matrix types (and you really do because doing operations on raw floats it not scalable and it is bug prone.)

Background: I did a lot of 3D app dev in Java in the 1998-2001 time frame and then switched over to C#. C# was a huge improvement because it had value types. When you have 5M vectors, you really do not want each to be its own allocation.

acqq4• 12 years ago

But what will happen once there are "value objects" in the language? Will the new libraries be needed? Will the existing ones get some new genericity?

moomin• 12 years ago

I think you're dealing with an selling ice cream in winter problem here. There's a significant number of programmers who need this behaviour, but you don't hear from them because they have no interest in Java, because it doesn't even have rudimentary support for their use cases.

Pxtl• 12 years ago

The problem is that the reason people need value types is often for performance - once you've busted out value types for performance, you expect to be able to keep it with generics, and that's where boxing/unboxing becomes apparent.

Unboxing can also produce counter-intuitive typecast behavior.

If I want to cast an object-boxed int into a short

  Object myBoxedInt = GetInt();
  short myShort  = (short)(int)myIntObj;

because casting directly to short is a run-time exception. I've run into this problem in C#, but my understanding is that Java shares it.

bradleyjg2• 12 years ago

Do libraries handle the collections of the primitive types and the collections of the objects differently now

You can't use the built in collection classes on unboxed primatives, but there are a few different popular third party libraries that help overcome that. For example, Google guava has utility classes to work with arrays of primitives as if they were lists (https://code.google.com/p/guava-libraries/wiki/PrimitivesExp...). There's also GNU trove, and Goldman Sachs' java library. Maybe somewhere in the apache commons library too, I don't remember.

gordaco• 12 years ago

From the article, under "open questions":

Generics over values. It is persistent irritant that generics do not work over primitive types today. With value types, this irritation will increase dramatically; not being able to describe List<Point> would be even worse. Still worse would be having it mean “today’s list, containing boxed points”. Supporting generics over primitives and values, through specialization, is the topic of a separate investigation.

The need for boxing/unboxing is for me one of the most common sources of facepalm in Java. I guess it's difficult to fix without breaking existing code (I guess that a new implementation of generics may not break java code, but it would break existing bytecode), but it's really annoying.

pas• 12 years ago

Java needs feature opt-in, import future.sane.Generics; and so on. (Scala has these.)

Python learned it the hard way. The value of backward compatibility got a bit underestimated there, with Java it's going the other way (the value of progressing, giving better tools to developers is overlooked). The JVM is a big bag of crazy code already (HotSpot with C1 and C2 JIT compilers, the many garbage collector algorithms/implementations and the other stuff that is currently deemed the JVM's responsibility), so there's plenty of space for new opt-in features.

mcosta2• 12 years ago

Feature opt-in sounds good. The C++ people did it. Look what happened. Qt, boost, gtkmm, mscf are all (more or less) good. But you can't (shouldn't) mix them.

hencq• 12 years ago

Supporting generics over primitives and values, through specialization, is the topic of a separate investigation.

Sort of off-topic, but isn't that dilemma also the one preventing Go from having generics?

fiatmoney• 12 years ago

Basically. If you want to implement generics you basically have the choice of 1) boxing (Java approach), 2) instantiating a different type for each generic parameter (C++ approach), and 3) doing something in the runtime to enable a relatively transparent hybrid (C# approach). They each have their own tradeoffs in terms of flexibility, memory consumption, runtime complexity, and compilation / linking time.

frowaway0012• 12 years ago

It's funny how they slowly realize that value types without better Generics are as pointless as better Generics without value types.

pron3• 12 years ago

Note that specialization ("templates") are not a JVM issue but a language issue. If the JVM offers value types, then any JVM language can choose to provide specialization -- or not. In fact, this might be a better idea than baking specialization into the JVM (as done in .Net), as doing so might enforce a specific implementation of generic types, and might prevent other JVM languages from providing their own, novel type systems.

thescrewdriver• 12 years ago

It's probably worth looking at how Scala implemented value types to get an idea of a likely approach: https://docs.google.com/document/d/10TQKgMiJTbVtkdRG53wsLYwW...

lmm2• 12 years ago

Not really the same thing - that only works for classes wrapping a single value, not things like the given Point example.

frowaway0012• 12 years ago

The point is that the proposal now is pretty much identical with what Scala people wanted in the first place.

The single-field restriction is there because there are limits in how aggressive one can fight a non-cooperating runtime, not because it was their principled choice.

hrjet• 12 years ago

More interesting is this: https://github.com/miniboxing/miniboxing-plugin/

Their idea is, IIRC, to flatten the members of a type into an array of primitives.

lmm2• 12 years ago

I'm excited about this not because I'd use them in Java, but because JVM support for value types could make the case classes I'm using in Scala much more efficient.

pron3• 12 years ago

That depends. Value types don't support polymorphism and subclassing. More specifically, you can't have an array of a union value type like you would in C. Could case classes do without polymorphism?

kasey_junk• 12 years ago

Case classes as they currently stand cannot do without polymorphism. That said the Scala team doesn't show a lot of hesitancy in adding new features so I wouldn't be surprised if they implemented case value classes of some sort once the JVM supports them natively.

eternalban• 12 years ago

Possibly missing something here but couldn't the 'value type' distinction be made with an annotation? I think that would be cleaner and possibly more flexible as well.

ajanuary• 12 years ago

Indeed it could be, but that's syntax. The proposal is very careful to talk about semantics; most of the code examples have a disclaimer that the syntax is for illustrative purposes only.

jerven• 12 years ago

Probably, (also makes back compatibility to earlier jvms easier). However, I think the authors went for "horrible syntax in examples" so that we have time to think about a final good/decent syntax. See what happened with lambas lots of proposed syntaxes ended up with one decent one.

Here they want a discussion by implementers about the technical side and avoid bikeshedding about syntax (for now).

wvenable• 12 years ago

Does anyone else find the syntax choices for many of the new Java features to be really distasteful? As a sacrifice to the gods of backwards compatibility, Java syntax seems to going the way of C++.

cleverfoo• 12 years ago

Yeah I totally agree. As much as I like lambdas in JDK8 the syntax feels super bolt on. What's wrong with just {}, -> is just silly.

Alphasite_2• 12 years ago

Whats wrong with the () -> {} syntax? Its nice and simple, and scales down well, so a -> a.b()

TheCoelacanth• 12 years ago

They say that it's a strawman syntax, i.e. it's an intentionally terrible syntax that isn't meant to be used for real to get people to focus on the concept instead of bikeshedding syntax.

w01fe• 12 years ago

Also perhaps interesting for comparison, a Clojure library called Vertigo that emulates C structs with high performance on top of byte buffers:

https://github.com/ztellman/vertigo

taeric7• 12 years ago

Another borderline insane example of how richly lisp can be extended. That is crazy.

lispm• 12 years ago

Also perhaps interesting for comparison, a 1981 Lisp Machine library called DEFSTORAGE provides structures on memory, based on a similar feature of PL/1. For example used in the Lisp Machine file system. Example from Symbolics Genera:

    (defstorage (file-header)
      (version		fixnum)
      (logical-size		fixnum-bytes 2)
      (bootload-generation  fixnum)				;for validating
      (version-in-bootload  fixnum)				;used in above

      (number-of-elements	fixnum-bytes 2)			;for later expansion
      (ignore mod word)

      (* union
        (parts-array array 8 fh-element)
        (parts being fh-element				;and/or reformatting
               fh-header						;this header itself
               info						;header-resident info
               header-fm						;file map of header
               dire						;directory-entry-info
               property-list
               file-map
               pad-area						;many natures of obsolescence
               pad2-area)))

rurban• 12 years ago

Instead of "Codes like a class, works like an int!" they probably meant "Codes like a class, works like a struct".

The fact that a final class cannot be represented and optimized to a simple struct in a non-dynamic language is really disturbing.

aardvark179• 12 years ago

No, they did mean, "like an int." in that value types in java are intended to be atomic and immutable in the same way primitives types already are and that structs (in many languages) aren't.

mcosta2• 12 years ago

It is not. Java dinamic as runtime (if that means something) but is statically typed. Java is dinamic in some ways, arrays have not declared size, has reflection and dinamic method dispatch, but all clasess and are declared and required.

A final class can be represented as a simple (plain) struct if the scape analysis tells so, and allocated on the stack. Else, that inmutable object can be used as a lock, inserted into a collection (think hash) or whatever you can do with an object.

alkonaut3• 12 years ago

Feels like it needs proper (reified/runtime) generics in order to be useful. Reified generics and value types would be a complete and long overdue break in backwards compatibility.

But

It's a bit sad how java struggles to become a C# from five years ago. Would make a lot more sense to leave java alone, add reified generics and value types at the bytecode/vm level and instead launch a new language that could use all of it.

Throw in pattern matching, algebraic data types and a bit more and I'm sold.

ihnorton• 12 years ago

Your comment made me wonder if there was an F# implementation for the JVM. This is the only one I could find, and it is still very young:

https://github.com/penberg/fjord

Alphasite_2• 12 years ago

I'vea heard that its on the cards for 9/10, isn't it? (reified generics)

pjmlp5• 12 years ago

Java like most open standards suffers from design by committee, whereas C# so far had Microsoft alone dictating where to go.

Add the Sun troubles into the mix, and slow the features go.

jdonaldson2• 12 years ago

Try Haxe. http://haxe.org/ You get pattern matching, algebraic data types, and much more. And you can also target Java or C#

coldtea• 12 years ago

He meant a language with an actual ecosystem and hundrends of thousands of users, like Java. Haxe does not qualify at the moment...

bad_user6• 12 years ago

Feels like it needs proper (reified/runtime) generics in order to be useful.

Actually type-erasure is one of Java's best features, because it didn't cripple the runtime for other languages. For example Scala's type system is too expressive to be built on top of .NET's generics.

First of all, reification only helps in terms of type-safety if you have a weak type system. The only value that reification, as implemented in .NET brings is specialization for value types.

Second of all, specialization can be done by the compiler. That's how many languages have always done it. Scala for example has a @specialized annotation for specializing type parameters for primitives [1]. And because this functionality has some gotchas, there's also an up&coming project plugin that's meant to be a replacement in future versions of Scala and that works really well [2]

I myself have used the @specialized annotation on many occasions and in general it does what it's supposed to do. And if that means I can develop in languages like Scala, Clojure and JRuby on top of the JVM, then I really, really love type-erasure. And oh, apparently one barrier for implementing type-classes in F# are the generics in .NET ;-)

It's a bit sad how java struggles to become a C# from five years ago

What I find sad is grown men that can't see the forest from the trees. Java, the language, is totally irrelevant and uninteresting and I like it that way, because it's the kind of language you can rely on in case you want backwards-compatibility (yes, that's a feature). On the other hand, the JVM is light-years ahead of the CLR, because that's what the Sun, now Oracle engineers have been doing with all of their time.

pattern matching, algebraic data types

See Scala. It also does type-classes and higher-kinded types, amongst others that F# is not capable of.

[1] http://www.scala-lang.org/api/2.10.3/index.html#scala.specia...

[2] http://scala-miniboxing.org/

Locke16895• 12 years ago

...

People keep repeating this stuff and they're totally wrong. F* is dependently typed and is a CLR language.

bad_user, have you ever actually attempted to write a type unsoundness proof for your claim or are you just repeating something you heard somewhere?

alkonaut3• 12 years ago

I'm not saying erasure is a bad idea for the jvm, but from a java perspective it's horrible. Not having structs or primitive/struct collections makes all types of low level interop and/or high perf (e.g game) programming cumbersome.

Specialization for value types (including ones not known at compile time) is the main point imho of reified generics, yes.

I like scala and agree that F#'s typed sometimes feels like the bastard child of ML and C# (although I do like ML syntax better).

I agree with you that the backwards compatibility of java is a feature now, since so many other languages incorporate what we'd otherwise want to see in java.

I thought that compile time specializations wouldn't reach all the way, just like C++ templates don't.

bborud• 12 years ago

Would it kill them to format the article nicely?

kolev• 12 years ago

The double underscores are ugly and foreign to Java's conventions.

bilalsoidik• 12 years ago

MAKE VALUE TYPES EASIER TO USE AND EXPLOIT THE TYPE INFERENCE CAPABILITIES Hi! I have some ideas that I think They would be interesting on how to use Values Types. I have two proposal: How to define if? and how to use it? The two are separate proposal. I will write the first proposal.

1.Defining Value Types? A. What about forcing a primary constructor to indicate that it is a value type, there is some thing like it in C#6, but in C# it just to make easy to define a primary constructor. So in Java we can use it differently. So we can say that if we use it that we are defining a value type. It is possible to have more than one explicit constructor. But I don't think that we have to force developer to write a constructor if it is not necessary. Why? According to the document Value-types constructors are really factory methods, so there is no new;dup;init dance in the bytecodes.

So I think that to define a value type we can only do: <pre><code> final class Point(int x, int y){

boolean equals(Point p){ return this.x==p.x&&this.y==p.y}

}; </code></pre> x and y are automatically final and public members. So that can exactly be compiled like: <pre><code> final __ByValue class Point { public final int x; public final int y;

    public Point(int x, int y) { 
        this.x = x;
        this.y = y;
    }

    public boolean equals(Point that) {
        return this.x == that.x && this.y == that.y;
    }

} </code></pre> Simple, concise and contributes to productivity. I also I thought about something new. We can also do: <pre><code> final class Point(int x, int y){ private int c;//if I wont boolean equals(Point p){ return this.x==p.x&&this.y==p.y} public static Point getFunPoint(){ } public static void maFunction(Point p, boolean b, double b){ } } </code></pre> B. Why not an implicit default equals. So if I do : <pre><code> final class Point(int x, int y){} </code></pre> that means if the JVM doesn't find an explicit equals, it cans do logical compare. <pre><code> public boolean equals(Point that) { return this.x == that.x && this.y == that.y; }. </code></pre> So a Point can be defined in one line: <pre><code> final class Point(int x, int y){} </code></pre> C. If we don't want to define something else in a value type, braces can be optional as in lambda expressions :) So to define a value type we can only do: <pre><code> final class Point(int x, int y); </code></pre>

Value Types for Java – A sketch of proposed enhancements

Related Stories