Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve compiler warnings for jruby_9_2 branch #10247

Merged
merged 1 commit into from
Jan 3, 2019

Conversation

yaauie
Copy link
Member

@yaauie yaauie commented Jan 2, 2019

#10244 added -werror flag, and this PR addresses the fall-out after the jruby_9_2 branch was rebased on top of that work


There are 3 types of compiler warnings that are either resolved or suppressed:

  1. Rawtypes: In JRuby 9.2, RubyArray is a generic, so references throughout
    our codebase to the now "raw" type trigger warnings. In most cases we cannot
    actually resolve the issue, since the JRuby-provided methods for creating
    RubyArrays still return the raw type, so these have been suppressed.

  2. Deprecations:

    • RubyString#intern19() -> RubyString#intern()
    • RubyString#downcase19(ThreadContext) -> RubyString#downcase(ThreadContext)
    • NativeException: remove import & reference directly; suppress usage
      warnings
    • RaiseException(): migrate to equivalent non-deprecated methods wherever
      possible; in some cases where we are using this in conjunction with the
      also-deprecated NativeException to preserve java stacktraces, there
      seems to be no non-deprecated path forward, so these cases have been
      suppressed.
  3. Redundant Casts

    • Resolved

@yaauie yaauie requested a review from danhermann January 2, 2019 23:31
logstash-core/src/main/java/org/logstash/KeyNode.java Outdated Show resolved Hide resolved
@danhermann
Copy link
Contributor

danhermann commented Jan 3, 2019

@yaauie, looks good apart from the IDEA-specific annotations. It really is unfortunate that normal use of core JRuby classes such as RubyArray triggers compiler warnings, but I guess there's little that can be done about that.

There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved
@yaauie yaauie force-pushed the jruby_9_2_compilation_warnings branch from a186677 to 8770778 Compare January 3, 2019 17:29
@yaauie yaauie dismissed danhermann’s stale review January 3, 2019 17:34

removed IDEA-specific warning suppressions that the review had issues with

@yaauie yaauie merged commit 4a5c773 into elastic:jruby_9_2 Jan 3, 2019
@yaauie yaauie deleted the jruby_9_2_compilation_warnings branch January 3, 2019 18:08
yaauie added a commit to yaauie/logstash that referenced this pull request Jan 20, 2019
There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved
yaauie added a commit to yaauie/logstash that referenced this pull request Jan 22, 2019
There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved
jsvd pushed a commit to jsvd/logstash that referenced this pull request Jan 22, 2019
There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved
yaauie added a commit to yaauie/logstash that referenced this pull request Feb 4, 2019
There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved
yaauie added a commit that referenced this pull request Feb 5, 2019
* bump jruby to 9.2

* don't rely on logstash-base docker image

* work around webmock ruby 2.5 support

* ensure data folder exists in docker

* change fixnum and bignum to integer

* FileUtils.rmdir to rm_rf

this is because from 2.3 to 2.5 FileUtils.rmdir will throw an exception
if the directory isn't empty. On 2.3 the operation will just not delete
the directory silently.

* bump jruby to 9.2.5.0 and fix test

* make rake default task since prepare pack needs it

