Are structs necessary for Java?
Structs will make working with memory in nio buffers much easier, cleaner and more performant. Win win.
Oh the pain that could have been saved had these been there from day one (well when nio was created)… Thousands of programmers lost their sanity crying out for proper data constructs… Not in vane my brothers!! Your cries have been heard!!!
can you explain in simple, clear and short bit of text why?
Sure. The simplest way is to pose a problem to you:
In Java, using a direct ByteBuffer (say we are sending data to OpenGL), map the following information into a useable structure of some kind (class) and access the 100th item. You should allocate space for 100 elements, but only bother populating the 100th element for your solution. Set all values to 1:
float x
float y
float z
Compare whatever you come up with to a C version - old crusty language wich is supposed to be more difficult then Java 
struct vertex {
float x;
float y;
float z;
};
int main() {
struct vertex * verts;
vertex *v ;
verts = (struct vertex *) malloc(sizeof(struct vertex) * 100);
v = verts + 99;
v->x = 1;
v->y = 1;
v->z = 1;
free(verts);
}
My C is rusty (like 10-15 years rusty ;)). I don’t know if that’s 100% correct, but if not, it’s close, you get the idea.
Compare both and ask yourself which one of these is supposed to be the modern language making things simple and easy
Did I miss something?
Java:
public class Vertex {
public float x;
public float y;
public float z;
};
Vertex vertex[] = new Vertex[100];
int i = 99;
vertex[i].x = 1;
vertex[i].y = 1;
vertex[i].z = 1;
Looks easier?
Yes.
This is about mapping to a specific memory layout to allow fast efficient interfacing to C code, buffers of network data, file structures, etc. It’s about efficient IO.
In C/C++ you can simply load data directly into a structure that matches a file header layout for example. Because all of these specific data layouts exist and they aren’t going anywhere (e.g. network packet data layouts, file headers, or just structures required to interface to native APIs) this mechanism to efficiently map that real-world data to and from a Java object makes a lot of sense.
handeling memory is something the jvm should do, I have nothing however to giving the jvm hints . if I wanted to pricisely handle memory I would have chosen an other language.
ditch the simple example and give me the theoretical discription, I might be able to walk with you a lot futher.
//was edited missed a few words in my sentence.
Yup.
This is not mapping the data to direct memory. You couldn’t send this to OpenGL.
Java can still manage the memory, that wouldn’t change. This is just a means to access it cleanly and efficiently.
That example is not so simple, that’s the point. It’s a very real world problem that has to be hacked to death in Java to make it work. Hacked may be to strong…let’s just say the solution is unclean, wasteful and obviously non-intuitive (or one of you would have posted the solution).
It’s about efficient data manipulation and interfacing with other technologies. Try using OpenGL or interfacing with other systems via their network protocols, then you’ll know why this is important.
structs for java is a cool idea and i think it could be made with any virtual machine, everything depend on compiler which would be able or not to handle struct type in bytecode. Structs can be emulated even in old jvm’s for example let say that we have some struct:
struct STRUCTURE{
float x, y, z;
String s;
}
// and a function writen in *.java class
STRUCTURE func( STRUCTURE vertex0 )
{
STRUCTURE out_vertex1 = new STRUCTURE();
/// memory alocating should be solved in some other more efiicient way, now
/// i am making it like simple class, but how it colud be solved on compiler
/// side i will give later....
out_vertex1.x = vertex0.x;
out_vertex1.s = new String();
... some other functions
return out_vertex1;
}
theoretically it will not work on any current java compiler but with a little effort from some new compiler (or extension to old ones) it could be coded with any target jvm even 1.1 i think how ? , new compiler should remake this code to something diffrent but the result will be the same:
// our structure as tables, lets say that we have some STRUCTURE as a global tables which will be used in our func example with
// vertex0 argument
float vertex0_STRUCTURE_x[1];
float vertex0_STRUCTURE_y[1];
float vertex0_STRUCTURE_z[1];
String vertex0_STRUCTURE_String[1];
// and argument which will be returned by func
float vertex1_STRUCTURE_x[1];
float vertex1_STRUCTURE_y[1];
float vertex1_STRUCTURE_z[1];
String vertex1_STRUCTURE_String[1];
void func( float arg0 // here will be passed this table: float vertex0_STRUCTURE_x[]
,float arg1[] // float vertex0_STRUCTURE_y[]
,float arg2[] // float vertex0_STRUCTURE_z[]
,String arg3[] // float vertex0_STRUCTURE_String[]
, float out0[] // here everything what must be returnde by function also in tables, out0 = vertex1_STRUCTURE_x[]
, float out1[] // vertex1_STRUCTURE_y[]
, float out2[] // vertex1_STRUCTURE_z[]
, float out3[] // vertex1_STRUCTURE_String[]
)
{
// function body
out0[0] = arg0[0]; // out_vertex1.x = vertex0.x;
out3[0] = new String(); // out_vertex1.s = new String();
// note: no return operation, everytching was made using tables arguments out...
}
there should be no errors in my code i think, well this is only an idea how compilers could make code for older jvm’s especialy 1.5 and 1.4 which are the most popular. I think that SUN should really add some support for structs, probably it also made some cheanges in bytecode to allow hotspot support for structs, it will be really fast. The solution i gave can be made for older jvm’s becouse lot of us use compile with backward compability to for example 1.3 or 1.4 java , and it is not as slow as you colud think, reference of an out arguments is kipped by tables which are the best solution, seperate classes will create other files/classes, so in my way everything will be kept in one .class file. I do not know maybe somebody has earlier thought about it in the same way as i am , if yes please give your opinions etc,
I think that structs give us much more flexibility in coding and some operations will be simpler…
And one thing , in my example also tables can be addeded for struct , for example
struct{
float x[3];
float s[2];
}
etc, in this case compiler will generate one huge table with offset argument… , well it is easy…
Sorry if that what i write was said earlier by other users , i have read first page of this topic, eh
WE NEED STRUCTS!!!
NOOOOOOO!!!
Please don’t put structs in Java just for memory mapping purposes. Please.
The C examples given are mostly flawed because you’ve all forgotten the hell of the necessary packing and alignment pragmas (and even occasionally endiannesss) that were necessary with C compilers (and different with every compiler) to make that work on anything other than the vanilla platform.
At the end of the day we just want to access NIO buffers with a load/store instruction but retain the type security - for me, the syntactic sugar of being able to write vertex.x = blah is less important.
I would prefer to look for a solution that uses the compiler/jvm smarts to infer that from some generic type info or annotations.
This isn’t about changing the language to add a ‘struct’ keyword. That would not happen. This is a significant ease of use and performance improvement for I/O and interfacing to native resources and APIs. We think it can be done entirely with annotations such that the byte code produced is optimal and the JVM takes care of things behind the scenes.
No we have not. ByteBuffers already have support for setting ‘endianness’ and the alignment issues can be easily dealt with using annotations.
[quote]At the end of the day we just want to access NIO buffers with a load/store instruction but retain the type security - for me, the syntactic sugar of being able to write vertex.x = blah is less important.
I would prefer to look for a solution that uses the compiler/jvm smarts to infer that from some generic type info or annotations.
[/quote]
Um… that’s exactly what this is about.
Ah, my apologies then. I’ve been following this debate on and off for a few years now and structs as Java language constructs have been proposed many times (including it would seem right at the start of this thread). Glad to hear that idea has been soundly dumped. But what is the proposal now then? Can you provide a link?
[/quote]
why not make a new RFE which is up to date to where the language is now.
or rather use the wiki and make a full blown document which can be reviewed a few times before submittign a new one.
I think I have it lined up in my head now, what it should do and how it should work. I however still don’t know what it is, or how I can define it.
Because the RFE we have has alll those votes
[quote]or rather use the wiki and make a full blown document which can be reviewed a few times before submittign a new one.
I think I have it lined up in my head now, what it should do and how it should work. I however still don’t know what it is, or how I can define it.
[/quote]
That’s a good idea. I think we can do a full implementation now using annotations. I just whipped up something last night based on some random thoughts and it worked ok. But it is copying the data out of the ByteBuffer still, and I’m not sure that is what we want.
I’ve attached my experiment…
Annotations and a well-defined java.nio API of course 
Cas
does a programmer need to bother with offsets? theres Byte.SIZE Integer.SIZE etc (wenn sticking to primitives).
Probably don’t need offsets. you can just tag members as being part of the struct or not and the natural size of the ‘structed’ members would be used to calculate offsets. However, you would still want some sort of annotation to support various alignment properties of the fields.
[quote]We are considering the struct RFE for Dolphin. However, I hope to make some sample code which illustrates the idea. Potentially, this could be part of the Mustang documentation.
Posted by Peter von der Ahe on February 16, 2006 at 12:29 PM PST
Website: http://blogs.sun.com/ahe #
[/quote]
This is good news… My interpretation is that through the JSR 269 changes we will be able to code an implementation ourselves with Mustang that does most of what we want (though maybe a bit slower than we would like), and that in Dolphin we will probably get something official. Perhaps it will work much like the other open source stuff that got rolled into Mustang (the desktop integration stuff for example).
My personal favourite design would be to simply state that a Struct simply extends an abstract base class, java.nio.Struct, and that all primitive non-transient members are mapped in memory in the order they appear and with the sizes specified by the JLS, and that Object fields are totally ignored by the mapping mechanism. I suppose that simply wouldn’t even need any annotation processing at all.
Cas