Re: Changes in Java 8 generics breaking Camel
I tested with the snapshot version and it works great. Thanks for the quick fix! What's the expected time for 2.14.2 to be a stable release? On 12/21/14, 8:16 AM, Babak Vahdat [via Camel] wrote: Hi Thanks for raising the ticket and providing the sample-app. The ticket is now fixed and your provided sample-app works on Java 8 as well. You’re welcome to test it by your “real-app” as well (either using the 2.14.2-SNAPSHOT or the master branch) and report us back if it would now work by your “real-app” on Java 8 as well. BTW all this is the side effect of: https://bugs.openjdk.java.net/browse/JDK-6695379 Babak andrewcelerity wrote I opened a Jira ticket and attached a sample app that replicates the problem. Hopefully it's an easy fix. https://issues.apache.org/jira/browse/CAMEL-8160 If you reply to this email, your message will be added to the discussion below: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638p5760975.html To unsubscribe from Changes in Java 8 generics breaking Camel, click here http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5760638code=YW5kcmV3QGNlbGVyaXR5Z2xvYmFsLmNvbXw1NzYwNjM4fDE3MzQ0Njg1NDA=. NAML http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638p5760990.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
Am 22.12.14 15:49 schrieb andrewcelerity unter and...@celerityglobal.com: I tested with the snapshot version and it works great. Thanks for the quick fix! What's the expected time for 2.14.2 to be a stable release? The 2.14.1 release was just announced last week and the patch releases are typically 3 months apart. So I guess the 2.14.2 release will be available around March 2015. Babak On 12/21/14, 8:16 AM, Babak Vahdat [via Camel] wrote: Hi Thanks for raising the ticket and providing the sample-app. The ticket is now fixed and your provided sample-app works on Java 8 as well. You¹re welcome to test it by your ³real-app² as well (either using the 2.14.2-SNAPSHOT or the master branch) and report us back if it would now work by your ³real-app² on Java 8 as well. BTW all this is the side effect of: https://bugs.openjdk.java.net/browse/JDK-6695379 Babak andrewcelerity wrote I opened a Jira ticket and attached a sample app that replicates the problem. Hopefully it's an easy fix. https://issues.apache.org/jira/browse/CAMEL-8160 If you reply to this email, your message will be added to the discussion below: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Cam el-tp5760638p5760975.html To unsubscribe from Changes in Java 8 generics breaking Camel, click here http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubsc ribe_by_codenode=5760638code=YW5kcmV3QGNlbGVyaXR5Z2xvYmFsLmNvbXw1NzYwNj M4fDE3MzQ0Njg1NDA=. NAML http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_v iewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.B asicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.te mplate.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml -instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail .naml -- View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Came l-tp5760638p5760990.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
I opened a Jira ticket and attached a sample app that replicates the problem. Hopefully it's an easy fix. https://issues.apache.org/jira/browse/CAMEL-8160 -- View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638p5760876.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
I am using Camel 2.14.0. I do see one problem, though maybe it's just a lack of understanding of the process you're using to compare results. Annotations like @Consume have a retention policy of runtime, meaning the compiler leaves them in the compiled class file (I believe). Your decompiled code does not show any annotations. I fully expect to see the same methods generated via Java 7 and 8, but the annotations on them should be different in the 8 generated byte code. -- View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638p5760703.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
Current Camel 2.14.0 is built with JDK7 and we run the CI with JDK8 and didn’t find the issue that you said. Can you create a JIRA and submit a test case for it? -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On December 15, 2014 at 9:39:22 PM, andrewcelerity (and...@celerityglobal.com) wrote: I am using Camel 2.14.0. I do see one problem, though maybe it's just a lack of understanding of the process you're using to compare results. Annotations like @Consume have a retention policy of runtime, meaning the compiler leaves them in the compiled class file (I believe). Your decompiled code does not show any annotations. I fully expect to see the same methods generated via Java 7 and 8, but the annotations on them should be different in the 8 generated byte code. -- View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638p5760703.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
Am 15.12.14 14:38 schrieb andrewcelerity unter and...@celerityglobal.com: I am using Camel 2.14.0. I do see one problem, though maybe it's just a lack of understanding of the process you're using to compare results. Annotations like @Consume have a retention policy of runtime, meaning the compiler leaves them in the compiled class file (I believe). Your decompiled code does not show any annotations. Well spotted. I used jad to decompile Foo.class: http://varaneckas.com/jad Which apparently did not take the @Consume annotation into the account, don't know why. That said using JAD produced the expected @Consume annotated method: http://jd.benow.ca But as Willem has already said it could help us if you would provide a concrete code showing the problem in Java 8, like some compilation errors or a failing test in Java 8 which works properly in Java 7 and what not. Then we could nail down the problem in case there¹s any. Babak I fully expect to see the same methods generated via Java 7 and 8, but the annotations on them should be different in the 8 generated byte code. -- View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Came l-tp5760638p5760703.html Sent from the Camel - Users mailing list archive at Nabble.com.
Changes in Java 8 generics breaking Camel
Java 8 made a changes to generics that is currently not allowing camel to
start up, and if it did start up would be in a bad state. Bridge methods
now get a copy of the annotations placed on the real method. This is bad
when combined with Camel annotations. For example:
interface SomethingT extends SomeType {
void doSomethingWith(T it);
}
class Foo implements SomethingRealType {
@Consume(uri = ...)
@Override
public void doSomethingWith(RealType it) {
.
}
}
The class the compiler makes actually looks like this because of type
erasure:
class Foo implements SomethingRealType {
@Consume(uri = ...)
@Override
public void doSomethingWith(RealType it) {
.
}
@Consume(uri = ...)
@Override
public void doSomethingWith(SomeType it) {
.
}
}
This is a breaking change as far as Camel is concered for 2 reasons:
1. BeanInfo.isValidMethod does not allow for bridge methods
2. There are now 2 methods listening to the same endpoint
Is this a bug that should be reported? Any ideas on a workaround? I'm
about to downgrade to java 7.
--
View this message in context:
http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
Am 12.12.14 16:48 schrieb andrewcelerity unter
and...@celerityglobal.com:
Java 8 made a changes to generics that is currently not allowing camel to
start up, and if it did start up would be in a bad state. Bridge methods
now get a copy of the annotations placed on the real method. This is bad
when combined with Camel annotations. For example:
interface SomethingT extends SomeType {
void doSomethingWith(T it);
}
class Foo implements SomethingRealType {
@Consume(uri = ...)
@Override
public void doSomethingWith(RealType it) {
.
}
}
The class the compiler makes actually looks like this because of type
erasure:
class Foo implements SomethingRealType {
@Consume(uri = ...)
@Override
public void doSomethingWith(RealType it) {
.
}
@Consume(uri = ...)
@Override
public void doSomethingWith(SomeType it) {
.
}
}
This is a breaking change as far as Camel is concered for 2 reasons:
1. BeanInfo.isValidMethod does not allow for bridge methods
2. There are now 2 methods listening to the same endpoint
Is this a bug that should be reported? Any ideas on a workaround? I'm
about to downgrade to java 7.
Hi
Which Camel version do you use? Java 8 support is given from Camel 2.14.x
onwards.
That said, I'm not sure if there's really any difference by the generated
byte code as you claim no matter if Java 7 or 8 is in use. With the
following source:
import org.apache.camel.Consume;
interface SomethingT extends Number {
void doSomethingWith(T it);
}
class Foo implements SomethingLong {
@Consume(uri = direct:start)
@Override
public void doSomethingWith(Long it) {
}
}
Now decompiling the class file for the source above, no matter if Java 7
or 8 compiler is in use, you get the *same* decompiled source out of the
byte code, which is:
class Foo
implements Something
{
Foo()
{
}
public void doSomethingWith(Long long1)
{
}
public volatile void doSomethingWith(Number number)
{
doSomethingWith((Long)number);
}
}
Note that all the Java generics sugar inside the byte code is gone. So
unter the hut the generated byte code is exactly the same. And when you
would do
myFoo.doSomethingWith(3L);
inside your Java source code, the compiler does call the second method
above (the one with Number as the argument type). And the cast to type
Long inside the byte code above is guaranteed to succeed *if* you don't
have any unchecked/type safety warnings while compiling the source
(assuming no @SuppressWarnings is in use).
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Came
l-tp5760638.html
Sent from the Camel - Users mailing list archive at Nabble.com.
