Value Types for Java

[Kenneth Russell]

It's possible to do what you want with the existing NIO Buffer classes 
and a helper tool. GlueGen (http://gluegen.dev.java.net/) generates Java 
classes to access C data structures. These accessor classes wrap 
ByteBuffers and provide setter / getter methods for accessing the fields 
of the structs. It maintains parallel ByteBuffer, IntBuffer, etc. views 
of the same memory to avoid multiple memory fetches for multi-byte 
primitive values. It supports arrays of C structures by providing a Java 
array of objects, each of which refers to a slice of the underlying C 
storage.

It's not efficient. The need to dereference through the NIO Buffers 
means that each memory fetch gets expanded into something like three or 
four, assuming the HotSpot compiler can't common up some of those 
fetches for multiple accesses to the same object.

When talking to the graphics card via an API like OpenGL there is less 
need to view the data in the form of structures. 
http://jogl.dev.java.net/ and http://jogl-demos.dev.java.net/ have links 
to various demos and JavaOne presentations. For several years we have 
consistently been able to achieve at least 90% of C speed in 3D 
graphical applications written in Java.

Still, value types would be very useful for exactly the cases you 
describe. I would be concerned about the semantic change of 
pass-by-value and what that would mean for the easy readability and 
understanding of Java source code.

-Ken

Ben Hutchison wrote:
> Miles Sabin wrote:
>> On Wed, Jun 18, 2008 at 6:15 AM, Ben Hutchison <benh at ibsglobalweb.com> wrote:
>>   
>>> Also, in terms of what it doesn't do:
>>>
>>> 1. Hard to see any way to extend to interpret a ByteBuffer region as an
>>> array of some value type, a feature ultimately needed for bulk interop
>>> with external IO/processes, I feel.
>>>     
>> What do you mean here? That a ByteBuffer be viewable as an array of
>> (value) objects? 
> Yes. Viewable and updatable.
> 
>  The example case I have in mind is an interaction between a Java 
> process and a 3D graphics driver. Eg a Java process would be 
> writing/updating triangle data in the buffer, and the graphics driver 
> rendering it. (I admit it might be difficult to get this to work even 
> with value type support, given that Java's philosophy says precise 
> memory level representation is undefined by spec)
> 
>> Again, I'm really not sure what it is that you want
>> to do that you can't already.
>>   
> Your earlier idea seemed to be that heterogeneous value types would 
> translate into multiple side-by-side arrays accessed in unison. Most 
> external processes you might want to interact with aren't going to 
> "think" that way. They would typically expect to find fields of a 
> related struct next to each other.
> 
> (Granted you did mention a  single array encoding for homogenous types, 
> but I am concerned thats too fragile in practice - the moment it becomes 
> heterogenous, the encoding scheme totally changes.)
> 
> So, you could have one encoding of a given value type to/from 
> ByteBuffer, and another otherwise, but that seems messy.
> 
> You surely agree that your proposal represents a (worthy) workaround to 
> work in current JVM architectures, and not the ideal solution?
> 
> -Ben
>