[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125300#comment-17125300 ] Nick Dimiduk commented on HBASE-13583: -- bq. which means we'll get neither startup speedup or java method invocation validation. :( > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk >Priority: Major > Attachments: HBASE-13583.patch, HBASE-13583.v2.patch, > HBASE-13583.v3.patch, HBASE-13583.v4.patch > > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125299#comment-17125299 ] Nick Dimiduk commented on HBASE-13583: -- Not sure if it helps here, but looks like there's a tool called [warbler|https://github.com/jruby/warbler] that assists with AOT-compilation. I do prefer an approach that makes use of a maven plugin, though. > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk >Priority: Major > Attachments: HBASE-13583.patch, HBASE-13583.v2.patch, > HBASE-13583.v3.patch, HBASE-13583.v4.patch > > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508830#comment-16508830 ] Mike Drob commented on HBASE-13583: --- Chatted a bunch with the JRuby team on IRC, apparently jrubyc isn't currently as useful as we imagined it to be. bq. right now it doesn't _really_ even compile to bytecode; it's just a .class file containing a serialized version of our internal representation which means we'll get neither startup speedup or java method invocation validation. > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk >Priority: Major > Attachments: HBASE-13583.patch, HBASE-13583.v2.patch, > HBASE-13583.v3.patch, HBASE-13583.v4.patch > > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508169#comment-16508169 ] Mike Drob commented on HBASE-13583: --- My last patch before I decide to table this for some time. We can drop the rb source files from the jar we produce, and put that shell jar on the jruby load path (it's already on the classpath, I think) and try to load classes out of it. I'm doing something wrong, still, but this all feels like it _should_ work, so I'm going to take a break. If anybody else wants to pick up and run with it, then please go ahead. > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk >Assignee: Mike Drob >Priority: Major > Attachments: HBASE-13583.patch, HBASE-13583.v2.patch, > HBASE-13583.v3.patch, HBASE-13583.v4.patch > > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[
https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506488#comment-16506488
]
Hadoop QA commented on HBASE-13583:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
8s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
13s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 14s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
12s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m
47s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 36m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-13583 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12927097/HBASE-13583.v3.patch |
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml compile |
| uname | Linux 2f1f97c3b7ef 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 30a052b3e5 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/13165/testReport/ |
| Max. process+thread count | 2550 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13165/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> AOT compile our JRuby
> -
>
> Key: HBASE-13583
> URL: https://issues.apache.org/jira/browse/HBASE-13583
> Project: HBase
> Issue Type: Improvement
> Components: build, scripts, shell
>Reporter: Nick Dimiduk
>Assignee: Mike Drob
>Priority: Major
> Attachments: HBASE-13583.patch, HBASE-13583.v2.patch,
> HBASE-13583.v3.patch
>
>
> Our Jruby code seems to not keep up well with Java
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506448#comment-16506448 ] Mike Drob commented on HBASE-13583: --- v3: remove unnecessary extra properties > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk >Assignee: Mike Drob >Priority: Major > Attachments: HBASE-13583.patch, HBASE-13583.v2.patch, > HBASE-13583.v3.patch > > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[
https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505618#comment-16505618
]
Hadoop QA commented on HBASE-13583:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
47s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
51s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 3s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m
52s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 37m 59s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-13583 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12927003/HBASE-13583.v2.patch |
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml compile |
| uname | Linux df032c26a3c7 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / cfeb26d27a |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/13152/testReport/ |
| Max. process+thread count | 2112 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13152/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> AOT compile our JRuby
> -
>
> Key: HBASE-13583
> URL: https://issues.apache.org/jira/browse/HBASE-13583
> Project: HBase
> Issue Type: Improvement
> Components: build, scripts, shell
>Reporter: Nick Dimiduk
>Assignee: Mike Drob
>Priority: Major
> Attachments: HBASE-13583.patch, HBASE-13583.v2.patch
>
>
> Our Jruby code seems to not keep up well with Java changes. We should
>
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[
https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505600#comment-16505600
]
Mike Drob commented on HBASE-13583:
---
v2: get something that actually works! manually verified that there are class
files corresponding to the ruby source in our hbase-shell jar. We end up
including both the .rb and .class files, which might be ok for now? Can circle
back to that later.
It's actually much worse than what you suggested, [~busbey].
Checked the classpath with {{mvn -X}} and saw that we have asm 3.1 in use. I
tried using a newer version of asm both asm:asm:3.3.1 (the latest version in
the asm:asm coordinate space) and org.ow2.asm:asm-all:5.0.4 (the version jruby
is using) and they fail with:
{noformat}
[INFO] TypeError: failed to coerce org.objectweb.asm.ClassWriter to
org.jruby.org.objectweb.asm.ClassVisitor
[INFO] block in compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:189
[INFO] block in compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:291
[INFO] each at org/jruby/RubyArray.java:1734
[INFO] block in compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:290
[INFO] each at org/jruby/RubyArray.java:1734
[INFO]compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:281
[INFO] compile_argv at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:94
[INFO] at -e:3
{noformat}
which led me to https://github.com/jruby/jruby/issues/2887 that suggest using
shaded and unshaded asm in the same classpath will lead to a world of trouble.
So... I looked at the dependency tree and noted that we're pulling asm 3.1 via
jersey-server via a bunch of hadoop libs, so we can exclude that in dependency
management. And in hadoop-3, we're pulling in a different asm, so out that goes
as well. Should file another JIRA to see what else we can prune from that
dependency list, because it looks really long and full of hadoop stuff that I'm
sure we don't need. Removing MR entries for now since those obviously don't
belong, but leaving the rest because I don't want too invasive of a change.
> AOT compile our JRuby
> -
>
> Key: HBASE-13583
> URL: https://issues.apache.org/jira/browse/HBASE-13583
> Project: HBase
> Issue Type: Improvement
> Components: build, scripts, shell
>Reporter: Nick Dimiduk
>Assignee: Mike Drob
>Priority: Major
> Attachments: HBASE-13583.patch, HBASE-13583.v2.patch
>
>
> Our Jruby code seems to not keep up well with Java changes. We should
> investigate adding a compilation step for our shell and the rb scripts in bin
> to ensure they're calling methods that exist on classes that exist. This
> looks like as good a starting point as any:
> https://github.com/jruby/jruby/wiki/GeneratingJavaClasses
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505570#comment-16505570 ] Sean Busbey commented on HBASE-13583: - that's a problem with the version of [ASM|http://asm.ow2.io/] that must be on the classpath during the maven invocation. It looks like the [Opcodes class|http://asm.ow2.io/javadoc/org/objectweb/asm/Opcodes.html] in your classpath is limited to JDK6 and earlier, but JRuby is expecting 1.7+. Try adding it as a dependency to the jruby-maven-plugin plugin declaration. > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk >Assignee: Mike Drob >Priority: Major > Attachments: HBASE-13583.patch > > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[
https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505430#comment-16505430
]
Mike Drob commented on HBASE-13583:
---
Running {{java -jar
~/.m2/repository/org/jruby/jruby-complete/9.1.13.0/jruby-complete-9.1.13.0.jar
-S jrubyc hbase-shell/src/main/ruby -t /tmp/}} worked great, so I have some
hope here.
Patch in current state fails due to arcane error:
{noformat}
[INFO] NameError: uninitialized constant Java::OrgObjectwebAsm::Opcodes::V1_7
[INFO] Did you mean? Java::OrgObjectwebAsm::Opcodes::V1_4
[INFO]Java::OrgObjectwebAsm::Opcodes::V1_5
[INFO]Java::OrgObjectwebAsm::Opcodes::V1_6
[INFO]Java::OrgObjectwebAsm::Opcodes::V1_1
[INFO]Java::OrgObjectwebAsm::Opcodes::V1_2
[INFO]Java::OrgObjectwebAsm::Opcodes::V1_3
[INFO] const_missing at org/jruby/RubyModule.java:3343
[INFO] block in compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:171
[INFO] block in compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:291
[INFO] each at org/jruby/RubyArray.java:1734
[INFO] block in compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:290
[INFO] each at org/jruby/RubyArray.java:1734
[INFO]compile_files_with_options at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:281
[INFO] compile_argv at
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/jruby/compiler.rb:94
[INFO] at -e:3
{noformat}
Not sure what it expects from us, but in accordance with Yonik's Law of
Patches, here it is.
> AOT compile our JRuby
> -
>
> Key: HBASE-13583
> URL: https://issues.apache.org/jira/browse/HBASE-13583
> Project: HBase
> Issue Type: Improvement
> Components: build, scripts, shell
>Reporter: Nick Dimiduk
>Assignee: Mike Drob
>Priority: Major
> Attachments: HBASE-13583.patch
>
>
> Our Jruby code seems to not keep up well with Java changes. We should
> investigate adding a compilation step for our shell and the rb scripts in bin
> to ensure they're calling methods that exist on classes that exist. This
> looks like as good a starting point as any:
> https://github.com/jruby/jruby/wiki/GeneratingJavaClasses
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995224#comment-15995224 ] Mike Drob commented on HBASE-13583: --- I think the easiest way to do this is going to be via the "gem-maven-plugin" to run jrubyc in the generate-source phase. > AOT compile our JRuby > - > > Key: HBASE-13583 > URL: https://issues.apache.org/jira/browse/HBASE-13583 > Project: HBase > Issue Type: Improvement > Components: build, scripts, shell >Reporter: Nick Dimiduk > > Our Jruby code seems to not keep up well with Java changes. We should > investigate adding a compilation step for our shell and the rb scripts in bin > to ensure they're calling methods that exist on classes that exist. This > looks like as good a starting point as any: > https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-13583) AOT compile our JRuby
[ https://issues.apache.org/jira/browse/HBASE-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14525584#comment-14525584 ] Lars Hofhansl commented on HBASE-13583: --- Should we also update our jruby? 1.6.x is ancient now. I know this comes up every now and then, and we always find reasons not to do it, but eventually we need to bite the bullet :) AOT compile our JRuby - Key: HBASE-13583 URL: https://issues.apache.org/jira/browse/HBASE-13583 Project: HBase Issue Type: Improvement Components: build, scripts, shell Reporter: Nick Dimiduk Our Jruby code seems to not keep up well with Java changes. We should investigate adding a compilation step for our shell and the rb scripts in bin to ensure they're calling methods that exist on classes that exist. This looks like as good a starting point as any: https://github.com/jruby/jruby/wiki/GeneratingJavaClasses -- This message was sent by Atlassian JIRA (v6.3.4#6332)
