On Fri, 29 Oct 2021 05:10:29 GMT, Alexander Zuev <[email protected]> wrote:
>> We did not change the behavior of the Swing, it works the same before and >> after that spec update. That tests were broken from the beginning and this >> is why they are unstable, and this is why the requirements were changed. > > You contradict yourself. There were a concept of cold and hot times in > component life cycle called non-realized and realized component. It was > specified. Test were written according the specification. Failing to follow > specification would have considered a bug. Some of the projects were relying > on that concept. User code were relying on that concept because they were > taught by us and by tutorials officially approved and endorsed by us. Then > tests started failing, customers started submitting bugs and we discovered > that that is because we do not follow specification we wrote. The bugs were > reported against specific version and they were not present in the previous > version - means the bugs were results of our changes - remember, that was at > the times when there were virtually no external contribution so whatever > caused the specification break was our deed. And instead of fixing it we gave > up and changed specification. This is a definition of backward incompatible > change and in my opi nion pure "we can not fix this bug, let's call it a feature" approach. The Swing never claims that it is thread-safe, and the one who added a notion about the safeness of manipulation of the Swing components from the different threads to the tutorial was just wrong. That was not part of the spec. And it is a good thing that the people realized that mistake and fixed it early than later. ------------- PR: https://git.openjdk.java.net/jdk/pull/6104
