[smx5] Scala based (was Re: Profiling stragegy)

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[smx5] Scala based (was Re: Profiling stragegy)

Guillaume Nodet
Administrator
Yeah, definitely.  I don't think we've really discussed that point.   I used
scala for the following reasons right now:
  * the manual / web console (almost empty now) are based on scalate which
is focusing on scala
  * it forces me to learn Scala ;-)

I agree we need to make sure we all agree on which direction to go.
I don't have much knowledge of Scala yet so I'm far less productive than
when using Java right now (I guess a lot of us are newbies too).

I was going to try finding benefits and list them, but I just came across
James's blog entry:

http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
In short, Scala is just a better language I think.  How long will we have to
wait for java closures?  And even when they come, it will be in Java 7 or 8
which we won't be able to use until a few years.

Anyway, I know I'll be a little less productive at least for a few months,
but I think the long term benefits are greater than the cost.

On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré <[hidden email]> wrote:

> Hi Guillaume,
>
> thanks a bunch, it looks very good.
>
> I see that you implemented in Scala.
>
> Does it mean that SMX5 will by Scala based ?
> We had discussion on the mailing list around that but I didn't see an
> agreement about that.
>
> Maybe, we should start a vote to see if the community is ready to go to
> Scala for SMX.
>
> WDYT ?
>
> Regards
> JB
>
>
> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>
>> I've been experimenting with a first value added feature for camel routes
>> deployed in smx5.
>> The idea is to have a profiling strategy similar to a java profiler.
>> The output I have in my test is the following:
>>
>> Processor                                  Count     Time    Total
>> Route[[From[direct:a]] ->  [To[mock:p...]       0        0     3536
>>  To[mock:polyglot]                          1000      149      149
>>  Choice[[When[{org.apache.**camel.sca...]     1000       63     3386
>>    When[{org.apache.camel.scala.**Sca...]     1000     2208     2277
>>      To[mock:english]                        328       69       69
>>    When[{org.apache.camel.scala.**Sca...]      672       74      976
>>      To[mock:dutch]                          339       74       74
>>      Delay[{2} ->  []]                        339      727      727
>>      To[mock:german]                         339      100      100
>>    Otherwise[[To[mock:french]]]              333        8       69
>>      To[mock:french]                         333       60       60
>>
>>
>> And the route is defined using the scala DSL as:
>>
>>     context.addRoutes(new RouteBuilder {
>>       "direct:a" ==>  {
>>         to("mock:polyglot")
>>         choice {
>>           when( (e: Exchange) =>  { sleep(); e.in == "<hello/>" }) {
>>             to ("mock:english")
>>           }
>>           when(_.in == "<hallo/>") {
>>             to("mock:dutch")
>>             delay( 2 ms )
>>             to("mock:german")
>>           }
>>           otherwise to ("mock:french")
>>         }
>>       }
>>     });
>>
>> This currently requires some modifications to camel which I've done
>> locally,
>> so you won't really be able to experiment with it at this point, but I
>> just
>> wanted to give a heads up, as I found this feature quite interesting.
>>
>>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Jean-Baptiste Onofré
Thanks Guillaume for the pointer and explanation.

Before voting, I'm going to read the James' blog, review your code, and
a quick try by myself.

I would like to evaluate also what is the impact in term of Apache/IT:
maven, hudson/jenkins continuous integration, etc.

I will send my vote asap :)

Thanks again
Regards
JB

On 07/08/2011 10:12 AM, Guillaume Nodet wrote:

> Yeah, definitely.  I don't think we've really discussed that point.   I used
> scala for the following reasons right now:
>    * the manual / web console (almost empty now) are based on scalate which
> is focusing on scala
>    * it forces me to learn Scala ;-)
>
> I agree we need to make sure we all agree on which direction to go.
> I don't have much knowledge of Scala yet so I'm far less productive than
> when using Java right now (I guess a lot of us are newbies too).
>
> I was going to try finding benefits and list them, but I just came across
> James's blog entry:
>
> http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
> In short, Scala is just a better language I think.  How long will we have to
> wait for java closures?  And even when they come, it will be in Java 7 or 8
> which we won't be able to use until a few years.
>
> Anyway, I know I'll be a little less productive at least for a few months,
> but I think the long term benefits are greater than the cost.
>
> On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré<[hidden email]>  wrote:
>
>> Hi Guillaume,
>>
>> thanks a bunch, it looks very good.
>>
>> I see that you implemented in Scala.
>>
>> Does it mean that SMX5 will by Scala based ?
>> We had discussion on the mailing list around that but I didn't see an
>> agreement about that.
>>
>> Maybe, we should start a vote to see if the community is ready to go to
>> Scala for SMX.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>>
>>> I've been experimenting with a first value added feature for camel routes
>>> deployed in smx5.
>>> The idea is to have a profiling strategy similar to a java profiler.
>>> The output I have in my test is the following:
>>>
>>> Processor                                  Count     Time    Total
>>> Route[[From[direct:a]] ->   [To[mock:p...]       0        0     3536
>>>   To[mock:polyglot]                          1000      149      149
>>>   Choice[[When[{org.apache.**camel.sca...]     1000       63     3386
>>>     When[{org.apache.camel.scala.**Sca...]     1000     2208     2277
>>>       To[mock:english]                        328       69       69
>>>     When[{org.apache.camel.scala.**Sca...]      672       74      976
>>>       To[mock:dutch]                          339       74       74
>>>       Delay[{2} ->   []]                        339      727      727
>>>       To[mock:german]                         339      100      100
>>>     Otherwise[[To[mock:french]]]              333        8       69
>>>       To[mock:french]                         333       60       60
>>>
>>>
>>> And the route is defined using the scala DSL as:
>>>
>>>      context.addRoutes(new RouteBuilder {
>>>        "direct:a" ==>   {
>>>          to("mock:polyglot")
>>>          choice {
>>>            when( (e: Exchange) =>   { sleep(); e.in == "<hello/>" }) {
>>>              to ("mock:english")
>>>            }
>>>            when(_.in == "<hallo/>") {
>>>              to("mock:dutch")
>>>              delay( 2 ms )
>>>              to("mock:german")
>>>            }
>>>            otherwise to ("mock:french")
>>>          }
>>>        }
>>>      });
>>>
>>> This currently requires some modifications to camel which I've done
>>> locally,
>>> so you won't really be able to experiment with it at this point, but I
>>> just
>>> wanted to give a heads up, as I found this feature quite interesting.
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Guillaume Nodet
Administrator
On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré <[hidden email]> wrote:

> Thanks Guillaume for the pointer and explanation.
>
> Before voting, I'm going to read the James' blog, review your code, and a
> quick try by myself.
>
> I would like to evaluate also what is the impact in term of Apache/IT:
> maven, hudson/jenkins continuous integration, etc.
>

This has no impact afaik, it's just a different maven plugin.   Also note
that the scala compiler can actually compile java code at the same time, so
you can mix scala and java in the same project without any problems.


>
> I will send my vote asap :)
>
> Thanks again
> Regards
> JB
>
>
> On 07/08/2011 10:12 AM, Guillaume Nodet wrote:
>
>> Yeah, definitely.  I don't think we've really discussed that point.   I
>> used
>> scala for the following reasons right now:
>>   * the manual / web console (almost empty now) are based on scalate which
>> is focusing on scala
>>   * it forces me to learn Scala ;-)
>>
>> I agree we need to make sure we all agree on which direction to go.
>> I don't have much knowledge of Scala yet so I'm far less productive than
>> when using Java right now (I guess a lot of us are newbies too).
>>
>> I was going to try finding benefits and list them, but I just came across
>> James's blog entry:
>>
>> http://macstrac.blogspot.com/**2009/04/scala-as-long-term-**
>> replacement-for.html<http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html>
>> In short, Scala is just a better language I think.  How long will we have
>> to
>> wait for java closures?  And even when they come, it will be in Java 7 or
>> 8
>> which we won't be able to use until a few years.
>>
>> Anyway, I know I'll be a little less productive at least for a few months,
>> but I think the long term benefits are greater than the cost.
>>
>> On Fri, Jul 8, 2011 at 09:59, Jean-Baptiste Onofré<[hidden email]>
>>  wrote:
>>
>>  Hi Guillaume,
>>>
>>> thanks a bunch, it looks very good.
>>>
>>> I see that you implemented in Scala.
>>>
>>> Does it mean that SMX5 will by Scala based ?
>>> We had discussion on the mailing list around that but I didn't see an
>>> agreement about that.
>>>
>>> Maybe, we should start a vote to see if the community is ready to go to
>>> Scala for SMX.
>>>
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 07/08/2011 09:56 AM, Guillaume Nodet wrote:
>>>
>>>  I've been experimenting with a first value added feature for camel
>>>> routes
>>>> deployed in smx5.
>>>> The idea is to have a profiling strategy similar to a java profiler.
>>>> The output I have in my test is the following:
>>>>
>>>> Processor                                  Count     Time    Total
>>>> Route[[From[direct:a]] ->   [To[mock:p...]       0        0     3536
>>>>  To[mock:polyglot]                          1000      149      149
>>>>  Choice[[When[{org.apache.****camel.sca...]     1000       63     3386
>>>>    When[{org.apache.camel.scala.****Sca...]     1000     2208     2277
>>>>      To[mock:english]                        328       69       69
>>>>    When[{org.apache.camel.scala.****Sca...]      672       74      976
>>>>      To[mock:dutch]                          339       74       74
>>>>      Delay[{2} ->   []]                        339      727      727
>>>>      To[mock:german]                         339      100      100
>>>>    Otherwise[[To[mock:french]]]              333        8       69
>>>>      To[mock:french]                         333       60       60
>>>>
>>>>
>>>> And the route is defined using the scala DSL as:
>>>>
>>>>     context.addRoutes(new RouteBuilder {
>>>>       "direct:a" ==>   {
>>>>         to("mock:polyglot")
>>>>         choice {
>>>>           when( (e: Exchange) =>   { sleep(); e.in == "<hello/>" }) {
>>>>             to ("mock:english")
>>>>           }
>>>>           when(_.in == "<hallo/>") {
>>>>             to("mock:dutch")
>>>>             delay( 2 ms )
>>>>             to("mock:german")
>>>>           }
>>>>           otherwise to ("mock:french")
>>>>         }
>>>>       }
>>>>     });
>>>>
>>>> This currently requires some modifications to camel which I've done
>>>> locally,
>>>> so you won't really be able to experiment with it at this point, but I
>>>> just
>>>> wanted to give a heads up, as I found this feature quite interesting.
>>>>
>>>>
>>>>  --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
On 8 July 2011 09:31, Guillaume Nodet <[hidden email]> wrote:

> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré <[hidden email]> wrote:
>
>> Thanks Guillaume for the pointer and explanation.
>>
>> Before voting, I'm going to read the James' blog, review your code, and a
>> quick try by myself.
>>
>> I would like to evaluate also what is the impact in term of Apache/IT:
>> maven, hudson/jenkins continuous integration, etc.
>>
>
> This has no impact afaik, it's just a different maven plugin.   Also note
> that the scala compiler can actually compile java code at the same time, so
> you can mix scala and java in the same project without any problems.

Agreed. For an example of a project thats working at Apache using Java
and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
just released
http://activemq.apache.org/apollo/

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

iocanel
In reply to this post by Guillaume Nodet
I like the idea of using Scala inside ServiceMix for the reason its just a
better language than Java, which you can use without sacrificing any of the
Java coolness *(in terms of tools frameworks etc)*.

I've only used Scala once, in a tiny web application combined with Apache
Wicket and I can say that the result was great as the boilerplate was
significantly reduced.

I am definitely no expert, but I'd love to use Scala in ServiceMix5.

--
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*
Ioannis Canellos
http://iocanel.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Jean-Baptiste Onofré
In reply to this post by James Strachan
Thanks James and Guillaume for your advice :)

Let me take a look on all these resources :)

Regards
JB

On 07/08/2011 10:43 AM, James Strachan wrote:

> On 8 July 2011 09:31, Guillaume Nodet<[hidden email]>  wrote:
>> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré<[hidden email]>  wrote:
>>
>>> Thanks Guillaume for the pointer and explanation.
>>>
>>> Before voting, I'm going to read the James' blog, review your code, and a
>>> quick try by myself.
>>>
>>> I would like to evaluate also what is the impact in term of Apache/IT:
>>> maven, hudson/jenkins continuous integration, etc.
>>>
>>
>> This has no impact afaik, it's just a different maven plugin.   Also note
>> that the scala compiler can actually compile java code at the same time, so
>> you can mix scala and java in the same project without any problems.
>
> Agreed. For an example of a project thats working at Apache using Java
> and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
> just released
> http://activemq.apache.org/apollo/
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
BTW the main reason for using Scala on ActiveMQ Apollo wasn't just to
get a 'better Java' - it was to avoid loads of inefficient
synchronized blocks which are very easy to deadlock leading to really
hairy asynchronous code thats a nightmare to edit & maintain - you can
use much simpler code to read & write using the Scala block structure
- in much the same way as the Scala / ScalaZ DSLs for Camel are much
easier to read and write and don't have the block syntax smells that
the Java DSL has (the java .begin() and .end() calls for example).

For any kind of concurrent or asynchronous code this is a massive win
(never mind the amazing collections library, function composition,
pattern matching, type inference, traits, arrays actually being useful
and nice to use and huge lack of boilerplate).

In Scala things like HawtDispatch or Scala / Akka
actors/futures/promises can be used to simplify things like
asynchronous coding...
http://hawtdispatch.fusesource.org/
http://akka.io/


On 8 July 2011 09:47, Jean-Baptiste Onofré <[hidden email]> wrote:

> Thanks James and Guillaume for your advice :)
>
> Let me take a look on all these resources :)
>
> Regards
> JB
>
> On 07/08/2011 10:43 AM, James Strachan wrote:
>>
>> On 8 July 2011 09:31, Guillaume Nodet<[hidden email]>  wrote:
>>>
>>> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré<[hidden email]>
>>>  wrote:
>>>
>>>> Thanks Guillaume for the pointer and explanation.
>>>>
>>>> Before voting, I'm going to read the James' blog, review your code, and
>>>> a
>>>> quick try by myself.
>>>>
>>>> I would like to evaluate also what is the impact in term of Apache/IT:
>>>> maven, hudson/jenkins continuous integration, etc.
>>>>
>>>
>>> This has no impact afaik, it's just a different maven plugin.   Also note
>>> that the scala compiler can actually compile java code at the same time,
>>> so
>>> you can mix scala and java in the same project without any problems.
>>
>> Agreed. For an example of a project thats working at Apache using Java
>> and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
>> just released
>> http://activemq.apache.org/apollo/
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Jean-Baptiste Onofré
In reply to this post by iocanel
 From a pure technical point of view, it can be very interesting and
fun. Of course, we need some time at the beginning, but it's not a big deal.

My concern is more for users/customers: I do not want to scare them by
mixing Java/Scala, or going only to Scala which is not really heavily
known in the industry for now.

As we said in French: "j'ai le cul entre deux chaises" (which can be
translated by "I ass between two chairs" :)).

I would like more time to send my formal vote :)

Regards
JB

On 07/08/2011 10:47 AM, Ioannis Canellos wrote:

> I like the idea of using Scala inside ServiceMix for the reason its just a
> better language than Java, which you can use without sacrificing any of the
> Java coolness *(in terms of tools frameworks etc)*.
>
> I've only used Scala once, in a tiny web application combined with Apache
> Wicket and I can say that the result was great as the boilerplate was
> significantly reduced.
>
> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Charles Moulliard
In reply to this post by James Strachan
Hi,

Before to take the decision to use or not scala, we should also
considering the impact of this choice for our users/committers
community and customers. Are they ready to use a Scala project or a
Apache project combining scala + java ? What will be the reaction of
certain committers not interested for developing in Scala language ?
We could potentially close the doors to new users/committers
interested by SMX5. BTW, this could be transparent for people in
charge to operate SMX5 platform but what will be their reaction when
developer will ask to start a profiler tool on SMX5 or to debug
remotely. Times are changing and Java language also Do we have to
consider to abandon Java simply because Scala offers some better
options to resolve asynch, ... Java has been adopted as "Enterprise"
language but I'm not sure that this is the case right now for Scala
which exist since 10 years

Regards,

Charles Moulliard

Apache Committer

Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard



On Fri, Jul 8, 2011 at 11:03 AM, James Strachan <[hidden email]> wrote:

> BTW the main reason for using Scala on ActiveMQ Apollo wasn't just to
> get a 'better Java' - it was to avoid loads of inefficient
> synchronized blocks which are very easy to deadlock leading to really
> hairy asynchronous code thats a nightmare to edit & maintain - you can
> use much simpler code to read & write using the Scala block structure
> - in much the same way as the Scala / ScalaZ DSLs for Camel are much
> easier to read and write and don't have the block syntax smells that
> the Java DSL has (the java .begin() and .end() calls for example).
>
> For any kind of concurrent or asynchronous code this is a massive win
> (never mind the amazing collections library, function composition,
> pattern matching, type inference, traits, arrays actually being useful
> and nice to use and huge lack of boilerplate).
>
> In Scala things like HawtDispatch or Scala / Akka
> actors/futures/promises can be used to simplify things like
> asynchronous coding...
> http://hawtdispatch.fusesource.org/
> http://akka.io/
>
>
> On 8 July 2011 09:47, Jean-Baptiste Onofré <[hidden email]> wrote:
>> Thanks James and Guillaume for your advice :)
>>
>> Let me take a look on all these resources :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:43 AM, James Strachan wrote:
>>>
>>> On 8 July 2011 09:31, Guillaume Nodet<[hidden email]>  wrote:
>>>>
>>>> On Fri, Jul 8, 2011 at 10:24, Jean-Baptiste Onofré<[hidden email]>
>>>>  wrote:
>>>>
>>>>> Thanks Guillaume for the pointer and explanation.
>>>>>
>>>>> Before voting, I'm going to read the James' blog, review your code, and
>>>>> a
>>>>> quick try by myself.
>>>>>
>>>>> I would like to evaluate also what is the impact in term of Apache/IT:
>>>>> maven, hudson/jenkins continuous integration, etc.
>>>>>
>>>>
>>>> This has no impact afaik, it's just a different maven plugin.   Also note
>>>> that the scala compiler can actually compile java code at the same time,
>>>> so
>>>> you can mix scala and java in the same project without any problems.
>>>
>>> Agreed. For an example of a project thats working at Apache using Java
>>> and Scala together, check out ActiveMQ Apollo which 1.0-beta 4 was
>>> just released
>>> http://activemq.apache.org/apollo/
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
In reply to this post by Jean-Baptiste Onofré
How would a user/customer know what tools where used to create
servicemix 5? So long as its available as jars/bundles and there's a
web console, who cares if there's JSP or XSLT or Java or Scala or
Scalate or whatever?

On 8 July 2011 11:14, Jean-Baptiste Onofré <[hidden email]> wrote:

> From a pure technical point of view, it can be very interesting and fun. Of
> course, we need some time at the beginning, but it's not a big deal.
>
> My concern is more for users/customers: I do not want to scare them by
> mixing Java/Scala, or going only to Scala which is not really heavily known
> in the industry for now.
>
> As we said in French: "j'ai le cul entre deux chaises" (which can be
> translated by "I ass between two chairs" :)).
>
> I would like more time to send my formal vote :)
>
> Regards
> JB
>
> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>
>> I like the idea of using Scala inside ServiceMix for the reason its just a
>> better language than Java, which you can use without sacrificing any of
>> the
>> Java coolness *(in terms of tools frameworks etc)*.
>>
>> I've only used Scala once, in a tiny web application combined with Apache
>> Wicket and I can say that the result was great as the boilerplate was
>> significantly reduced.
>>
>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Jean-Baptiste Onofré
+1 James

I just try to expose the thoughts that come in my mind :)
Just to share together and list to pros/cons.

Thanks
Regards
JB

On 07/08/2011 12:19 PM, James Strachan wrote:

> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré<[hidden email]>  wrote:
>>  From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
In reply to this post by James Strachan
To be a little more clear - the only risk from a user perspective of
using Scala is not having nice Java APIs for Java developers to use.
But as HawtDispatch & Akka have shown; its easy to have great Java and
Scala APIs to frameworks.

However for implementation stuff, users wouldn't really know how the
Java bytecode was created unless they decompiled it or grep'd your
source code :). Its all just java bytecode in jars/bundles/wars.

On 8 July 2011 11:19, James Strachan <[hidden email]> wrote:

> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré <[hidden email]> wrote:
>> From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>



--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
In reply to this post by Jean-Baptiste Onofré
+1 for everyone exposing their concerns, thanks JB :)

On 8 July 2011 11:22, Jean-Baptiste Onofré <[hidden email]> wrote:

> +1 James
>
> I just try to expose the thoughts that come in my mind :)
> Just to share together and list to pros/cons.
>
> Thanks
> Regards
> JB
>
> On 07/08/2011 12:19 PM, James Strachan wrote:
>>
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré<[hidden email]>  wrote:
>>>
>>>  From a pure technical point of view, it can be very interesting and fun.
>>> Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily
>>> known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just
>>>> a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with
>>>> Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Claus Ibsen-2
In reply to this post by James Strachan
Have some pieces that are Scala could in fact attract new great
contributors/committers to the project.

If we keep using the good old dusty Java then the new generations of
great minds may not be so reluctant to start contributing.

However when using Scala we should bite this piece by piece.
And try to avoid adding to advanced code from the very start, so the
less trained eye do have a clue whats going on.



On Fri, Jul 8, 2011 at 12:23 PM, James Strachan <[hidden email]> wrote:

> To be a little more clear - the only risk from a user perspective of
> using Scala is not having nice Java APIs for Java developers to use.
> But as HawtDispatch & Akka have shown; its easy to have great Java and
> Scala APIs to frameworks.
>
> However for implementation stuff, users wouldn't really know how the
> Java bytecode was created unless they decompiled it or grep'd your
> source code :). Its all just java bytecode in jars/bundles/wars.
>
> On 8 July 2011 11:19, James Strachan <[hidden email]> wrote:
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré <[hidden email]> wrote:
>>> From a pure technical point of view, it can be very interesting and fun. Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>



--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Jean-Baptiste Onofré
In reply to this post by James Strachan
James,

I found this blog:
http://kotek.net/blog/scala_problems

WDYT ?

Especially around the size of the jar.

Doesn't it in "opposition" with the OSGi granularity ?

Regards
JB

On 07/08/2011 12:19 PM, James Strachan wrote:

> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré<[hidden email]>  wrote:
>>  From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Charles Moulliard
In reply to this post by James Strachan
You are right except that what we will deploy will be Java bundles
coming from projects. That means that when debugging will be required,
that will complicate the process as we have to debug java codes and
perhaps (this is what we do now under SMX/Karaf) classes of the
platform itself who will be in Scala (with SMX5). From this
perspective, our users will be impacted by this choice and some of
them will be reluctant.

just 2 cents for the discussion.

On Fri, Jul 8, 2011 at 12:19 PM, James Strachan <[hidden email]> wrote:

> How would a user/customer know what tools where used to create
> servicemix 5? So long as its available as jars/bundles and there's a
> web console, who cares if there's JSP or XSLT or Java or Scala or
> Scalate or whatever?
>
> On 8 July 2011 11:14, Jean-Baptiste Onofré <[hidden email]> wrote:
>> From a pure technical point of view, it can be very interesting and fun. Of
>> course, we need some time at the beginning, but it's not a big deal.
>>
>> My concern is more for users/customers: I do not want to scare them by
>> mixing Java/Scala, or going only to Scala which is not really heavily known
>> in the industry for now.
>>
>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>> translated by "I ass between two chairs" :)).
>>
>> I would like more time to send my formal vote :)
>>
>> Regards
>> JB
>>
>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>
>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>> better language than Java, which you can use without sacrificing any of
>>> the
>>> Java coolness *(in terms of tools frameworks etc)*.
>>>
>>> I've only used Scala once, in a tiny web application combined with Apache
>>> Wicket and I can say that the result was great as the boilerplate was
>>> significantly reduced.
>>>
>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
You'd need a Scala IDE (IDEA / Eclipse + Scala plugin) but debugging
works fine - so long as you've the source or map to where the source
is.

