Camel
  1. Camel
  2. CAMEL-2167

Upgrade camel-scala to scala 2.8.0.RC6

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.4.0
    • Component/s: camel-scala
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      The attached patch upgrades to 2.8.0-SNAPSHOT (actually a specific version, but pretty close to today).

      Only a few changes were required:

      • Change package declarations to new 2.8 style that allows relative imports
      • Change org.apache.camel.scala.conveters.ScalaTypeConverter from a singleton object to a class. Otherwise ObjectHelper failed to instantiate the converter due to private access. (This could be 2.8 bug. I will need to raise an issue.)
      • Removed generic parameters on references to java classes that were not generic. Don't know why this compiled with scala 2.7.

        Activity

        Hide
        Hadrian Zbarcea added a comment -

        Thanks for pointing it out and especially for the patch!

        Show
        Hadrian Zbarcea added a comment - Thanks for pointing it out and especially for the patch!
        Hide
        Claus Ibsen added a comment -

        We have to wait to apply this one before 2.8 is GA as we dont want to have a situation where we cant release Camel 2.1

        Show
        Claus Ibsen added a comment - We have to wait to apply this one before 2.8 is GA as we dont want to have a situation where we cant release Camel 2.1
        Hide
        Barry Kaplan added a comment -

        2.8 is not byte code compatible with 2.7, so most likely there will be a need to support both version concurrently. I changed the pom to "camel-scala-2_8" to reflect this. But you might still want to wait until 2.8 is released as the compiler, language, and library is a daily moving target. In the meantime I will use the 2.8 version on my project.

        Show
        Barry Kaplan added a comment - 2.8 is not byte code compatible with 2.7, so most likely there will be a need to support both version concurrently. I changed the pom to "camel-scala-2_8" to reflect this. But you might still want to wait until 2.8 is released as the compiler, language, and library is a daily moving target. In the meantime I will use the 2.8 version on my project.
        Hide
        Claus Ibsen added a comment -

        Barry does camel-scala compile with success on your end with the latest code from trunk? i.e. using 2.8.

        All the cough ugly jdk generics warnings removal (eclipse must be a bad editor since it shows all these warnings) have gotten the scala compiler to throw an internal error

        Show
        Claus Ibsen added a comment - Barry does camel-scala compile with success on your end with the latest code from trunk? i.e. using 2.8. All the cough ugly jdk generics warnings removal (eclipse must be a bad editor since it shows all these warnings) have gotten the scala compiler to throw an internal error
        Hide
        Claus Ibsen added a comment -

        I have temporary disabled the camel-scala on trunk in rev: 835811.

        Show
        Claus Ibsen added a comment - I have temporary disabled the camel-scala on trunk in rev: 835811.
        Hide
        Barry Kaplan added a comment - - edited

        Yes, trunk crashes the compiler for me as well. What was changed? Wait, Its using 2.7.3, can't figure out why (yet...)

        Show
        Barry Kaplan added a comment - - edited Yes, trunk crashes the compiler for me as well. What was changed? Wait, Its using 2.7.3, can't figure out why (yet...)
        Hide
        Claus Ibsen added a comment -

        Its Hadrian's work on removing Eclipse warnings because it think that all code must be ugly Java 5 genericfied.

        Sorry but I am not keen on this work, Hadrian.
        Often makes code even harder to read and maintain because of using <> everywhere and ugly cast utils needed.

        I guess it makes compilers go crazy

        Show
        Claus Ibsen added a comment - Its Hadrian's work on removing Eclipse warnings because it think that all code must be ugly Java 5 genericfied. Sorry but I am not keen on this work, Hadrian. Often makes code even harder to read and maintain because of using <> everywhere and ugly cast utils needed. I guess it makes compilers go crazy
        Hide
        Claus Ibsen added a comment -

        Barry have you tried trunk code with 2.8.0 Scala compiler?

        Show
        Claus Ibsen added a comment - Barry have you tried trunk code with 2.8.0 Scala compiler?
        Hide
        Claus Ibsen added a comment -

        Barry trunk code now works with scala again

        Show
        Claus Ibsen added a comment - Barry trunk code now works with scala again
        Hide
        Barry Kaplan added a comment -

        Great! I've been out for some days. I'll give it a go. Thanks!

        Show
        Barry Kaplan added a comment - Great! I've been out for some days. I'll give it a go. Thanks!
        Hide
        Hadrian Zbarcea added a comment -

        @Claus, I understand how you feel and I share some of it myself. I got complaints about the ridiculous number of compiler warnings in Camel. Sometimes they hide real issues (and I found that in a couple of cases). I agonized over the decision if to go for it or not. It is indicative though of some level of maturity, or at least it creates a perception of it and I leaned towards biting the bullet.

        Sorry for breaking the scala component, my bad. I guess I owe you guys a beer. From the fact that you caught it so quickly it seems that you are following the cutting edge HEAD revision. Which probably means that... I owe you two beers . Many thanks!

        Show
        Hadrian Zbarcea added a comment - @Claus, I understand how you feel and I share some of it myself. I got complaints about the ridiculous number of compiler warnings in Camel. Sometimes they hide real issues (and I found that in a couple of cases). I agonized over the decision if to go for it or not. It is indicative though of some level of maturity, or at least it creates a perception of it and I leaned towards biting the bullet. Sorry for breaking the scala component, my bad. I guess I owe you guys a beer. From the fact that you caught it so quickly it seems that you are following the cutting edge HEAD revision. Which probably means that... I owe you two beers . Many thanks!
        Hide
        Barry Kaplan added a comment - - edited

        Claus when you say "trunk now works again" do you mean with 2.7? I am crashing scalac beta1-rc1 with my patches applied.

        And trying to figure out what the problem is quite hard since there are so many circular dependencies in camel-scala you can't compile one file a time.

        Show
        Barry Kaplan added a comment - - edited Claus when you say "trunk now works again" do you mean with 2.7? I am crashing scalac beta1-rc1 with my patches applied. And trying to figure out what the problem is quite hard since there are so many circular dependencies in camel-scala you can't compile one file a time.
        Hide
        Barry Kaplan added a comment - - edited

        Ah, well looks like its more java generics foo. Likely the self referentials, eg: "class ProcessorDefinition<Type extends org.apache.camel.model.ProcessorDefinition>".

        This going to be a slog. Here is one example:

        public abstract class OptionalIdentifiedDefinition<T extends OptionalIdentifiedDefinition> {..}
        
        public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition implements Block {..}
        

        The above compiles fine with just javac. But when scalac see's this (when trying to compile scala) it complains that ProcessorDefinition does not provide the type argument for OptionalIdentifiedDefinition. I only found this by extracting out just the type declarations into a separate project. In that small project scalac did not crash but provided the error message. In the camel-scala project scalac just barfs.

        rant begin I hate java generics. I hate java. After a couple years of only scala, groovy, ruby, and c# I had forgotten what an archaic, noisy language java is. rant end

        Show
        Barry Kaplan added a comment - - edited Ah, well looks like its more java generics foo. Likely the self referentials, eg: "class ProcessorDefinition<Type extends org.apache.camel.model.ProcessorDefinition>". This going to be a slog. Here is one example: public abstract class OptionalIdentifiedDefinition<T extends OptionalIdentifiedDefinition> {..} public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition implements Block {..} The above compiles fine with just javac. But when scalac see's this (when trying to compile scala) it complains that ProcessorDefinition does not provide the type argument for OptionalIdentifiedDefinition. I only found this by extracting out just the type declarations into a separate project. In that small project scalac did not crash but provided the error message. In the camel-scala project scalac just barfs. rant begin I hate java generics. I hate java. After a couple years of only scala, groovy, ruby, and c# I had forgotten what an archaic, noisy language java is. rant end
        Hide
        Barry Kaplan added a comment - - edited

        I don't even know what makes sense for ProcessorDefinitionclass above. I've tried:

        public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition<ProcessorDefinition> ...
        public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition<OptionalIdentifiedDefinition> ...
        public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition<Type> ...
        

        All of which compile with javac but none of which type check with scalac.

        Show
        Barry Kaplan added a comment - - edited I don't even know what makes sense for ProcessorDefinitionclass above. I've tried: public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition<ProcessorDefinition> ... public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition<OptionalIdentifiedDefinition> ... public abstract class ProcessorDefinition<Type extends ProcessorDefinition> extends OptionalIdentifiedDefinition<Type> ... All of which compile with javac but none of which type check with scalac.
        Hide
        Claus Ibsen added a comment -

        rant start
        Barry I am totally with you on java generics. Its a pain in the b*** to use when its used for a little more than just avoiding ugly type cast.

        And on other platforms AIX, HP-UX etc. code that compiles with SUN javac fails on these platforms. To bad they didnt implemented something that was easier and ligher. And got those closure in as well. As James Strachan says - javac is dying.
        rant end

        I have used scala 2.7.7 on trunk and I haven't seen any errors/warns. Do you see that on trunk? e.g without your patches etc.?

        Show
        Claus Ibsen added a comment - rant start Barry I am totally with you on java generics. Its a pain in the b*** to use when its used for a little more than just avoiding ugly type cast. And on other platforms AIX, HP-UX etc. code that compiles with SUN javac fails on these platforms. To bad they didnt implemented something that was easier and ligher. And got those closure in as well. As James Strachan says - javac is dying. rant end I have used scala 2.7.7 on trunk and I haven't seen any errors/warns. Do you see that on trunk? e.g without your patches etc.?
        Hide
        Barry Kaplan added a comment -

        Trunk compiles fine with 2.7.x. Since I get compiler crashes when I try to compile the entire module,
        probably there is a compiler bug lurking in there. I'll try to post the sample to the scala list and see if someone
        can make sense of what types are required or whether one of the ones I tried should have worked.

        In the meantime I'm gonna thunk down the java dsl so I can work with camel trunk.

        Show
        Barry Kaplan added a comment - Trunk compiles fine with 2.7.x. Since I get compiler crashes when I try to compile the entire module, probably there is a compiler bug lurking in there. I'll try to post the sample to the scala list and see if someone can make sense of what types are required or whether one of the ones I tried should have worked. In the meantime I'm gonna thunk down the java dsl so I can work with camel trunk.
        Hide
        Barry Kaplan added a comment -

        I think I've made a breakthru. In my sandbox (where I've created skeletons of some of the camel-core and camel-scala classes) I have gotten past what was causing the compiler to crash in the full build and generate type errors in the sandbox.

        (For this case at last) it was a mistake in the java generics:

        public class ExpressionNode extends ProcessorDefinition<ProcessorDefinition> {..}
        

        Should be:

        public class ExpressionNode extends ProcessorDefinition<ExpressionNode > {..}
        

        Which allowed this to type check:

        abstract class SAbstractDefinition[P <: ProcessorDefinition[_]] {..}
        
        case class SIdempotentConsumerDefinition(val target: IdempotentConsumerDefinition) extends SAbstractDefinition[IdempotentConsumerDefinition] {..}
        
        Show
        Barry Kaplan added a comment - I think I've made a breakthru. In my sandbox (where I've created skeletons of some of the camel-core and camel-scala classes) I have gotten past what was causing the compiler to crash in the full build and generate type errors in the sandbox. (For this case at last) it was a mistake in the java generics: public class ExpressionNode extends ProcessorDefinition<ProcessorDefinition> {..} Should be: public class ExpressionNode extends ProcessorDefinition<ExpressionNode > {..} Which allowed this to type check: abstract class SAbstractDefinition[P <: ProcessorDefinition[_]] {..} case class SIdempotentConsumerDefinition(val target: IdempotentConsumerDefinition) extends SAbstractDefinition[IdempotentConsumerDefinition] {..}
        Hide
        Claus Ibsen added a comment -

        Barry well spotted, those Java generics is like have/love combo.

        Show
        Claus Ibsen added a comment - Barry well spotted, those Java generics is like have/love combo.
        Hide
        Claus Ibsen added a comment -

        Barry I have committed a fix to trunk about that generics

        trunk: 886072.

        Show
        Claus Ibsen added a comment - Barry I have committed a fix to trunk about that generics trunk: 886072.
        Hide
        Claus Ibsen added a comment -

        I will put that to 2.3 as Scala 2.8 must be GA first

        Show
        Claus Ibsen added a comment - I will put that to 2.3 as Scala 2.8 must be GA first
        Hide
        Barry Kaplan added a comment -

        Ok. I'm still dropping the compiler so there may be more java generics to fix.
        But I'll try again with RC3 and see if fares any better.

        I wish I could get a small test to crash the compiler so I could file a compiler issue. But with a
        small test I get a reasonable error message. Only using the full camel-scala module do I
        get a compiler crash.

        Show
        Barry Kaplan added a comment - Ok. I'm still dropping the compiler so there may be more java generics to fix. But I'll try again with RC3 and see if fares any better. I wish I could get a small test to crash the compiler so I could file a compiler issue. But with a small test I get a reasonable error message. Only using the full camel-scala module do I get a compiler crash.
        Hide
        Gert Vanthienen added a comment - - edited

        Looks like the changes to the generics in the Java types together with the upgrade to the latest Scala 2.8.0.RC6 does work.
        Fixed in http://svn.apache.org/viewvc?view=revision&revision=957013

        Thanks to Hadrian and Barry for all the hard work in figuring these things out!

        Show
        Gert Vanthienen added a comment - - edited Looks like the changes to the generics in the Java types together with the upgrade to the latest Scala 2.8.0.RC6 does work. Fixed in http://svn.apache.org/viewvc?view=revision&revision=957013 Thanks to Hadrian and Barry for all the hard work in figuring these things out!
        Hide
        Claus Ibsen added a comment -

        Closing all resolved tickets from 2010 or older

        Show
        Claus Ibsen added a comment - Closing all resolved tickets from 2010 or older

          People

          • Assignee:
            Hadrian Zbarcea
            Reporter:
            Barry Kaplan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development