Re: How stable is 1.5?
- From: "Mickey Segal" <not_monitored@xxxxxxxxxxx>
- Date: Fri, 4 Nov 2005 16:47:06 -0500
"Larry Barowski" <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote in
message news:q5adnSX_moelOvbenZ2dnUVZ_tWdnZ2d@xxxxxxxxxxxxxx
>
> The crash happens when a window peer is disposed.
> For a test case, did you try popping up a window and
> disposing it repeatedly?
The relevant code is at a point where a Panel is removed and a new Panel is
added. I fiddled with the code a bit from the code in the thread I cited
from exactly a year ago, but the problem remains. What I'm doing is
creating a new "Page" class extending Panel. Here is the core method, in
which the constrain class is for a GridBagLayout:
___________________
Page.now = pageCode;
Page newPage = instantiateClass(pageCode); // making the new object before
adding it
newPage.resetValuesForPage();
if (page != null) remove(page);
page = newPage;
Page.constrain(this, page, 0, 0, 1, 1, GridBagConstraints.NORTH, 0, 0, 0,
0, GridBagConstraints.BOTH, 1, 1);
if (!infoTipPanelConstrained && Page.pageAllowingTips(Page.now))
{
Page.constrain(this, infoTipPanel, 0, 1, 1, 1,
GridBagConstraints.NORTH, 2, 2, 0, 2, GridBagConstraints.HORIZONTAL, 1, 0);
resetInfoTipPanel(page.getMainPanelScroll());
infoTipPanelConstrained = true;
}
else if (infoTipPanelConstrained && !Page.pageAllowingTips(Page.now))
{
if (infoTipPanel != null) remove(infoTipPanel);
infoTipPanelConstrained = false;
}
validate(); // calls setBounds and makes TextFields visible for setText to
call textValueChanged
page.resetFocusForPage(); // calls methods to set focus after the
components are visible
____________________
I tried all sorts of simulations but was unable to reproduce the problem in
a smaller applet. For typical bugs I've been able to narrow down the
problem, as illustrated by the many reductionistic bugs listed at
www.segal.org/java/.
> Also, I would email back whoever rejected your bug
> report, tell them they are being silly and to at least
> have someone take a look at the crash dump. After
> all, if you are not using JNI, a true crash can not be
> the fault of the application programmer (though I
> suppose this could be a video driver bug). That
> worked for me when I found a JDI bug in Java 1.6.
> I was working hard to restrain my annoyance, so I
> think the worst I said in regard to always demanding
> a test case was "use your common sense".
I'm not using JNI. I can understand Sun's reluctance to deal with an applet
that has 30,000 lines of code, but clearly their JVM is buckling
intermittently under some sort of strain and it is not something one can
necessarily reproduce in a small program.
I once had a similar problem that occurred only in Apple's old MRJ JVM, and
the engineers at Apple were able to look at the crucial code and recommend a
workaround to their error. The workaround involved creating new objects
with temporary names before adding them to a layout. The changes from last
year's code to this year's code attempted to try a similar approach, but
without success.
If this happened more than 1% of the time it would be simpler to tinker.
.
- Follow-Ups:
- Re: How stable is 1.5?
- From: Larry Barowski
- Re: How stable is 1.5?
- References:
- Re: How stable is 1.5?
- From: Mickey Segal
- Re: How stable is 1.5?
- From: Larry Barowski
- Re: How stable is 1.5?
- Prev by Date: Re: setLocation does not work
- Next by Date: Re: setLocation does not work
- Previous by thread: Re: How stable is 1.5?
- Next by thread: Re: How stable is 1.5?
- Index(es):
Relevant Pages
|