On 8 July 2011 11:31, Charles Moulliard <[hidden email]> wrote:

> You are right except that what we will deploy will be Java bundles
> coming from projects. That means that when debugging will be required,
> that will complicate the process as we have to debug java codes and
> perhaps (this is what we do now under SMX/Karaf) classes of the
> platform itself who will be in Scala (with SMX5). From this
> perspective, our users will be impacted by this choice and some of
> them will be reluctant.
>
> just 2 cents for the discussion.
>
> On Fri, Jul 8, 2011 at 12:19 PM, James Strachan <[hidden email]> wrote:
>> How would a user/customer know what tools where used to create
>> servicemix 5? So long as its available as jars/bundles and there's a
>> web console, who cares if there's JSP or XSLT or Java or Scala or
>> Scalate or whatever?
>>
>> On 8 July 2011 11:14, Jean-Baptiste Onofré <[hidden email]> wrote:
>>> From a pure technical point of view, it can be very interesting and fun. Of
>>> course, we need some time at the beginning, but it's not a big deal.
>>>
>>> My concern is more for users/customers: I do not want to scare them by
>>> mixing Java/Scala, or going only to Scala which is not really heavily known
>>> in the industry for now.
>>>
>>> As we said in French: "j'ai le cul entre deux chaises" (which can be
>>> translated by "I ass between two chairs" :)).
>>>
>>> I would like more time to send my formal vote :)
>>>
>>> Regards
>>> JB
>>>
>>> On 07/08/2011 10:47 AM, Ioannis Canellos wrote:
>>>>
>>>> I like the idea of using Scala inside ServiceMix for the reason its just a
>>>> better language than Java, which you can use without sacrificing any of
>>>> the
>>>> Java coolness *(in terms of tools frameworks etc)*.
>>>>
>>>> I've only used Scala once, in a tiny web application combined with Apache
>>>> Wicket and I can say that the result was great as the boilerplate was
>>>> significantly reduced.
>>>>
>>>> I am definitely no expert, but I'd love to use Scala in ServiceMix5.
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>



