Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Andreas Leitgeb Newsgroups: comp.lang.java.programmer Subject: Re: bug shows up depending on whether Java console is there or not. Date: Fri, 15 Aug 2014 01:22:53 +0000 (UTC) Organization: A noiseless patient Spider Lines: 40 Message-ID: References: Reply-To: avl@logic.at Injection-Date: Fri, 15 Aug 2014 01:22:53 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="7fd0c836d94caf9f0b88d96117d7c68e"; logging-data="24424"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18NFS1psLAeneL9YKvNdkiv" User-Agent: slrn/pre1.0.0-18 (Linux) Cancel-Lock: sha1:Po/Yv1VRQfli/D1JCbmPdtMixbY= Xref: csiph.com comp.lang.java.programmer:29670 Marcel Mueller wrote: > On 12.08.14 19.53, Andreas Leitgeb wrote: >> Now comes the strange part: with 1.6.0_u51, that code block throws >> an JAXBException, but only if the java console is hidden. As soon >> as the console is activated, code runs through perfectly normal (as >> it did up to 1.6.0_u45 regardless of console). >> >> Is this "proof" that something is wrong with _u51, or could anyone >> think of a programming error that would show up only with a specific >> version and depend on console visibility and cause a JAXBException >> to be thrown? > > Almost anything could happen in case of a race condition. > Console access could serialize things that otherwise run in parallel. > Of course, I'm just guessing. Thanks for the guess, but that likely isn't the case here. The code within the try-block doesn't really attempt to write to the console. All logging activities are governed by a debugging flag, and even when that flag is false, the presence or absence of console still made a reliably *reproducible* difference. I still keep it in backhead, though. >> On top of that, the getLocalizedMessage() method on the >> thrown exception returns null, and thus we don't really get much >> information about the problem itself. > > What about the call stack? Try to find the corresponding throw in the > Java source. That will be subject to check in the next days. My hopes are not very high (based on the null from getLocalizedMessage()) to find any other sensible information, but it is definitely worth a try. (I need to add some code for that and have the user check again, as the stack-trace of the JAXBException isn't currently visible to the user. So, it'll take some time.) Thanks!