Date: Fri, 26 Oct 2007 16:37:28 -0700 (PDT) From: Nick Johnson <freebsd@spatula.net> To: freebsd-java@freebsd.org Subject: Re: JDK 1.5.0 patchset 7 "South China" Message-ID: <20071026162351.B25435@turing> In-Reply-To: <20071026134734.M25435@turing> References: <20071023195511.GA27666@misty.eyesbeyond.com> <20071023170536.H25435@turing> <20071024210348.GA34044@misty.eyesbeyond.com> <20071026205754.15950c80@tinca> <20071026121159.A25435@turing> <20071026134734.M25435@turing>
next in thread | previous in thread | raw e-mail | index | archive | help
Good news! I did an rm -rf work on the port, edited the makefile just to be absolutely certain it would bootstrap off Diablo, recompiled everything, and now the 1.5 JDK from ports does indeed read java.security. It also reports the correct debugging information with -Djava.security.debug=properties like it should. No clue whatsoever why it wasn't reading it before or why it made a difference to bootstrap it with Diablo. I'm pretty sure I'd always done a make clean on the port before building it in the past (because otherwise it doesn't do anything anyway), so I wouldn't think that removing the work directory entirely would make a difference (unless make clean leaves things behind). I guess the moral of the story is that if you're getting bizarre behaviour out of the JVM, try removing the port's work directory, download Diablo for use with bootstrapping, and build it again using Diablo as the bootstrap. [Incidentally, truss still fails to show that one particular open call, but ktrace -t n does show it. (Previously even ktrace -t n was not showing it.)] Hope this thread helps if others find themselves in a similar situation. It remains to be seen whether this will resolve the problems I've been having with InetAddress caching, but I am hopeful that it will. Nick On Fri, 26 Oct 2007, Nick Johnson wrote: > Just to add another piece to the puzzle here, I downloaded the Diablo JDK > and confirmed that it *does* read java.security, and the > -Djava.security.debug=properties option does produce debugging output. > > Just for kicks I'm going to try rebuilding the jdk port, this time > bootstrapping it from Diablo to see if that makes a difference. > > On Fri, 26 Oct 2007, Nick Johnson wrote: > > > On Fri, 26 Oct 2007, Zsolt K?ti wrote: > > > > > A friend of mine's result: > > > $ ktrace -t n java Test > > > $ kdump |fgrep securi > > > 1589 java NAMI "/usr/local/jdk1.5.0/jre/lib/security/java.security" > > > 1589 java NAMI "/usr/local/jdk1.5.0/jre/lib/security/java.security" > > > > I don't get that when I run that exact same sequence of commands with > > 1.5.0_13-p7. There's no reference to java.security in the ktrace at all. > > That's on FreeBSD 6.2 though. > > > > Adding -Djava.security.debug=properties produces no additional output. > > > > I went so far as to rebuild the port again this morning; it made no > > difference. > > > > The JVM was built with debug support enabled and IPv6 support enabled > > (though I routinely turn this off with the preferIPv4 switch). The > > options for building the browser plugin, installing the unlimited strength > > policy files, updating time zone data and building the port in a jail were > > not enabled. > > > > This is also running with libpthread=libthr, though I doubt that would > > make any difference. > > > > Nick > > > > > > -- "Courage isn't just a matter of not being frightened, you know. It's being afraid and doing what you have to do anyway." Doctor Who - Planet of the Daleks This message has been brought to you by Nick Johnson 2.3b1 and the number 6. http://healerNick.com/ http://morons.org/ http://spatula.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071026162351.B25435>