Hmmm, doing some usage test cases.
Have to get back to ya. 
Two things doing it my way gets rid of is Class overhead (the objects aren’t that big), which is the JIT and reflection overhead for each inherited type. That is a bloater and with arguable usefulness in a struct. The features you want are nice and interesting (auto-typing/casting, copyless native access), but I just don’t think we are talking about solving the same problems.
I DO respect the fact that you both try to improve this beautiful language (absolutely no irony/sarcasm here), but I also believe that you are trying to make a VW beatle into a Mercedes by changing the windshield.
I’ll ask you a very simple question and I’m outta your faces: If there was a magical way, to instantly transform your current projects into C/C++/the-graphics-lib-of-your-choice(you’re making games, right?) ones, would you do it? Be honest.
What I’m trying to say is that Java provides convenience from which you cannot easily escape-but you should when you reach the level that you guys are at.
And Cas baby, I might not be doing what you’re doing now, but I survived the 80s using machine code, I spent the 90s with c and c++ and currently I’m working on a new 3D engine for a games studio in London. Java is my hobby so I am a Java newbie compared to you, but I kinda know what I’m talking about. 
Good luck to both of you
I wish I could just say “Wow” to this last post, but I’m noisier than that.
[quote]I DO respect the fact that you both try to improve this beautiful language (absolutely no irony/sarcasm here), but I also believe that you are trying to make a VW beatle into a Mercedes by changing the windshield.
I’ll ask you a very simple question and I’m outta your faces: If there was a magical way, to instantly transform your current projects into C/C++/the-graphics-lib-of-your-choice(you’re making games, right?) ones, would you do it? Be honest.
[/quote]
Maybe if you also gave me a C/C++ compiler that made my all my code as written run on Win and Linux, did GC, didn’t crash on null pointer exceptions (as well as division by zero, and numberous other crash sources), actually used exceptions, and was secure…(for starters)
When people are having a discussion to clarify a piece of technology, why would you jump in and argue whether we SHOULD be having the discussion, because for you it is a forgone conclusion that the entire technology base is inadequate. To take an assertively anti-progressive position towards other’s activities in a public forum, well, is your right, but foreign to me.
After this post, I can only think to myself, why are you at this forum?
Carefully disguised flamebait is still flamebait.
I guess I have to stop reponding to this now, and get on with what we were trying to work out.
Shawn, what you’ve got to do is write some of the code that you want to write and see a) how it looks and b) if it could work! I should do the same really.
Cas
The more I think about it, the only time I would really want a struct is when interfacing to a specific file structure, or native structure. I’m not bothered (yet?) by the extra memory required for java objects. The main inconvenience is the manual packing/unpacking for IO and access to native data structures.
So I tend to side more with princec on this, because it seems the least disruptive to the the language.
This could be simply because I haven’t encountered an example that requires structs for anything other than memory effiency, and that memory savings alone doesn’t seem to be a good enough reason for true structs. Again, maybe I’m just missing the right example.
The thing is, my design also solves the memory efficiency issue as well - and it does it without resorting to pointers, and it’s memory safe. You can store a BSP tree in a ByteBuffer and recurse through it using only one instance of a BSPNode. Nice. And the bonus of having methods on it too What more could a programmer ask for?
Cas
Well it doesn’t solve the memory issues in a way that fits in with how you would want to use structs in Java… (basically the same as objects).
I wouldn’t want a separate ByteBuffer backing each struct, and it is irritating to have to pass around an index or something if you want to pass an individual struct from a buffer containing many… but for IO and native interface purposes it is a reasonable compromise.
Sure thing, I never wanted to use Structs in that way anyway - I’ve got Objects to do that, and they do it better than C++ does it. It’s a win-win situation! Vote vote vote! We only need another 20 odd and it’ll be on the top 25!
Cas
Ok I jsut got a few chumps voted on to the Struct RFE
http://developer.java.sun.com/developer/bugParade/bugs/4820062.html
So it is 99 which is now higher than the last 25th of 96. So it should get some public exposure now at least!
Good Luck still!
It’s a shame I can’t edit the RFE a bit to make it a bit clearer and such. Never mind
Cas
since there is only your short comment at the bottom, i think if you put some more expanation in there as another comment it’s going to be pretty visable…
It didn’t make it today. 
http://developer.java.sun.com/developer/bugParade/top25rfes.html
It’s got 100 votes but other went up as well.
So close. 
Hi all,
Well I got a special email in my inbox today.
"The following bug(s) that you are watching in the Bug Database have been updated.
To view their details, please visit the following urls:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062
Updated field(s): Category"
If you check it, it now says:
Bug ID: 4820062
Votes 318
Synopsis Provide “struct” syntax in the Java language
Category java:classes_nio
WOO-HOO congrats to EVERYONE who voted and/or cared.
Nice job Princec, it’s been a long time, but there ya go
Hmmm, after careful review, I may have jumped the gun on this.
The category changed, but that doesn’t mean it’s going to production so to speak.
Just that it’s actively being research, I s’pose that’s a good thing, but not THE good thing I thought it was.
Tape at 11am…
unfortunately not for mustang (may be dolphin)
Lilian
Nice to see that it is getting some attention.
I think they are really on the right track now. NIO with annotations should be a great way to deal with this.
I wonder if it will lead to something like an ObjectBuffer (much like the primitive-based IntBuffer, DoubleBuffer etc.)
ByteBuffer bb = ByteBuffer.allcoateDirect(size);
// following thows an exception if StructThing class is missing the needed annotations
ObjectBuffer<StructThing> objBuf = bb.asObjectBuffer(StructThing.class);
...
StructThing s = objBuff.get(0);
...
Post that idea to the comments, or te discussion thread Cas mentions in his opening remarks…
done.
We should write a pure Java reference implementation that makes an ObjectBuffer and uses annotations to determine the offsets of the fields. It would be slow but it might serve to get the point across better.
That’s precisely the way forward. The idea is that the VM (or classloader, or combination of both) can then use annotations and intrinsify the code at runtime into ultrafast memory access.
Cas
I came across something interesting this morning.
[quote]You already know how to use libraries (jar files) when compiling, now as annotation processing is a part of any Java compiler, libraries can use annotation processing and automatically generate boiler-plate code for you. A possible example of this is RFE 4820062. I plan to elaborate more on this in a future entry.
[/quote]