--- Comment #6 from david at jpackage dot org 2006-04-11 04:34 ---
I was saying something slightly different, since I did not test the program
across multiple runs. I did test nextBytes() within the same program run, and
this produced identical bytes with each successive call to
--- Comment #8 from david at jpackage dot org 2006-04-12 00:11 ---
The first case. There is only one instance of SecureRandom. The calls to
nextBytes() are on the same object.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
--- Comment #9 from david at jpackage dot org 2006-04-22 19:18 ---
Maybe we can consider moving these class before closing this bug? I am also
wondering why the are Diffie Hellman classes in the `sig' package. DH is not a
digital signature algorithm, unless we are accounting fo
--- Comment #11 from david at jpackage dot org 2006-08-22 18:03 ---
I am just voicing my support for comment #2.
In practice, we see a problem when installing both classpath and gcj on the
same system, since they both install classpath.security and logging.properties
files.
Ideally
--- Comment #1 from david at jpackage dot org 2006-08-22 18:06 ---
I agree with reporter.
Bug #27890 is also related to FHS compliance with regard to readonly /usr
partitions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798
--- Additional Comments From david at jpackage dot org 2005-09-11 02:59
---
I am experiencing something that looks similar to this with eclipse on x86_64.
Here is the stack trace on amd64.
#0 0x2bb7c710 in GC_local_gcj_malloc () from
/usr/lib/../lib64/libgcj.so.6
#1
exist in superclass
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at jpackage dot org
http
--- Comment #4 from david at jpackage dot org 2006-04-07 10:56 ---
FYI, the JSR 166 Concurrency Utilities sources
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/> are in the
public domain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20247
--- Comment #4 from david at jpackage dot org 2006-04-07 11:06 ---
I experienced a similar problem.
I created a new SecureRandom with
SecureRandom sr = new SecureRandom();
Then, multiple calls to
sr.nextBytes()
produced the same bytes each time.
--
http://gcc.gnu.org/bugzilla