You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by andrewcelerity <an...@celerityglobal.com> on 2014/12/12 16:48:00 UTC
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 Something<T extends SomeType> {
void doSomethingWith(T it);
}
class Foo implements Something<RealType> {
@Consume(uri = "...")
@Override
public void doSomethingWith(RealType it) {
.....
}
}
The class the compiler makes actually looks like this because of type
erasure:
class Foo implements Something<RealType> {
@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
Posted by Babak Vahdat <ba...@swissonline.ch>.
Am 22.12.14 15:49 schrieb "andrewcelerity" unter
<an...@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_code&node=5760638&code=YW5kcmV3QGNlbGVyaXR5Z2xvYmFsLmNvbXw1NzYwNj
>>M4fDE3MzQ0Njg1NDA=>.
>> NAML
>>
>><http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_v
>>iewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.B
>>asicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.te
>>mplate.NodeNamespace&breadcrumbs=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
Posted by andrewcelerity <an...@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?
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_code&node=5760638&code=YW5kcmV3QGNlbGVyaXR5Z2xvYmFsLmNvbXw1NzYwNjM4fDE3MzQ0Njg1NDA=>.
> NAML
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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
Posted by Babak Vahdat <ba...@swissonline.ch>.
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
--
View this message in context: http://camel.465427.n5.nabble.com/Changes-in-Java-8-generics-breaking-Camel-tp5760638p5760975.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Changes in Java 8 generics breaking Camel
Posted by andrewcelerity <an...@celerityglobal.com>.
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
Posted by Babak Vahdat <ba...@swissonline.ch>.
Am 15.12.14 14:38 schrieb "andrewcelerity" unter
<an...@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.
Re: Changes in Java 8 generics breaking Camel
Posted by Willem Jiang <wi...@gmail.com>.
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 (andrew@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
Posted by andrewcelerity <an...@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.
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
Posted by Babak Vahdat <ba...@swissonline.ch>.
Am 12.12.14 16:48 schrieb "andrewcelerity" unter
<an...@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 Something<T extends SomeType> {
> void doSomethingWith(T it);
>}
>
>class Foo implements Something<RealType> {
>
> @Consume(uri = "...")
> @Override
> public void doSomethingWith(RealType it) {
> .....
> }
>
>}
>
>The class the compiler makes actually looks like this because of type
>erasure:
>class Foo implements Something<RealType> {
>
> @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 Something<T extends Number> {
void doSomethingWith(T it);
}
class Foo implements Something<Long> {
@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.