This indeed might be related to the hw/lw mixing feature. What I noticed: pressing the Ctrl-Shift-F1 while running your code in the appletviewer, I see the NotationsPanel has zero size. I applied the following diff to the NotationsPanel.java:
$ diff -c NotationsPanel.java~ NotationsPanel.java
*** NotationsPanel.java~ 2009-04-30 17:17:16.000000000 +0400
--- NotationsPanel.java 2009-04-30 18:15:08.000000000 +0400
*** 32,37 ****
--- 32,38 ----
this.rightMargin = rightMargin;
this.bottomMargin = bottomMargin;
+ setSize(boardWidth + leftMargin + rightMargin, boardHeight + topMargin + bottomMargin);
setLayout ( null );
// add two Canvas areas for the top and right board boarder areas
And everything started to work correctly.
Actually the hw/lw mixing code takes into account the bounds of the container when calculating a shape for hw components. I suspect that zero bounds lead to an empty shape for the children compoents, and therefore the borders do not get displayed. While I agree that this is a change in the behavior, I can not say for sure whether this is a defect in Java, or in the user application. I would tend to think it's the latter.
Did you witness the ***partially*** painted borders in your browser?
Did you witness it working fine under older JRE versions?
Did you try my second test case which uses a proper layout manager to position the NotationsPanel?
There you might notice that the NotationsPanel is given a height of one pixel while at the same time the label is positioned correctly at the very bottom.
Please, share your experience.
To avoid repeating observations already made by others I suggest we should focus on compatibility as the major question here.
I took the liberty and confirmed that the test case works just fine under Java 1.1
That makes me certain when I say that the code worked for the last 14 years.
Turning a blind eye on this compatibility issue would mean that a different bug existed in the JRE for 14 years and nobody has noticed it.
I find that hard to believe so I prefer a bug thatâ€™s two months old.
I can assure you that users do pay attention to such compatibility oversights.
Soon they start asking simple questions like â€œWhat else?â€, â€œWhat surprise is coming in the next release?â€ and after that they start looking and getting ready to go away.
So, letâ€™s not discuss how to â€œimprove/fixâ€ the code in the test case because it works just fine with a very long list of JREs.
your test contains both lightweight (Container) and heavyweight (Canvas) components. So I should ask you: have you read the article about heavyweight and lightweight components:
? It's roughly as old as JDK 1.1... This is why I consider your test has been working with the previous JDK versions just by chance, and nobody noticed this problem just because they didn't try writing the code like that.
In the latest JDK versions - 6u12+ and 7.0 - the limited mixing is supported. It is not a backwards incompatibility, and bug-to-bug compatibility was never a priority for JDK
The article you suggested is about mixing Swing and AWT components. Since the test case is a pure AWT applet I donâ€™t think thatâ€™s relevant here. In the AWT world lw/hw mixing was not only supported and well documented but also encouraged.
The discussion in the original thread is way head so you may take a look
Hopefully, you can see there why no miracles, chances or accidents were involved.
Let me pay attention to the following 2 facts:
1. Lightweght != Swing. Indeed, all the Swing components are lightweight (with the exception of toplevels and applets, of course) and most of lightweight components are Swing ones. However, there are several AWT components that are lightweight as well: Component and Container are good examples. We never encouraged nor supported mixing of these components with really heavyweights.
2. Mixing is not just using hw and lw components in the same toplevel. When a lw component is inserted into hw parent - that's fine. But not the reverse...
I don't state the current hw/lw mixing implementation is perfect and contains no bugs. We've already got a number of questions about (in)valid components and this area probably requires more investigation. Some minor improvements in the component shapes are coming. But in this particular case I think the current behavior is correct: any child component must be clipped by its parent bounds, regardless of them being lw or hw.
Well, well ! How big a confusion have we got here?
Letâ€™s refresh some memory, indeed: Previous AWT Enhancements
This time pay closer attention to â€œLightweight UI Frameworkâ€. Those of us who remember would recognize one of the proud babes of Java 1.1.
Read on and youâ€™ll reach the section â€œMixing Lightweight & Heavyweight Componentsâ€.
I can only quote:
[b]â€œLightweight components can be freely mixed with existing heavyweight components.â€[/b]
Are you implying that â€œquality improvementsâ€ in later releases made this statement invalid?
Can we have a link that doesnâ€™t speak about Swing, please?
Now, I suggest we try harder to save each other's time and spare the useless lecturing.
Yes, AWT/Swing developers were a bit too optimistic about "can be freely mixed" at the time of 1.1 release - what else can I say?... Amy's article about http://java.sun.com/products/jfc/tsc/articles/mixing/ is published after the "Previous AWT Enhancements" article (as the latter is referenced in the text) and clearly describes most of the problems with the mixing found after 1.1 was released.
Do you think we've been having support for hw/lw mixing for years? What's been fixed in 6u12/7.0 then?
> I realized that this thread
> &tstart=0 is quite relevant here since it applies to
> JRE 1.6.0_14 (early access) and even JRE7.
> I originally posted it in the â€œSwing & AWTâ€ forum
> mostly based on my guess about its nature.
For some unknown reason your post at Swing & AWT forum was missed (at least, by me:)) Let me take a day or two to look at the problem...
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.