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 ----
I am trying compile H2O from Eclipse using the tutorial here:
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 java.lang.ClassLoader.loadClass(Unknown Source)
... 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?