This syntax is not possible, the closest one is:
@StackAllocation Vector3f v = new Vector3f(...);
Yes, sorry, I've forgot about exact syntax for statement annotations -- they are rarely used, as for me.
Interesting idea, though I don't like the annotations syntax for this. I consider the stack allocation as a core feature that shoudn't be optional as it changes the memory behaviour a lot. This is reason why it throws Error instead of some sort of fallback, users would then accidentally run slower/worse path. Also I like it in this explicit way because it tells something special is occuring and not ordinary allocation, such as the case with constructor with argument (or without), the programmer can be misleaded to think that the constructor is actually run or assume that the values are zeroed whereas it's not true.
Well, I agree, your point of view is completely legitime. I just think it's more about your specific use case. As far, as I understand, stack allocations was a critical feature, letting you to port C code to java without great rewritting it to refactor memory usage strategy. So it's really "something special" and "core feature" in your case. But if you want your library to be public used (as for me, it worth it -- it's small, easy, and do the work well -- that's more?), just try to look at it from point of view of developer, thinking about incorporate stack allocations in existing code. In current form, it can't be called non-obtrusive. One should make rather big changes in code, and live with fact, that code won't be ran without instrumentation. It's makes a high barrier for such decision. From other side -- add annotations to some of statement is not a big deal. Anyone can just do it and be sure, what without special processing such annotations do change nothing
in current behavior (and, most probably, even completely removed by obfuscator, if used). As for me, it makes decision "to use or not to use" much easier.
For example. Ive' just downloaded JBullet and exploring sources. I can't run it from my IDE without instrumentation -- although I just want to debug it to clearify code paths, and it's ok for me to have code run slow...
As for "changes the memory behaviour a lot" -- well, think of it from that point of view: memory behavior may be changed a lot by jvm GC options given at startup. It's gives you, in some cases, really big changes in memory behavior, and you really do not see nothing about it in code. It can be chaned by JIT -- and, again, you'll se nothing about it in code. It's java -- memory behavior is much less predictable at all, and I think, most java developers already learn to live with it. You even can't be sure, that new Vector3f() do not actually do the stack allocation by itself -- being optimized by JIT (well, may be for now you can -- such optimizations usually described in Sun's jdk's preview -- but for future... we all waiting for it). If jdk1.7 (8,9..) will include such optimization, one can just remove instrumentation step from it's build process, and letting jit do it's best. While currently one's left with some "strange" legacy code in allocations, which can confuse JIT in it's optimization, and confuse junior developers in understanding "wtf is happens here and why?"
To summarize -- I suppose, annotations-based instrumentation can be added as an option. If someone want stack allocation to be explicit -- it'll have such option. If for someone it'll be easier to add it in non-obtrusive way -- the option will also be here. Nobody can escape. Your library will conquer the world! At least, java part of it