6 ms·

Why did you expect it was threadsafe? I can find nothing in its javadoc that would lead me to believe it was. Most of the Java standard library isn't threadsafe

Why did you expect it was threadsafe? I can find nothing in its javadoc that would lead me to believe it was. Most of the Java standard library isn't threadsafe, that why there are concurrent objects in addition to their non-threadsafe cousins and language level synchronization statements. https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/TypeVariable.html#getBounds-- https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/...

benmmurphy 10y ago
You can't avoid it. The java.lang.Class getTypeParameters() method will give you back the same instance. System.out.println(System.identityHashCode(java.util.List.class.getTypeParameters()[0])); System.out.println(System.identityHashCode(java.util.List.class.getTypeParameters()[0])); 2018699554 2018699554
exabrial 10y ago
It seems there's sort of an unwritten standard that static methods should be thread safe or avoid shared state :/ Another great failure is UUID.generateRandomUUID(); One would think that's thread safe... [maybe it's fixed now]
- smnplk 10y ago
  From oracle docs: "A class that represents an immutable universally unique identifier (UUID). A UUID represents a 128-bit value." Looks thread safe to me. No setters on the object.
  - exabrial 10y ago
    Go look at the implementation...
    - exabrial 10y ago
      http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/UUID.java http://grepcode.com/file/repository.grepcode.com/java/root/j... I hope this has been fixed in subsequent releases!
      - charleslmunger 10y ago
        SecureRandom is thread safe, and the global initialization is volatile. What am I missing?
        deleted 10y ago
        [deleted]
        Groxx 10y ago
        The `volatile_var = local_var = X` seems safe - even if you break it into two assignments it only uses the local var afterward, so SecureRandom should be fully initialized in that thread. And though SecureRandom is non-final, it does look safe to use with double-initialization - it self-seeds if not explicitly seeded (it's not in this case), so even double-init shouldn't repeat a value (which is as strong of a statement as SecureRandom allows here - no idea if it makes that claim!). So I'd think it only matters if `volatile` doesn't guarantee that non-final object fields are fully initialized... and I can't find anything that explicitly states one way or another, so I'm not sure. If it doesn't make that guarantee, then yeah - this could publish a partly-initialized SecureRandom without a generator, which would probably crash. But the contents of https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm... imply to me that write-then-read is equivalent to a synchronized block or any other monitor sequence (and in the method they only use the local var, so it doesn't matter for the creator-thread), so I suspect it's fine. Just can't claim any further. @exabrial: care to elaborate? What's unsafe / have you seen crashes due to uninitialized SecureRandom?
      - wuch 10y ago
        Keep in mind that data races in Java are not undefined behaviour. There are quite a few places where authors of standard library deliberately left out synchronization, for example in String.hashCode. EDIT: In this case numberGenerator is volatile so it introduces happens-before relations between write and read.
- mikeash 10y ago
  They basically have to be thread safe, because they're globally accessible. If you can't control access to a call that isn't thread safe, then you can't call it safely at all if there's any code in your process that you don't control (like, say, third-party libraries, or even first-party libraries). I think it's reasonable to assume that any documented API must at least be callable.
  - lomnakkus 10y ago
    Indeed it must be so -- at least it would be very strange to have a thread-unsafe static method where the documentation doesn't spell out how to use it safely[1]. Even in that case it would be a weird thing to even have a thread-unsafe static method (except accidentally, of course). [1] The JDK documentation is pretty good on spelling out such caveats, IME.
twic 10y ago
Even code which isn't "threadsafe" shouldn't crash the VM.
- 0x0 10y ago
  Exactly, especially so because that would totally break sandboxing. Granted, applets are way beyond their best-before date, but there may be other reasons a SecurityManager sandbox is in place, perhaps for isolating multiple .wars from different sources, or maybe someone even wrote a sandbox for executing user-supplied code. Java's raison d'être was arguably the byte code verifier. Being able to crash the JVM with validated byte code is always a bug.

benmmurphy 10y ago

You can't avoid it. The java.lang.Class getTypeParameters() method will give you back the same instance. System.out.println(System.identityHashCode(java.util.List.class.getTypeParameters()[0])); System.out.println(System.identityHashCode(java.util.List.class.getTypeParameters()[0])); 2018699554 2018699554

exabrial 10y ago

It seems there's sort of an unwritten standard that static methods should be thread safe or avoid shared state :/ Another great failure is UUID.generateRandomUUID(); One would think that's thread safe... [maybe it's fixed now]

smnplk 10y ago
From oracle docs: "A class that represents an immutable universally unique identifier (UUID). A UUID represents a 128-bit value." Looks thread safe to me. No setters on the object.
- exabrial 10y ago
  Go look at the implementation...
  - exabrial 10y ago
    http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/UUID.java http://grepcode.com/file/repository.grepcode.com/java/root/j... I hope this has been fixed in subsequent releases!
    - charleslmunger 10y ago
      SecureRandom is thread safe, and the global initialization is volatile. What am I missing?
      - deleted 10y ago
        [deleted]
      - Groxx 10y ago
        The `volatile_var = local_var = X` seems safe - even if you break it into two assignments it only uses the local var afterward, so SecureRandom should be fully initialized in that thread. And though SecureRandom is non-final, it does look safe to use with double-initialization - it self-seeds if not explicitly seeded (it's not in this case), so even double-init shouldn't repeat a value (which is as strong of a statement as SecureRandom allows here - no idea if it makes that claim!). So I'd think it only matters if `volatile` doesn't guarantee that non-final object fields are fully initialized... and I can't find anything that explicitly states one way or another, so I'm not sure. If it doesn't make that guarantee, then yeah - this could publish a partly-initialized SecureRandom without a generator, which would probably crash. But the contents of https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm... imply to me that write-then-read is equivalent to a synchronized block or any other monitor sequence (and in the method they only use the local var, so it doesn't matter for the creator-thread), so I suspect it's fine. Just can't claim any further. @exabrial: care to elaborate? What's unsafe / have you seen crashes due to uninitialized SecureRandom?
    - wuch 10y ago
      Keep in mind that data races in Java are not undefined behaviour. There are quite a few places where authors of standard library deliberately left out synchronization, for example in String.hashCode. EDIT: In this case numberGenerator is volatile so it introduces happens-before relations between write and read.
mikeash 10y ago
They basically have to be thread safe, because they're globally accessible. If you can't control access to a call that isn't thread safe, then you can't call it safely at all if there's any code in your process that you don't control (like, say, third-party libraries, or even first-party libraries). I think it's reasonable to assume that any documented API must at least be callable.
- lomnakkus 10y ago
  Indeed it must be so -- at least it would be very strange to have a thread-unsafe static method where the documentation doesn't spell out how to use it safely[1]. Even in that case it would be a weird thing to even have a thread-unsafe static method (except accidentally, of course). [1] The JDK documentation is pretty good on spelling out such caveats, IME.

twic 10y ago

Even code which isn't "threadsafe" shouldn't crash the VM.

0x0 10y ago
Exactly, especially so because that would totally break sandboxing. Granted, applets are way beyond their best-before date, but there may be other reasons a SecurityManager sandbox is in place, perhaps for isolating multiple .wars from different sources, or maybe someone even wrote a sandbox for executing user-supplied code. Java's raison d'être was arguably the byte code verifier. Being able to crash the JVM with validated byte code is always a bug.