Are the KeyEvent VK_* constants stable?!

Question

I've been looking everywhere for an answer to this. I'm newish to Java and I've found myself totally flummoxed by something in the documentation that I don't see how can physically make sense, and if it did it wouldn't be sensible design. I'd really appreciate insight from more knowledgeable folks.
My gripe is with the [java.awt.event.KeyEvent|http://java.sun.com/javase/6/docs/api/java/awt/event/KeyEvent.html] api. It defines lots of virtual key code constants for use with the getKeyCode() function. What I need is to have user-configurable key controls for a game, and store them in a config file, so the VK constants seemed perfect.
To my total horror, I saw this note in the documentation:
WARNING: Aside from those keys that are defined by the Java language (VK_ENTER, VK_BACK_SPACE, and VK_TAB), do not rely on the values of the VK_ constants. Sun reserves the right to change these values as needed to accomodate a wider range of keyboards in the future.This is totally useless for any sort of permanent key binding, which is needed to store keys into a file and have them not break in different/future VMs. So I made THIS monstrosity to define better constants: [http://pastebin.com/f73084f4f]
Once I'd updated the rest of my code to use that, it worked perfectly. Then, just to check something, I decided to open up the compiled .class file in Notepad. But the VK_* identifiers are nowhere to be found. They've apparently been inlined by the compiler. I got a disassembler and checked again, and yes, the enums are being initialized like this (with fricking ASCII codes, of all the unrelated things to number virtual key constants with):
A = new StableKey("A", 11, 65);
B = new StableKey("B", 12, 66);
C = new StableKey("C", 13, 67);
D = new StableKey("D", 14, 68);
E = new StableKey("E", 15, 69);
..etcetera..So what the heck is going on? It says the constants can change, but surely this will break all compiled code even if it isn't storing the key codes externally? Several books have the same ominous caution as the docs, but they all seem to be based on that original note. Is the note wrong? (Its spelling is -- it should be "accommodate".) Or is the VM able to update constants in a way I'm not grasping?
I'm using the ordinary javac that came with the Sun JDK. I've not run the code through any external optimizer.
Please help. This is important to my project. If I release it with the extra constants, I'll never be able to remove them later if they turn out to be completely unnecessary without breaking existing config files, and if I release it without them it might just randomly break anyway later.

Answer 1

If you're new to Java then you are probably unaware of the Swing classes which make it mostly unnecessary for you to look at the value of key codes.I'm not sure what classes you're referring to specifically. I'd welcome an alternate trick for this but I don't see one. It's not like I'm deliberately typing numbers into the code to be awkward. I made this nice dialog box: [http://img14.imageshack.us/i/inputz.png/]. Now when keys are pressed on the JKeyChoosers there, I get sent the KeyEvents. Looking at the members of the KeyEvent class (getKeyChar(), getKeyCode, getKeyLocation, and isActionKey), I don't see a better way to compare two KeyEvents to find out if they're from the same key than to compare the key codes. I need something that's stable across different runs of the application, different VMs, and even different computers.
Directly below the block of documentation that the OP posted in the JavaDocs is "since 1.1", which means that those values have existed for over 10 years and, based on the fact that I had a similar conversation with one of my colleagues when we moved for 1.0.2 to 1.1, I suspect that few, if any, of the underlying values for keys on a standard keyboard have actually changed in the intervening time. So, to answer the original question, the constants appear to have been stable for over a decade.This is interesting, and I agree with you. I'm inclined to think the constants are unlikely to ever change.
But the class file format specifies the Java version it was compiled against and designed to support. So here's what this question really boils down to:
Supposing you compile a file with a Java 1.5 compiler and run it on a 1.6 VM:
(A) Do you get the Java 1.6 classes? I.e., using reflection, could you access the extra methods and fields and such?
OR
(B) Do new VMs include copies of the old classes to support exactly what old programs expect them to support?
Does anyone know this? If it's (A), then Sun could not ever change the constants no matter what, without breaking old stuff. If it's (B), they could change them in future Java versions, and classes would still be consistent after compilation, even if being compiled to different versions of Java broke any values they'd saved externally.