--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

James Strachan
In reply to this post by Jean-Baptiste Onofré
On 8 July 2011 11:29, Jean-Baptiste Onofré <[hidden email]> wrote:
> James,
>
> I found this blog:
> http://kotek.net/blog/scala_problems
>
> WDYT ?

Most of the issues are old (e.g. old versions of scala kept breaking
bytecode compatibility, something OSGi can help you with anyway) or
tooling issues. See the comments - e.g. use SBT / FSC option in your
IDE. I use IDEA with Scala with FST on and its pretty fast and snappy.

Using SBT in incremental compile/test mode on 0.10 is now *much
faster* than using maven and java :). As you change a line of code in
your IDE everything recompiles & reruns really quickly.


> Especially around the size of the jar.
>
> Doesn't it in "opposition" with the OSGi granularity ?

Am not really sure if the exact size of a jar file is much of a
concern in the grand scheme of things; it certainly doesn't affect
granularity at least. That being said, sure Scala uses more classes in
the generated bytecode (as does Java 8's closures & java 4's inner
classes), but then the Scala library replaces a ton of boilerplate
bytecode operations you have to do in Java for doing
loops/mapping/transforming/filtering of code so its probably a case
that you use much less actual code and less helper classes (often
copied randomly from project to project) and libraries (google
collections v common collections v guava v all the other java
libraries attempting to make collections more palatable in Java).

