Do you have any other environment that might be affecting this? I can't reproduce on MacOS at least:

$ jruby -ve "a = String.new('a'); p ((-a).object_id == (-a).object_id)"
jruby 9.2.1.0-SNAPSHOT (2.5.0) 2018-05-24 98abdb4 Java HotSpot(TM) 64-Bit Server VM 25.161-b12 on 1.8.0_161-b12 +jit [darwin-x86_64]
true

Our logic does appear to match MRI...if the string is already frozen it is just returned, otherwise it is frozen and deduplicated.

static VALUE
str_uminus(VALUE str)
{
    if (OBJ_FROZEN(str)) {
        return str;
    }
    else {
        return rb_fstring(str);
    }
}

I also do not see this on fedora:

./bin/jruby -ve "a = String.new('a'); p ((-a).object_id == (-a).object_id)"
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 Java HotSpot(TM) 64-Bit Server VM 25.172-b11 on 1.8.0_172-b11 +jit [linux-x86_64]
true

I don't think I have an environment that affects this, since I tested on both OpenBSD and on Windows and got the same results on both. Weird that it would work on Mac OS and Linux but not on Windows or OpenBSD. Can you test on Windows?

@jeremyevans WOW...It does not work on Windows (and Java 9...although I checked 8 and 10 on linux and they both work). WTF

@jeremyevans ok I take that back a little bit...It does work in a script but fails with -e. So perhaps this is some icky CMD parsing thing in that case. That would not explain why FreeBSD fails though. Also it seems like it should work in CMD command line too. This is weird.

I don't think it is limited to -e. I noticed the issue because Sequel's specs failed with JRuby 9.2.0.0, and -e was definitely not involved there.

I think in Sequel's specs, the code is a little different, something akin to:

a = :a.to_s.dup
b = :a.to_s.dup
p ((-a).object_id == (-b).object_id)

That returns true in ruby 2.5.1 and false in jruby 9.2.0.0 (both in Windows and OpenBSD):

$ ruby -v fstring_test.rb
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-openbsd]
true
$ jruby -v fstring_test.rb
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 OpenJDK 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [OpenBSD-x86_64]
false

There are two launchers for JRuby on non-unix platforms: the bash script and the native executable. On Windows there's only the native executable, so that makes me suspect a problem in there. There's another bug about improperly quoting (I believe) where I mention a Win32 call that lets you get at raw untweaked command line arguments.

Can you try both launchers on OpenBSD at least?

OpenBSD uses the jruby-launcher gem to build a native executable, as otherwise you can't use jruby in a shebang line (unlike Linux, on OpenBSD, the shebang line must refer to a native executable). But I can probably test the bash script manually tomorrow.

Note that as my previous comment shows, this is not (only) a command line parsing issue.

Same results with the bash script:

$ PATH=/usr/local/jdk-1.8.0/bin/:$PATH bin/jruby.bash -ve "a = String.new('a'); p ((-a).object_id == (-a).object_id)"
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 OpenJDK 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [OpenBSD-x86_64]
false

I've found the command line issue appears to be encoding related. If I force a UTF-8 encoding, it returns true:

$ LC_CTYPE=en_US.UTF-8 jruby -ve "a = String.new('a'); p ((-a).object_id == (-a).object_id)"
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 OpenJDK 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [OpenBSD-x86_64]
true

However, forcing a UTF-8 encoding does not fix the fstring_test.rb example above:

$ LC_CTYPE=en_US.UTF-8 jruby -v fstring_test.rb
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 OpenJDK 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [OpenBSD-x86_64]
false

@jeremyevans maybe try -X-Dfile.coding=UTF-8 and see if this changes anything. I still don't get it but on windows perhaps file.coding is window31j or something like that...I would still think these would dedup properly though as that encoding.

With that option I get jruby: invalid extended option -Dfile.coding=UTF-8 (-X will list valid options) followed by the usage output (both on OpenBSD and on Windows).

haha @jeremyevans sorry I made two mistakes: -J-Dfile.encoding=UTF-8.

@enebo That appears to make the same changes as LC_CTYPE=en_US.UTF-8, fixing the command line example, but still not having the fstring_test.rb example work:

$ jruby -J-Dfile.encoding=UTF-8 -ve "a = String.new('a'); p ((-a).object_id == (-a).object_id)"
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 OpenJDK 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [OpenBSD-x86_64]
true
$ jruby -J-Dfile.encoding=UTF-8 -v ../fstring_test.rb
jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 OpenJDK 64-Bit Server VM 25.144-b01 on 1.8.0_144-b01 +jit [OpenBSD-x86_64]
false

I suspect the symbol example (fstring.rb) fails because the string associated with the symbol is getting interned with another encoding. Even if the string contents are the same, if the encodings differ we don't deup.

When I put some logging into our dedup logic, I see the following:

+ is UTF-8 and + is US-ASCII
- is UTF-8 and - is US-ASCII
 is ASCII-8BIT and  is UTF-8
 is ASCII-8BIT and  is UTF-8
 is ASCII-8BIT and  is UTF-8
 is ASCII-8BIT and  is UTF-8
 is ASCII-8BIT and  is UTF-8
 is ASCII-8BIT and  is UTF-8
 is ASCII-8BIT and  is UTF-8
method is ASCII-8BIT and method is UTF-8
 is ASCII-8BIT and  is UTF-8
a is UTF-8 and a is US-ASCII
a is UTF-8 and a is US-ASCII
false

And if I disable booting our Ruby kernel altogether with -Xdebug.parser, it works properly. So somewhere in the libraries that load at boot this particular string is getting deduped as UTF-8.

Confirmed the script version works if you use something other than 'a'.

All of the strings that report encoding mismatches above are 7-bit ASCII (and several are blank) so I'm not sure why they're getting in here as ASCII-8BIT and UTF-8. I did notice that RubyString.hashCode does not consider encoding if the strings are 7-bit and the encoding is ASCII-compatible, which allows a US-ASCII 'a' to retrieve the UTF-8 'a' from the cache.

We could modify the hashCode logic to always consider encoding, and then we'd have no conflicts; but we might have multiple copies of some 7-bit strings in there.

MRI does appear to allow multiple entries for the same bytes but different encoding to live in the fstring cache.

a1 = "a".force_encoding("ASCII-8BIT")
a2 = "a".force_encoding("UTF-8")
a1p = (-a1)
a2p = (-a2)
p a1p.object_id == (-a1.dup).object_id # true
p a2p.object_id == (-a2.dup).object_id # true
p a1p.encoding # ASCII-8BIT
p a2p.encoding # UTF-8

MRI does not consider the encoding for a 7-bit string's hash code, but for the fstring cache it does specify a comparison function that rejects mismatched encodings. So they'll go in the same bucket but both encodings are preserved. I'll see about making the same change in JRuby.

For reference, here's the comparison function MRI uses for fstring cache:

static int
fstring_cmp(VALUE a, VALUE b)
{
    long alen, blen;
    const char *aptr, *bptr;
    RSTRING_GETMEM(a, aptr, alen);
    RSTRING_GETMEM(b, bptr, blen);
    return (alen != blen ||
            ENCODING_GET(a) != ENCODING_GET(b) ||
            memcmp(aptr, bptr, alen) != 0);
}

Hmm, this may be a bit trickier than I'd hoped.

All the JDK collections, including the ConcurrentHashMap we're using, default to calling equals and there's no way to replace that without rewriting the collection. RubyString#equals does not consider encoding (in MRI, only if 7bit; in JRuby it seems to always be ignored if the bytes are the same).

So there's a bit more gymnastics required here.