A weak compare and swap could act as a full volatile variable, depending on the implementation of the JVM, sure. In fact, I wouldn’t be surprised if on certain architectures it is not possible to implement a weak CAS in a notably more performant way than the normal CAS. On these architectures, it may well be the case that weak CASes are implemented exactly the same as a full CAS. Or it might simply be that your JVM has not had much optimisation put into making weak CASes particularly fast, so the current implementation just invokes a full CAS because it’s quick to implement, and a future version will refine this.
The JLS simply says that a weak CAS does not establish a happens-before relationship, so it’s simply that there is no guarantee that the modification it causes is visible in other threads. All you get in this case is the guarantee that the compare-and-set operation is atomic, but with no guarantees about the visibility of the (potentially) new value. That’s not the same as guaranteeing that it won’t be seen, so your tests are consistent with this.
In general, try to avoid making any conclusions about concurrency-related behaviour through experimentation. There are so many variables to take into account, that if you don’t follow what the JLS guarantees to be correct, then your program could break at any time (perhaps on a different architecture, perhaps under more aggressive optimisation that’s prompted by a slight change in the layout of your code, perhaps under future builds of the JVM that don’t exist yet, etc.). There’s never a reason to assume you can get away with something that’s stated not to be guaranteed, because experiments show that “it works”.