Though if you're ever worried about jar sizes for Scala or Java,
there's always ProGuard to trim dead code.

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Jean-Baptiste Onofré
Thanks for the update James.

It's more clear :)

Regards
JB

On 07/08/2011 01:27 PM, James Strachan wrote:

> On 8 July 2011 11:29, Jean-Baptiste Onofré<[hidden email]>  wrote:
>> James,
>>
>> I found this blog:
>> http://kotek.net/blog/scala_problems
>>
>> WDYT ?
>
> Most of the issues are old (e.g. old versions of scala kept breaking
> bytecode compatibility, something OSGi can help you with anyway) or
> tooling issues. See the comments - e.g. use SBT / FSC option in your
> IDE. I use IDEA with Scala with FST on and its pretty fast and snappy.
>
> Using SBT in incremental compile/test mode on 0.10 is now *much
> faster* than using maven and java :). As you change a line of code in
> your IDE everything recompiles&  reruns really quickly.
>
>
>> Especially around the size of the jar.
>>
>> Doesn't it in "opposition" with the OSGi granularity ?
>
> Am not really sure if the exact size of a jar file is much of a
> concern in the grand scheme of things; it certainly doesn't affect
> granularity at least. That being said, sure Scala uses more classes in
> the generated bytecode (as does Java 8's closures&  java 4's inner
> classes), but then the Scala library replaces a ton of boilerplate
> bytecode operations you have to do in Java for doing
> loops/mapping/transforming/filtering of code so its probably a case
> that you use much less actual code and less helper classes (often
> copied randomly from project to project) and libraries (google
> collections v common collections v guava v all the other java
> libraries attempting to make collections more palatable in Java).
>
> Though if you're ever worried about jar sizes for Scala or Java,
> there's always ProGuard to trim dead code.
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [smx5] Scala based (was Re: Profiling stragegy)

