I think it would help get the attention of the different advantages of struct's were better categorized, and it was made clear that they are related to completely separate abstract use-cases.
1. Provide OO access to "raw" data from an external source (usually either a network-protocol or a file-format)
2. Provide higher-speed access to raw data that is large data structures with many small fixed-size data structures inside them
3. Significantly reduce memory requirements and increase speed for apps that have a huge number of very small objects that cannot effectively be represented as arrays
4. Enable portions of the OO universe to be constrained to a sequential portion of native memory so that the *application* can manually dump and restore them as needed.
NB: I've never looked at using mem-mapped BB's for use-case 4; the last time I was doing that was pre-1.4.x (c.f. below).
I've no idea if these are good categorizations/use-cases, but the current descriptions tend to be different depending upon who you ask, with lots of "Oh, and BTW there's also another good reason", instead of a clear, easy-to-read overview.
Consider my age-old BSP conundrum. You have a BSP file, containing data for vertices, triangles, nodes, etc. If you tried to represent this in Java as an actual graph of Vector3fs and so on you'd end up with 50mb of object header bloat before you even got round to storing the data.
I've faced the same problem when dealing with massive parse-trees / AST's (of the order of 10^6 - 10^7 (or more) nodes), in the days before BB's existed, and structs would have been a great help (in the end I just borrowed RAM and did partial-evaluations instead). In this example, you also want to "checkpoint" frequently (losing the partial results of calculations that have generated many millions of nodes is not something you want to do!) - and BB-contained sliding-structs (IIRC your definition of the "sliding" struct...) provide a very convenient way of doing this: (temporarily) I don't care about the fileformat, just let me do a straight-through dump-to-disk at maximum speed
. If the system crashes, I at least know I can get the data back...
This is another problem that the sliding struct solves really neatly.
Indeed: it is "another problem".
I'm not saying it's not a worthy problem to solve, but in the current state of things I think the structs issue comes across in a very confused manner to people who don't already know all the advantages.
Describing it as separate issues may also make it easier for sun to evaluate in the light of other activities - e.g. if they are separately spending considerable effort elsewhere trying to make objects have smaller memory footprint then part of the use-cases may be already improved from that different direction.