Re: Code review request: 7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so
On 25/09/2012 05:16, Weijun Wang wrote: Hi Stuart Please take a look at http://cr.openjdk.java.net/~weijun/7200682/webrev.00/ So I am now using java -XshowSettings:properties | grep os.arch to find out the arch. Not sure if there is a more formal way to do that. An alternative might be to look at the OS_ARCH field in the release file The intention with that file is that there is somewhere in the image that IDEs, tools, tests, etc. can look at without needing to run java. The other issue might be the development environment where you are running tests on a non-images build and so the release file won't exist. -Alan.
hg: jdk8/tl/jdk: 2 new changesets
Changeset: f0aa997ad78b Author:valeriep Date: 2012-09-25 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0aa997ad78b 7199941: test about AES/ECB mode fails Summary: Fixed the problem of field blockMode not having correct value for AES algorithms. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 4fcbddfd97f0 Author:valeriep Date: 2012-09-25 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fcbddfd97f0 7199939: DSA 576 and 640 bit keys fail when initializing for No precomputed parameters Summary: Fixed initialize(int, SecureRandom) call to not error out when no precomputed params available. Reviewed-by: vinnie ! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java ! src/share/classes/sun/security/provider/DSAParameterGenerator.java ! src/share/classes/sun/security/provider/ParameterCache.java
hg: jdk8/tl/langtools: 7193657: provide internal ArrayUtils class to simplify common usage of arrays in javac
Changeset: 0e5899f09dab Author:jjg Date: 2012-09-25 13:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e5899f09dab 7193657: provide internal ArrayUtils class to simplify common usage of arrays in javac Reviewed-by: mcimadamore, jjg Contributed-by: vicent...@yahoo.es ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/javac/api/MultiTaskListener.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + src/share/classes/com/sun/tools/javac/util/ArrayUtils.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java
hg: jdk8/tl/langtools: 7196464: upgrade JavaCompiler.shouldStopPolicy to accomodate policies in face of error and no error
Changeset: 99d23c0ef8ee Author:jjg Date: 2012-09-25 13:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99d23c0ef8ee 7196464: upgrade JavaCompiler.shouldStopPolicy to accomodate policies in face of error and no error Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent
Please review the change at http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward Overview -- * introduced consistent forwarding to AbstractStringBuilder from StringBuffer and StringBuilder for append and other methods per the bug report. * Added missing @Override annotations. * Got rid of knowledge of the sub-classes from ASB (smelled too bad to leave in). * Retained all methods to maintain compatibility (even though some like append(StringBuffer) could go away because append(CharSequence) would do). * To further maintain compatibility, used sychronized(this) in place of adding synchronized methods to those methods in StringBuffer that now need it (because of type-based dispatch being done in super rather than in /both/ StringBuffer and StringBuilder with CharSequence args). * Ensured that StringBuffer.append(StringBuilder) and StringBuilder.append(StringBuffer) are both handled properly. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
Re: Code review request: 7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so
On 9/25/12 12:58 AM, Alan Bateman wrote: On 25/09/2012 05:16, Weijun Wang wrote: Hi Stuart Please take a look at http://cr.openjdk.java.net/~weijun/7200682/webrev.00/ So I am now using java -XshowSettings:properties | grep os.arch to find out the arch. Not sure if there is a more formal way to do that. An alternative might be to look at the OS_ARCH field in the release file The intention with that file is that there is somewhere in the image that IDEs, tools, tests, etc. can look at without needing to run java. The other issue might be the development environment where you are running tests on a non-images build and so the release file won't exist. The change looks like it does what it's intended to do, but it seems like there ought to be a better way to do this. Surely we don't expect every shell script to dig around and find the right paths to architecture-specific libraries, do we? I haven't looked too closely at the multiarch stuff, and aside from a bunch of flamage on Ubuntu forums, I did find this: https://wiki.ubuntu.com/MultiarchSpec It seems mostly about packaging and filesystem layout. I recall seeing somewhere that toolchains are expected to choose the right paths, so that one can install properly-constructed packages without regard to architecture (even installing both flavors on the same machine) and things should just work. What I couldn't find is a way for a running process to detect which architecture it is, so that it can look in the right place in the filesystem for architecture-specific files. Maybe there's a way to do this, I just haven't found it. Either that or the multiarch scheme isn't fully fleshed out. Meanwhile I don't think it's reasonable to try to put this logic into the shell script tests. They're bad enough already with the OS-specific logic that's done slightly differently in each test. Adding multiarch stuff would make things really messy. The alternative may be to stop trying to run 32-bit tests on the 64-bit-multiarch systems. s'marks