Michael Van
+1

Moving some bits of SMX to Scala is a great idea. Before moving, we should:
1) Ensure we are only using Scala where it makes sense. No need to re-invent (read re-write) packages in Scala simply because Scala is sexy.
2) Ensure we have a good FAQ or tutorial explaining how to set up your ide (IntelliJ and Eclipse) to use Scala, and then how to build SMX 5.0.

Jean-Baptiste Onofré wrote
Thanks for the update James.

It's more clear :)

Regards
JB

On 07/08/2011 01:27 PM, James Strachan wrote:
> On 8 July 2011 11:29, Jean-Baptiste Onofré<[hidden email]>  wrote:
>> James,
>>
>> I found this blog:
>> http://kotek.net/blog/scala_problems
>>
>> WDYT ?
>
> Most of the issues are old (e.g. old versions of scala kept breaking
> bytecode compatibility, something OSGi can help you with anyway) or
> tooling issues. See the comments - e.g. use SBT / FSC option in your
> IDE. I use IDEA with Scala with FST on and its pretty fast and snappy.
>
> Using SBT in incremental compile/test mode on 0.10 is now *much
> faster* than using maven and java :). As you change a line of code in
> your IDE everything recompiles&  reruns really quickly.
>
>
>> Especially around the size of the jar.
>>
>> Doesn't it in "opposition" with the OSGi granularity ?
>
> Am not really sure if the exact size of a jar file is much of a
> concern in the grand scheme of things; it certainly doesn't affect
> granularity at least. That being said, sure Scala uses more classes in
> the generated bytecode (as does Java 8's closures&  java 4's inner
> classes), but then the Scala library replaces a ton of boilerplate
> bytecode operations you have to do in Java for doing
> loops/mapping/transforming/filtering of code so its probably a case
> that you use much less actual code and less helper classes (often
> copied randomly from project to project) and libraries (google
> collections v common collections v guava v all the other java
> libraries attempting to make collections more palatable in Java).
>
> Though if you're ever worried about jar sizes for Scala or Java,
> there's always ProGuard to trim dead code.
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
123