On 28/11/2015 9:37 PM, Doug Lea wrote:
Does anyone know why the static singleton in java.lang.Runtime is
not declared as final?
public class Runtime {
private static Runtime currentRuntime = new Runtime();
I don't see a reason, so it seems likely that somehow no one
has noticed befor
On 11/28/2015 08:19 PM, Vitaly Davidovich wrote:
Is that a valid example given StringBuilder isn't threadsafe to begin
with? If the SB instance is shared among threads that perform writes
to it without external synchronization, it's a bug in that code. Am I
missing something?
That "bug
Is that a valid example given StringBuilder isn't threadsafe to begin with?
If the SB instance is shared among threads that perform writes to it
without external synchronization, it's a bug in that code. Am I missing
something?
You'd have to ensure that the returned String is stable and effective
On 28/11/2015 11:37, Doug Lea wrote:
Does anyone know why the static singleton in java.lang.Runtime is
not declared as final?
public class Runtime {
private static Runtime currentRuntime = new Runtime();
I don't see a reason, so it seems likely that somehow no one
has noticed before th
I agree with Peter.
Also, Ivan, one goal of JEP 280 is to be able to avoid the creation of an
intermediary char/byte buffer when doing string concatenation so when the
implementation of JEP 280 will be integrated it should speedup your benchmark.
cheers,
Rémi
- Mail original -
> De: "
Does anyone know why the static singleton in java.lang.Runtime is
not declared as final?
public class Runtime {
private static Runtime currentRuntime = new Runtime();
I don't see a reason, so it seems likely that somehow no one
has noticed before that this should be final (for thread sa
Hi Aleksey,
>> http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.04/
src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
356 ARG,
The comma is not needed.
548 // Mock the recipe to reuse the concat generator code
549 StringBuilder sb = n
