fix partially #1236 - hopefully the exclude pattern will be generic enough for future changes ;)
Merge branch 'jruby-1_7' of jruby.org:jruby into jruby-1_7
fix includes for rdoc and rake default gems - added json as default gem as well. fixes #1251
Fix Pathname#dup by defining #initialize_copy

* Fixes #1209.
Ensure consistency between internal and ivar path in Pathname
add test for Pathname#dup

* See #1209
Mask a test that fails due to new features on Java 8.
Use lighter-weight check for origin classloader of invokers.

Instead of using somewhat expensive getMethod calls, this uses
a simple comparison of the found class's superclass an expected
class from the current classloader context. The effect should be
the same...that is, if an invoker comes from a higher classloader
with mismatched JRuby classes, it will fail this check just as it
failed the getMethod check.

See JRUBY-5038 and related commits.
Don't search for pregen'ed AOT invokers, due to failure cost.

When AOT compiling code, or when JITing code that has "def" in it,
we must generate a stub to wrap the target method as either a
DynamicMethod or some type of block callback. These stubs are
normally generated at runtime when the AOT script boots, or when
the JITed method containing a def or block is run.

The logic here originally tried to load existing stubs, for the
rare case where the user has AOT-compiled their application *and*
pregenerated those invokers, such as for environments without code
loading capabilities or to force compiled code into the boot
classloader. However, since 99% of AOT users did not also pregen
the stubs, N method definitions executed in a script meant N
ClassNotFoundException getting raised for the missing stubs, plus
the overhead of proceeding to generate and load the stubs at
runtime.

Because there are likely no users pregenerating the stubs (we
have never publicized the feature and it generates far more
classes than just doing it lazily at runtime), we should prefer
startup time of typical AOT situations. This patch removes the
attempt to load AOT-compiled method stubs before generating them,
instead allowing them to generate and falling back on classloading
if the generated code fails to link.

For a simple experiment -- running -X+C -S rake -T in the JRuby
codebase -- my total execution time went from 5.3s down to 4.9s.
Another user saw improvements as well in normal jitted execution,
which is an unexpected benefit.

Note that this does make the pregenerated-stub feature moot; since
we now always try to generate at runtime, those pregenerated stubs
will almost never be seen. This may impact performance for
applications that pregenerate stubs, but it's unlikely to be
considerably slower since the heaviest lifting is from the
bytecode parsing and linking that always has to happen anyway.
Rework SexpMaker to reduce overhead.

Changes include:

* Use NodeType instead of node.getClass().getName() processing.
* Cache simple name of node types rather than recalculating.
* Eliminate noop elements from processing.
* Make everything static and avoid SexpMaker alloc.
* Use literal char instead of single-char string in sb.append.
* Preallocate StringBuilder at 100 chars to kickstart growth.

Performance of 100 sexp constructions of the entire AST of 1.8's
parse_rb.rb went from 0.52s to 0.27s. Since I benched it from
Ruby, most of the remaining overhead was JI string conversion, so
I believe the improvement in sexp construction is closer to a 75%
reduction in overhead.

Further improvement for sexp + sha1 calculation would be to feed
the sexp construction directly into sha1 digester rather than
aggregating in an intermediate StringBuilder + String.
Add RubyEncoding.encodeUTF16 using Unsafe tricks.

Converting a Java String to UTF-16 Ruby String appears to be 2x
faster using this method than converting to UTF-8 using Charset
encoders. However, we can't simply make all Java Strings entering
Ruby suddenly be UTF-16.
Add RubyString.newUTF16String and newUTF8String.

These new methods explicitly produce UTF-16 and UTF-8 Ruby strings
from incoming Java strings. The old newUnicodeString method will
now choose UTF-8 or UTF-16 based on whether the default internal
encoding rather than always doing UTF-8.

This allows a user to specify that the Ruby default internal
encoding should be UTF-16, and we will start encoding all Java
strings accordingly. This may not be a common way to run, but for
situations requiring the fastest-possible Java string handling, it
is an interesting option.

This also seems like "the right thing to do" if a user sets UTF-16
as default internal encoding, so it has a logical justification
outside of performance too.
Fix Java String coercion logic to use fast path.

Java Strings that enter Ruby through JI pass through JavaUtil's
converters. Unfortunately the converter for Java String was using
the slow-path Charset#encode logic rather than our thread-local
UTF-8 encoder logic. The former creates a number of buffers and
other objects, while the latter will ultimately only create the
final byte[] if the incoming String is of a reasonable size.

This commit also fixes the generic encodeBytelist used by
RubyString.newString(..., java.lang.String) and friends to be
smart about how it encodes the string, using the fast path UTF-8
and UTF-16 logic as appropriate.
Merge branch 'jruby-1_7'

Conflicts:
	core/src/main/java/org/jruby/ext/pathname/RubyPathname.java
Disable ClassCache of JITed code when invokedynamic is enabled.
*Only* encode Java Strings as UTF-16 if that's default internal.
Patch around JI specs that break with new Java 8 collections.

Specifically, Java 8 adds #sort to List (sorts in place given a
comparator, so our zero-arg calls and return value expectations
fail), #replace to Map (replaces a given key with a given value),
and #merge to Map (merges a given key's value with an incoming
value). This causes our monkey-patched versions to not be visible
and a few specs to break.
Remove sketchy test for concurrent require.

This behavior is also be covered by tests in MRI's suite and
RubySpec, and those do not appear to be quite as flaky in CI.
None of these tests are particularly reliable, but ours appers to
be a bit worse than the others.
Merge branch 'jruby-1_7'

Conflicts:
	spec/java_integration/types/map_spec.rb
Present the appropriate error for ASCII-8BIT high-range to chars.

This is mildly hacky.

In order to get the JDK Charset logic to present an error for
converting from ASCII-8BIT to a normal character encoding, we
use the US-ASCII Charset as the input. However, that charset
considers high-range bytes to be malformed rather than unmappable,
causing us to present the wrong error. This hack informs our
transcoder that we're doing a binary-to-character transcode and
that malformed errors should be treated as unmappable errors,
allowing us to raise the appropriate Ruby error.

Fixes #1254.