* Resolve compiler warnings (#10247)

There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved

* JRuby 9.2 bundler shenanigans (#10266)

* Revert "Revert "remove forced dependency on old bundler (#9395)""

This reverts commit bef9841.

* plugin management: update internal bundler to 1.17.x APIs

* deps: update dev dependency webmock to version compatible with JRuby 9.2

* spec: update Pack fixture to include manticore version that doesn't conflict

* build: update gradle to version that has Java 11 support

* java11: resolve or suppress deprecation warnings

* Remove superfluous flag opting into ParNew GC implementation

When opting into CMS garbage collector with `XX:+UseConcMarkSweepGC`, the
young generation collector ParNew has been the default since Java 8, making
the `XX:+UseParNew` flag redundant; the flag was removed in Java 9, and
should no longer be specified to work with modern Javas.

https://bugs.openjdk.java.net/browse/JDK-8006478
https://openjdk.java.net/jeps/214

* spec: set thread name to example description for easier debugging

* spec: prevent errors in testing specs by checking against skip list before using

* no-op: remove use of `HashMap#computeIfAbsent` on single-threaded code

> This method will, on a best-effort basis, throw a `ConcurrentModificationException`
> if it is detected that the mapping function modifies this map during computation.
>
> -- https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/HashMap.html#computeIfAbsent(K,java.util.function.Function)

* qa: by default, run integration against Elastic Stack 6.5.x

To support development on Logstash on top of Java 11, default to testing
against an Elastic Stack that is capable of running on Java 11.

* qa: ignore deprecation warnings when comparing offline pack output

* qa: add Java 9+ support to ChildProcess dev dependency

this can safely be removed when the childprocess gem supports Java9+
enkessler/childprocess#141

* qa: allow connections to localhost in webmock

* bump jrjackson version

* fix filebeat integration tests

* spec: ensure license compliance spec runs first

The license compliance spec that validates the licenses of bundled
plugins appears to not be compatible with the hooks that we inject
into bundler for plugin management, and will fail in obscure ways
when run after those hooks have been added. Since those hooks are
not necessary for validating licenses, the easiest solution was to
ensure that those specs run first, before the VM has been poluted.

Since the gradle/junit/rspec bridge that is currently in place
runs all specs in the same JVM, we also need to make sure that the
rspec "world" is reset before a run, to ensure that it doesn't
retain spec definitions from previous runs.

Also updates the rake invocation, although I'm not sure it is used
any more.
yaauie added a commit to yaauie/logstash that referenced this pull request Feb 5, 2019
* bump jruby to 9.2

* don't rely on logstash-base docker image

* work around webmock ruby 2.5 support

* ensure data folder exists in docker

* change fixnum and bignum to integer

* FileUtils.rmdir to rm_rf

this is because from 2.3 to 2.5 FileUtils.rmdir will throw an exception
if the directory isn't empty. On 2.3 the operation will just not delete
the directory silently.

* bump jruby to 9.2.5.0 and fix test

* make rake default task since prepare pack needs it

* Resolve compiler warnings (elastic#10247)

There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved

* JRuby 9.2 bundler shenanigans (elastic#10266)

* Revert "Revert "remove forced dependency on old bundler (elastic#9395)""

This reverts commit bef9841.

* plugin management: update internal bundler to 1.17.x APIs

* deps: update dev dependency webmock to version compatible with JRuby 9.2

* spec: update Pack fixture to include manticore version that doesn't conflict

* build: update gradle to version that has Java 11 support

* java11: resolve or suppress deprecation warnings

* Remove superfluous flag opting into ParNew GC implementation

When opting into CMS garbage collector with `XX:+UseConcMarkSweepGC`, the
young generation collector ParNew has been the default since Java 8, making
the `XX:+UseParNew` flag redundant; the flag was removed in Java 9, and
should no longer be specified to work with modern Javas.

https://bugs.openjdk.java.net/browse/JDK-8006478
https://openjdk.java.net/jeps/214

* spec: set thread name to example description for easier debugging

* spec: prevent errors in testing specs by checking against skip list before using

* no-op: remove use of `HashMap#computeIfAbsent` on single-threaded code

> This method will, on a best-effort basis, throw a `ConcurrentModificationException`
> if it is detected that the mapping function modifies this map during computation.
>
> -- https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/HashMap.html#computeIfAbsent(K,java.util.function.Function)

* qa: by default, run integration against Elastic Stack 6.5.x

To support development on Logstash on top of Java 11, default to testing
against an Elastic Stack that is capable of running on Java 11.

* qa: ignore deprecation warnings when comparing offline pack output

* qa: add Java 9+ support to ChildProcess dev dependency

this can safely be removed when the childprocess gem supports Java9+
enkessler/childprocess#141

* qa: allow connections to localhost in webmock

* bump jrjackson version

* fix filebeat integration tests

* spec: ensure license compliance spec runs first

The license compliance spec that validates the licenses of bundled
plugins appears to not be compatible with the hooks that we inject
into bundler for plugin management, and will fail in obscure ways
when run after those hooks have been added. Since those hooks are
not necessary for validating licenses, the easiest solution was to
ensure that those specs run first, before the VM has been poluted.

Since the gradle/junit/rspec bridge that is currently in place
runs all specs in the same JVM, we also need to make sure that the
rspec "world" is reset before a run, to ensure that it doesn't
retain spec definitions from previous runs.

Also updates the rake invocation, although I'm not sure it is used
any more.
jsvd pushed a commit that referenced this pull request Feb 5, 2019
backport of  #10279 to 6.x

* bump jruby to 9.2

* don't rely on logstash-base docker image

* work around webmock ruby 2.5 support

* ensure data folder exists in docker

* change fixnum and bignum to integer

* FileUtils.rmdir to rm_rf

this is because from 2.3 to 2.5 FileUtils.rmdir will throw an exception
if the directory isn't empty. On 2.3 the operation will just not delete
the directory silently.

* bump jruby to 9.2.5.0 and fix test

* make rake default task since prepare pack needs it

* Resolve compiler warnings (#10247)

There are 3 types of compiler warnings that are either resolved or suppressed:

1. Rawtypes: In JRuby 9.2, `RubyArray` is a generic, so references throughout
   our codebase to the now "raw" type trigger warnings. In most cases we cannot
   actually resolve the issue, since the JRuby-provided methods for creating
   `RubyArray`s still return the raw type, so these have been suppressed.

2. Deprecations:
   - `RubyString#intern19()` -> `RubyString#intern()`
   - `RubyString#downcase19(ThreadContext)` -> `RubyString#downcase(ThreadContext)`
   - `NativeException`: remove import & reference directly; suppress usage
     warnings
   - `RaiseException()`: migrate to equivalent non-deprecated methods wherever
     possible; in some cases where we are using this in conjunction with the
     also-deprecated `NativeException` to preserve java stacktraces, there
     seems to be no non-deprecated path forward, so these cases have been
     suppressed.

3. Redundant Casts
   - Resolved

* JRuby 9.2 bundler shenanigans (#10266)

* Revert "Revert "remove forced dependency on old bundler (#9395)""

This reverts commit bef9841.

* plugin management: update internal bundler to 1.17.x APIs

* deps: update dev dependency webmock to version compatible with JRuby 9.2

* spec: update Pack fixture to include manticore version that doesn't conflict

* build: update gradle to version that has Java 11 support

* java11: resolve or suppress deprecation warnings

* Remove superfluous flag opting into ParNew GC implementation

When opting into CMS garbage collector with `XX:+UseConcMarkSweepGC`, the
young generation collector ParNew has been the default since Java 8, making
the `XX:+UseParNew` flag redundant; the flag was removed in Java 9, and
should no longer be specified to work with modern Javas.

https://bugs.openjdk.java.net/browse/JDK-8006478
https://openjdk.java.net/jeps/214

* spec: set thread name to example description for easier debugging

* spec: prevent errors in testing specs by checking against skip list before using

* no-op: remove use of `HashMap#computeIfAbsent` on single-threaded code

> This method will, on a best-effort basis, throw a `ConcurrentModificationException`
> if it is detected that the mapping function modifies this map during computation.
>
> -- https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/HashMap.html#computeIfAbsent(K,java.util.function.Function)

* qa: by default, run integration against Elastic Stack 6.5.x

To support development on Logstash on top of Java 11, default to testing
against an Elastic Stack that is capable of running on Java 11.

* qa: ignore deprecation warnings when comparing offline pack output

* qa: add Java 9+ support to ChildProcess dev dependency

this can safely be removed when the childprocess gem supports Java9+
enkessler/childprocess#141

* qa: allow connections to localhost in webmock

* bump jrjackson version

* fix filebeat integration tests

* spec: ensure license compliance spec runs first

The license compliance spec that validates the licenses of bundled
plugins appears to not be compatible with the hooks that we inject
into bundler for plugin management, and will fail in obscure ways
when run after those hooks have been added. Since those hooks are
not necessary for validating licenses, the easiest solution was to
ensure that those specs run first, before the VM has been poluted.

Since the gradle/junit/rspec bridge that is currently in place
runs all specs in the same JVM, we also need to make sure that the
rspec "world" is reset before a run, to ensure that it doesn't
retain spec definitions from previous runs.

Also updates the rake invocation, although I'm not sure it is used
any more.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants