Java8 + Eclipse Luna compiling byte code which is rejected by our Weaver

Description

Based on H2O stream bug report:

It seems Java8+Eclipse Luna providing slightly different byte code which is not processed by our Weaver.


initial email ----
Hi there,

I am trying compile H2O from Eclipse using the tutorial here:
http://h2o-release.s3.amazonaws.com/h2o/rel-lambert/5/docs-website/developuser/quickstart_eclipse.html

And I have a very strange error when trying to import a CSV file:

Caused by: java.lang.RuntimeException: water.fvec.C1NChunk must implement all of read(AutoBuffer) and write(AutoBuffer) and copyOver(Freezable) or none
at water.Weaver.ensureSerMethods(Weaver.java:398)
at water.Weaver.addSerializationMethods(Weaver.java:158)
at water.Weaver.javassistLoadClass(Weaver.java:134)
at water.Weaver.javassistLoadClass(Weaver.java:88)
at water.Weaver.weaveAndLoad(Weaver.java:60)
at water.Boot.loadClass2(Boot.java:420)
at water.Boot.loadClass(Boot.java:410)
at java.lang.ClassLoader.loadClass(Unknown Source)
at water.TestUtil.load_test_file(TestUtil.java:147)
at water.TestUtil.load_test_file(TestUtil.java:144)
at water.TestUtil.loadAndParseFile(TestUtil.java:151)
at samples.Sample04_Parse$UserCode.userMain(Sample04_Parse.java:18)
... 9 more

Looking at water.Weaver.ensureSerMethods(Weaver.java:398) it seams that C1NChunk doesnt have the read method defined right (although is defined in Iced).

Funny thing is that I remote debugged the default h2o.jar and of course there it works and C1NChunk signature has just one method more ... the right one .

I am not a very big speciallist in Javassist and it drives me crazy

Are there any compile stuff that I am missing?
------ 2. email
Ok ... so it seems is indeed from compilation

I use Oracle JDK 1.8.0_20 and Eclipse Luna on Windows 8.

When I compile from command line (using JDK javac) everything works well.

When I compile from Eclipse (which uses his internal compiler) things get screwed.

It seems that Eclipse strips some "unnecessary" bytecode from the .class and since you are checking the signature verbatim in ensureSerMethods ((Lwater/AutoBufferLwater/Freezable it will not find it.

Although it finds (Lwater/AutoBufferLwater.fvec.C1NChunk; but since this is just string comparison it will not detect that water.fvec.C1NChunk actually extends Freezable.

Anyway it seems that this is just unlucky me hitting this ... but you might wanna add a note to the Eclipse tutorial or something.

I don't know if Eclipse compiler is actually not 100% conform with JSRs or that method signature is actually not necessary so compilers can choose to strip it or not.

Cause if it's the later then the check hasExisting("read" , "(Lwater/AutoBufferLwater/Freezable;" , ccms); is actually not stable and can cause problems in the future (if other people will wanna compile with a different flavor of javac)


3rd email —
And again ... it seems to be related to the new Luna release of Eclipse (tested on Kepler and it works) .. and after a little digging it might be actually because of a bug or something in Eclipse Luna Compiler not generating well the bridge methods in the bytecode.

Are you using Luna? and I am so unlucky?

Assignee

Michal Malohlava

Reporter

Michal Malohlava

Labels

None

CustomerVisible

No

testcase 1

None

testcase 2

None

testcase 3

None

h2ostream link

None

Affected Spark version

None

AffectedContact

None

AffectedCustomers

None

AffectedPilots

None

AffectedOpenSource

None

Support Assessment

None

Customer Request Type

None

Support ticket URL

None

End date

None

Baseline start date

None

Baseline end date

None

Task progress

None

Task mode

None

Components

Priority

Major
Configure