# Now Offically an OpenJDK Contributor

DevFeed: [Now Offically an OpenJDK Contributor](<https://devfeed.tech/articles/now-offically-an-openjdk-contributor-30635.md>)

Original publisher: [Read original article](<http://bad-concurrency.blogspot.com/2011/07/now-offically-openjdk-contributor.html>)

Author: Michael Barker (noreply@blogger.com)

Published: 2011-07-20T20:19:00Z

Content type: opinion

Language: en

Sources: [Bad Concurrency](<https://devfeed.tech/sources/bad-concurrency.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [openjdk](<https://devfeed.tech/topics/openjdk.md>), [Code](<https://devfeed.tech/topics/code.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [C#](<https://devfeed.tech/topics/csharp.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>)

Tags: [design-patterns](<https://devfeed.tech/tags/design-patterns.md>), [go](<https://devfeed.tech/tags/go.md>), [java](<https://devfeed.tech/tags/java.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [openjdk](<https://devfeed.tech/tags/openjdk.md>), [type-safety](<https://devfeed.tech/tags/type-safety.md>)

## AI overview

The author argues that Java and the JVM would benefit from efficient stack-allocated value types, tuples, and related structures. These could improve type safety, enable efficient tiny types, improve cache locality, and reduce garbage-collection pressure. The author also reports that initial implementations have been accepted into the MLVM project, while noting uncertainty about adoption in the JDK or Java language.

## Source excerpt

Being someone who's interested in Open Source and very focused on performance, I've been looking at the Java & the JVM and wondering about what I would most like to see added. IMHO one of the fundamental missing pieces is support for complex stack allocated types. This is not a new idea. C# calls them structs. In C, C++ and Go stack & heap allocation is orthogonal to the definition of the type. An implementation for Java is described by John Rose (some time ago) on his blog. While this is presented as a feature that would benefit alternative languages on the JVM, I think this could bring something significant to Java as well (not that I actually know what such a language feature would look like, I'm not a language designer). It would improve the efficiency of a some very useful design patterns that tend to be avoided (by me anyway) due to the cost of heap allocation. E.g. a number of classes in LMAX's code base consist of aggregations of 64 bit integers. public class OrderInstruction { public OrderInstruction(long accountId, long instrumentId, long clientOrderId, long stopPrice, long price, long quantity) { // ... } } While very efficient, it can lead to a number of errors as it is very easy to screw up an assignment wouldn't prevent assigning the accountId to the price. However, with support for tuples/value types/structs then it would be possible to do the following (I've borrowed from the C# syntax): public struct AccountId { public AccountId(long id) { // ... } } public struct InstrumentId { public InstrumentId(long id) { // ... } } public class OrderInstruction { public OrderInstruction(AccountId accountId, InstrumentId instrumentId, ClientOrderId clientOrderId, Price stopPrice, Price price, Quantity quantity) { // ... } } Given any reasonable implementation the structs Account, InstrumentId, etc, would compile down to a long (and be no less efficient). It would enforce type safety preventing accidental incorrect assignment. Another benefit is that is allows se