5:45 a.m.
Hi,
The REST module is written in Scala (both main + tests). We have some *test* contributions
written in Java (thanks mlinhard).
There was an IRC discussion on whether it's worth migrating the Java contribution to
Scala code or not.
Pros for migrating the contribution from Java to Scala:
- the REST module is written in Scala. Contributing these tests in Java would make the
module bi-lingual, potentially confusing future contributors
- even though this is not the case with this particular contribution, there might be code
duplications between the scala test suite and java test suite.
Cons for migrating the contribution from Java to Scala:
- there are contributors that are not familiar with Scala or are more proficient with
Java(such as mlinhard). Forcing them to contribute in a language they are not familiar
with would put them off
- my general feeling over time was that people (including me) are not very enthusiastic
about debugging and extending Scala code. So IMO if there's a choice between scala and
java (in the scope of the scala modules) we should stick to Java wherever possible (such
as this contribution).
This email is not about the migration of scala code to java, but about the very specific
contribution described above (even thought the mix of scala+java code in ISPN is a a very
interesting topic by itself).
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
5:53 a.m.
On 31 Jan 2013, at 11:45, Mircea Markus <mmarkus(a)redhat.com> wrote:
Hi,
The REST module is written in Scala (both main + tests). We have some *test*
contributions written in Java (thanks mlinhard).
There was an IRC discussion on whether it's worth migrating the Java contribution to
Scala code or not.
Pros for migrating the contribution from Java to Scala:
- the REST module is written in Scala. Contributing these tests in Java would make the
module bi-lingual, potentially confusing future contributors
Why? You can choose what to write your tests in.
- even though this is not the case with this particular contribution,
there might be code duplications between the scala test suite and java test suite.
Don't create separate test suites. Put them in the same class path - e.g.,
src/test/scala - you can have .java files in here too, they will be compiled together, run
together, can reference one another.
Cons for migrating the contribution from Java to Scala:
- there are contributors that are not familiar with Scala or are more proficient with
Java(such as mlinhard). Forcing them to contribute in a language they are not familiar
with would put them off
+1
- my general feeling over time was that people (including me) are not
very enthusiastic about debugging and extending Scala code. So IMO if there's a choice
between scala and java (in the scope of the scala modules) we should stick to Java
wherever possible (such as this contribution).
That should not be a hard and fast rule for all modules. I agree that some modules (like
core) should just stick to Java.
This email is not about the migration of scala code to java, but
about the very specific contribution described above (even thought the mix of scala+java
code in ISPN is a a very interesting topic by itself).
My vote: don't waste time in migrating the test to Scala, unless it is trivial, in
which case then do that.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
6:35 a.m.
On 31 Jan 2013, at 11:53, Manik Surtani wrote:
On 31 Jan 2013, at 11:45, Mircea Markus <mmarkus(a)redhat.com> wrote:
> Hi,
>
>
> The REST module is written in Scala (both main + tests). We have some *test*
contributions written in Java (thanks mlinhard).
> There was an IRC discussion on whether it's worth migrating the Java contribution
to Scala code or not.
>
> Pros for migrating the contribution from Java to Scala:
> - the REST module is written in Scala. Contributing these tests in Java would make
the module bi-lingual, potentially confusing future contributors
Why? You can choose what to write your tests in.
> - even though this is not the case with this particular contribution, there might be
code duplications between the scala test suite and java test suite.
Don't create separate test suites. Put them in the same class path - e.g.,
src/test/scala - you can have .java files in here too, they will be compiled together, run
together, can reference one another.
>
> Cons for migrating the contribution from Java to Scala:
> - there are contributors that are not familiar with Scala or are more proficient with
Java(such as mlinhard). Forcing them to contribute in a language they are not familiar
with would put them off
+1
> - my general feeling over time was that people (including me) are not very
enthusiastic about debugging and extending Scala code. So IMO if there's a choice
between scala and java (in the scope of the scala modules) we should stick to Java
wherever possible (such as this contribution).
That should not be a hard and fast rule for all modules. I agree that some modules (like
core) should just stick to Java.
I don't think that encouraging scala code is good purely for maintenance reasons. If
there's a choice, it should be java. Not saying that learning a new language is not
cool - but in practice people are a bit put off by maintaining Scala code. Its not only
about what the writer of the code prefers as a language: it's more important what the
maintainers of the code
will has to work with.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:37 a.m.
On 31 Jan 2013, at 12:35, Mircea Markus <mmarkus(a)redhat.com> wrote:
I don't think that encouraging scala code is good purely for
maintenance reasons. If there's a choice, it should be java. Not saying that learning
a new language is not cool - but in practice people are a bit put off by maintaining Scala
code. Its not only about what the writer of the code prefers as a language: it's more
important what the maintainers of the code
will has to work with.
Would such maintainers also be put off by new language features (lambdas) in Java 8 when
we (eventually) baseline to it? :-)
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
6:42 a.m.
On 31 Jan 2013, at 12:37, Manik Surtani wrote:
> I don't think that encouraging scala code is good purely for
maintenance reasons. If there's a choice, it should be java. Not saying that learning
a new language is not cool - but in practice people are a bit put off by maintaining Scala
code. Its not only about what the writer of the code prefers as a language: it's more
important what the maintainers of the code
> will has to work with.
Would such maintainers also be put off by new language features (lambdas) in Java 8 when
we (eventually) baseline to it? :-)
It's really NOT the same thing: any decent
java programmer keeps up with all the enhancements in Java.
What I might not want to - as an ISPN programmer - is to keep up with the language
enhancements in Scala. And I might need to do that because of Scala language enhancements
used in ISPN.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4:02 p.m.
On Thu, Jan 31, 2013 at 2:42 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 31 Jan 2013, at 12:37, Manik Surtani wrote:
I don't think that encouraging scala code is good purely for maintenance
reasons. If there's a choice, it should be java. Not saying that learning a
new language is not cool - but in practice people are a bit put off by
maintaining Scala code. Its not only about what the writer of the code
prefers as a language: it's more important what the maintainers of the code
will has to work with.
Would such maintainers also be put off by new language features (lambdas)
in Java 8 when we (eventually) baseline to it? :-)
It's really NOT the same thing: any decent java programmer keeps up with
all the enhancements in Java.
What I might not want to - as an ISPN programmer - is to keep up with the
language enhancements in Scala. And I might need to do that because of
Scala language enhancements used in ISPN.
I guess my main problem with Scala is that it's evolving at a furious pace,
and as a result it's accumulating a lot of different ways to do the same
thing. So different parts of the code evolve to do the same thing in many
different ways, depending on who wrote that bit and when.
As to debugging Java-Scala interop, I never had any problems. There is one
general annoyance with debugging Scala code in that almost everything is a
function call, so you almost never use step-over in the debugger.
Profiling Scala code may be a bit more complicated than profiling Java
code, but I haven't had to do that yet (I was profiling the HotRod server,
but most of the spent time was in the core module).
8:37 a.m.
On Jan 31, 2013, at 1:42 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 31 Jan 2013, at 12:37, Manik Surtani wrote:
>> I don't think that encouraging scala code is good purely for maintenance
reasons. If there's a choice, it should be java. Not saying that learning a new
language is not cool - but in practice people are a bit put off by maintaining Scala code.
Its not only about what the writer of the code prefers as a language: it's more
important what the maintainers of the code
>> will has to work with.
>
> Would such maintainers also be put off by new language features (lambdas) in Java 8
when we (eventually) baseline to it? :-)
It's really NOT the same thing: any decent java programmer keeps up with all the
enhancements in Java.
What I might not want to - as an ISPN programmer - is to keep up with the language
enhancements in Scala. And I might need to do that because of Scala language enhancements
used in ISPN.
^ I wonder whether C programmers thought the same way 20 years ago.
Cheers,
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
8:46 a.m.
On Feb 6, 2013, at 9:37 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Jan 31, 2013, at 1:42 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On 31 Jan 2013, at 12:37, Manik Surtani wrote:
>
>>> I don't think that encouraging scala code is good purely for maintenance
reasons. If there's a choice, it should be java. Not saying that learning a new
language is not cool - but in practice people are a bit put off by maintaining Scala code.
Its not only about what the writer of the code prefers as a language: it's more
important what the maintainers of the code
>>> will has to work with.
>>
>> Would such maintainers also be put off by new language features (lambdas) in Java
8 when we (eventually) baseline to it? :-)
> It's really NOT the same thing: any decent java programmer keeps up with all the
enhancements in Java.
> What I might not want to - as an ISPN programmer - is to keep up with the language
enhancements in Scala. And I might need to do that because of Scala language enhancements
used in ISPN.
^ I wonder whether C programmers thought the same way 20 years ago.
20 years ago? I'm pretty sure Bela said this last week.
Besides, it's all JavaScript these days. Scala is old and busted ;)
-alan
8:58 a.m.
On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
>>> I don't think that encouraging scala code is good
purely for maintenance reasons. If there's a choice, it should be java. Not saying
that learning a new language is not cool - but in practice people are a bit put off by
maintaining Scala code. Its not only about what the writer of the code prefers as a
language: it's more important what the maintainers of the code
>>> will has to work with.
>>
>> Would such maintainers also be put off by new language features (lambdas) in Java
8 when we (eventually) baseline to it? :-)
> It's really NOT the same thing: any decent java programmer keeps up with all the
enhancements in Java.
> What I might not want to - as an ISPN programmer - is to keep up with the language
enhancements in Scala. And I might need to do that because of Scala language enhancements
used in ISPN.
^ I wonder whether C programmers thought the same way 20 years ago.
Personally I
don't believe Scala is the next big thing as it doesn't have a "killer"
feature, e.g. OOP from C -> C++ or GC from C++ -> Java.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9:10 a.m.
On 2/6/13 3:58 PM, Mircea Markus wrote:
On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
>>>> I don't think that encouraging scala code is good purely for
>>>> maintenance reasons. If there's a choice, it should be java. Not
>>>> saying that learning a new language is not cool - but in practice
>>>> people are a bit put off by maintaining Scala code. Its not only
>>>> about what the writer of the code prefers as a language: it's more
>>>> important what the maintainers of the code
>>>> will has to work with.
>>>
>>> Would such maintainers also be put off by new language features
>>> (lambdas) in Java 8 when we (eventually) baseline to it? :-)
>> It's really NOT the same thing: any decent java programmer keeps up
>> with all the enhancements in Java.
>> What I might not want to - as an ISPN programmer - is to keep up
>> with the language enhancements in Scala. And I might need to do that
>> because of Scala language enhancements used in ISPN.
>
> ^ I wonder whether C programmers thought the same way 20 years ago.
Personally I don't believe Scala is the next big thing as it doesn't
have a "killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java.
+1000.
Let the flame war start (Galder with his lighter against us with flam
throwers) :-)
--
Bela Ban, JGroups lead (http://www.jgroups.org)
9:14 a.m.
On Feb 6, 2013, at 3:58 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
>>>> I don't think that encouraging scala code is good purely for
maintenance reasons. If there's a choice, it should be java. Not saying that learning
a new language is not cool - but in practice people are a bit put off by maintaining Scala
code. Its not only about what the writer of the code prefers as a language: it's more
important what the maintainers of the code
>>>> will has to work with.
>>>
>>> Would such maintainers also be put off by new language features (lambdas) in
Java 8 when we (eventually) baseline to it? :-)
>> It's really NOT the same thing: any decent java programmer keeps up with all
the enhancements in Java.
>> What I might not want to - as an ISPN programmer - is to keep up with the
language enhancements in Scala. And I might need to do that because of Scala language
enhancements used in ISPN.
>
> ^ I wonder whether C programmers thought the same way 20 years ago.
Personally I don't believe Scala is the next big thing as it doesn't have a
"killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java.
Scala opened my eyes to functional programming.
Whether that's a killer feature or not is debatable because functional programming has
been around for tons of years, even probably more than OOP.
Howver, from a Java developer perspective, I've seen no other programming language
that has done more to promote functional programming than Scala, and that to me is a
killer feature.
I'm very glad functional programming is coming to Java, but I hope they don't mess
it up like they did with generics.
Even then, the functional programming bits coming to Java are just a fraction of the rest
cool stuff that's present in Scala. The best example of this I've found is this:
http://www.myexpospace.com/JavaOne2012/SessionFiles/CON3470_mp4_3470_001.mp4
It's a very funny video too :D
On a more serious note, this is probably one of those arguments where the best we can do
is agree to disagree. I'm slightly dissapointed with the final decision you've
made, but this is open source development and live goes on…
Cheers,
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
9:50 a.m.
On 6 Feb 2013, at 14:58, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
>>>> I don't think that encouraging scala code is good purely for
maintenance reasons. If there's a choice, it should be java. Not saying that learning
a new language is not cool - but in practice people are a bit put off by maintaining Scala
code. Its not only about what the writer of the code prefers as a language: it's more
important what the maintainers of the code
>>>> will has to work with.
>>>
>>> Would such maintainers also be put off by new language features (lambdas) in
Java 8 when we (eventually) baseline to it? :-)
>> It's really NOT the same thing: any decent java programmer keeps up with all
the enhancements in Java.
>> What I might not want to - as an ISPN programmer - is to keep up with the
language enhancements in Scala. And I might need to do that because of Scala language
enhancements used in ISPN.
>
> ^ I wonder whether C programmers thought the same way 20 years ago.
Personally I don't believe Scala is the next big thing as it doesn't have a
"killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java.
That's 20/20 hindsight. Lots of C developers said OOP was bullish*t when C++ came
about, and even today some C++ folks argue than GC is for losers. :)
As Alan said, I for one look forward to writing all my code in JavaScript but until that
day there is a lot of innovation we ought to embrace. Java's shown itself to be slow
to grow and evolve. Oracle's acquisition of Sun has sped things up a lot, but it
still is behind the curve. There's a good reason why Ruby, Python, Erlang and Scala
are gaining popularity. If you've ever spent any time writing extensive code in any
of these platforms you'd understand why.
- M
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
3:04 a.m.
On 6 Feb 2013 17:51, "Manik Surtani" <msurtani(a)redhat.com> wrote:
On 6 Feb 2013, at 14:58, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
I don't think that encouraging scala code is good purely for maintenance
reasons. If there's a choice, it should be java. Not saying that learning a
new language is not cool - but in practice people are a bit put off by
maintaining Scala code. Its not only about what the writer of the code
prefers as a language: it's more important what the maintainers of the code
will has to work with.
Would such maintainers also be put off by new language features (lambdas)
in Java 8 when we (eventually) baseline to it? :-)
It's really NOT the same thing: any decent java programmer keeps up with
all the enhancements in Java.
What I might not want to - as an ISPN programmer - is to keep up with the
language enhancements in Scala. And I might need to do that because of
Scala language enhancements used in ISPN.
^ I wonder whether C programmers thought the same way 20 years ago.
Personally I don't believe Scala is the next big thing as it doesn't have
a "killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java.
That's 20/20 hindsight. Lots of C developers said OOP was bullish*t when
C++ came about, and even today some C++ folks argue than GC is for losers.
:)
Not sure about C developers, but there are plenty of developers in the
functional camp who still say OOP is bullsh*t :)
And many of the GC arguments were only invalidated 10 years after Java came
out, as multi-core became the norm and the GC could use a "free" core.
As Alan said, I for one look forward to writing all my code in
JavaScript
but until that day there is a lot of innovation we ought to embrace.
Java's shown itself to be slow to grow and evolve. Oracle's acquisition
of Sun has sped things up a lot, but it still is behind the curve. There's
a good reason why Ruby, Python, Erlang and Scala are gaining popularity.
If you've ever spent any time writing extensive code in any of these
platforms you'd understand why.
Seriously, what do JavaScript, Ruby, Python, Erlang and Scala have in
common? The only thing I can think of is "they're not Java" :)
I think Python is just as slow to evolve as Java, maybe even slower. And
it's not just the language itself, but the community as well: Python 3.0
came out in 2008, yet not everyone is on board just yet (
https://news.ycombinator.com/item?id=5009484).
Scala seems to be on the other end of the spectrum, adding a truck-load of
features every couple of years. My feeling is the Scala guys haven't
learned that every new feature starts at -100 points yet:
http://www.scala-lang.org/node/43<http://blogs.msdn.com/b/ericgu/archi...
- M
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:47 a.m.
On 1/31/13 1:37 PM, Manik Surtani wrote:
On 31 Jan 2013, at 12:35, Mircea Markus <mmarkus(a)redhat.com
<mailto:mmarkus@redhat.com>> wrote:
> I don't think that encouraging scala code is good purely for
> maintenance reasons. If there's a choice, it should be java. Not
> saying that learning a new language is not cool - but in practice
> people are a bit put off by maintaining Scala code. Its not only
> about what the writer of the code prefers as a language: it's more
> important what the maintainers of the code
> will has to work with.
Would such maintainers also be put off by new language features
(lambdas) in Java 8 when we (eventually) baseline to it? :-)
I don't think so. First, this will be a few years off anyway. Second,
this will not pose cross-language debugging problems. And third, even
Java+closures is still Java.
Nice try, advocatus diaboli ! :-)
--
Bela Ban, JGroups lead (http://www.jgroups.org)
6:49 a.m.
On 31 Jan 2013, at 12:47, Bela Ban wrote:
On 1/31/13 1:37 PM, Manik Surtani wrote:
>
> On 31 Jan 2013, at 12:35, Mircea Markus <mmarkus(a)redhat.com
> <mailto:mmarkus@redhat.com>> wrote:
>
>> I don't think that encouraging scala code is good purely for
>> maintenance reasons. If there's a choice, it should be java. Not
>> saying that learning a new language is not cool - but in practice
>> people are a bit put off by maintaining Scala code. Its not only
>> about what the writer of the code prefers as a language: it's more
>> important what the maintainers of the code
>> will has to work with.
>
> Would such maintainers also be put off by new language features
> (lambdas) in Java 8 when we (eventually) baseline to it? :-)
I don't think so. First, this will be a few years off anyway. Second,
this will not pose cross-language debugging problems. And third, even
Java+closures is still Java.
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
7:14 a.m.
On 31 Jan 2013, at 12:47, Bela Ban <bban(a)redhat.com> wrote:
On 1/31/13 1:37 PM, Manik Surtani wrote:
>
> On 31 Jan 2013, at 12:35, Mircea Markus <mmarkus(a)redhat.com
> <mailto:mmarkus@redhat.com>> wrote:
>
>> I don't think that encouraging scala code is good purely for
>> maintenance reasons. If there's a choice, it should be java. Not
>> saying that learning a new language is not cool - but in practice
>> people are a bit put off by maintaining Scala code. Its not only
>> about what the writer of the code prefers as a language: it's more
>> important what the maintainers of the code
>> will has to work with.
>
> Would such maintainers also be put off by new language features
> (lambdas) in Java 8 when we (eventually) baseline to it? :-)
I don't think so. First, this will be a few years off anyway.
Sooner than you think - according to schedule, it is feature-complete (as of today) and
targeted for GA in September.
http://openjdk.java.net/projects/jdk8/
http://www.infoq.com/news/2012/04/jdk-8-milestone-release-dates
Java 6 is EOL from next month and Java 7 will be EOL by July 2014. Oracle's being
pretty aggressive with moving Java forward.
http://www.oracle.com/technetwork/java/eol-135779.html
Second,
this will not pose cross-language debugging problems. And third, even
Java+closures is still Java.
What does that mean? It makes an imperative programming language more functional in
style. So yes, while it still has the Java brand, I'd argue that it is becoming more
than that. Best practices, paradigms and patterns will change and give way to even better
ways of doing things. It is, effectively, learning a new language (as opposed to just a
new API).
Nice try, advocatus diaboli ! :-)
--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
7:55 a.m.
On 31 Jan 2013, at 13:14, Manik Surtani wrote:
On 31 Jan 2013, at 12:47, Bela Ban <bban(a)redhat.com> wrote:
>
> On 1/31/13 1:37 PM, Manik Surtani wrote:
>>
>> On 31 Jan 2013, at 12:35, Mircea Markus <mmarkus(a)redhat.com
>> <mailto:mmarkus@redhat.com>> wrote:
>>
>>> I don't think that encouraging scala code is good purely for
>>> maintenance reasons. If there's a choice, it should be java. Not
>>> saying that learning a new language is not cool - but in practice
>>> people are a bit put off by maintaining Scala code. Its not only
>>> about what the writer of the code prefers as a language: it's more
>>> important what the maintainers of the code
>>> will has to work with.
>>
>> Would such maintainers also be put off by new language features
>> (lambdas) in Java 8 when we (eventually) baseline to it? :-)
>
> I don't think so. First, this will be a few years off anyway.
Sooner than you think - according to schedule, it is feature-complete (as of today) and
targeted for GA in September.
http://openjdk.java.net/projects/jdk8/
http://www.infoq.com/news/2012/04/jdk-8-milestone-release-dates
Java 6 is EOL from next month and Java 7 will be EOL by July 2014. Oracle's being
pretty aggressive with moving Java forward.
http://www.oracle.com/technetwork/java/eol-135779.html
> Second,
> this will not pose cross-language debugging problems. And third, even
> Java+closures is still Java.
What does that mean? It makes an imperative programming language more functional in
style. So yes, while it still has the Java brand, I'd argue that it is becoming more
than that. Best practices, paradigms and patterns will change and give way to even better
ways of doing things. It is, effectively, learning a new language (as opposed to just a
new API).
I don't think the step from learning Java7 -> Java8 is comparable to
Java6->Scala, but I really don't think that's the thing to be discussed*.
People seem to be reluctant to debug Scala code in ISPN - and that's a productivity
issue more than anything else.
*Also as a java developer you have the general option of not learning Scala, but you
don't really have the option of not keeping up with Java8.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
8:12 a.m.
On 31 Jan 2013, at 13:55, Mircea Markus <mmarkus(a)redhat.com> wrote:
*Also as a java developer you have the general option of not learning
Scala, but you don't really have the option of not keeping up with Java8.
So you generally only learn new things when you have no other option? ;)
I'm being an arse, ignore me. I realise your main concern is productivity, which is
why any Scala code has been restricted to a few, pretty independent modules.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
8:18 a.m.
On 31 Jan 2013, at 14:12, Manik Surtani wrote:
On 31 Jan 2013, at 13:55, Mircea Markus <mmarkus(a)redhat.com>
wrote:
> *Also as a java developer you have the general option of not learning Scala, but you
don't really have the option of not keeping up with Java8.
So you generally only learn new things when you have no other option? ;)
no, but I
like the option of choosing the things I learn (as much as possible). And personally,
I'd rather learn distributed algorithms than Scala :-)
I'm being an arse, ignore me. I realise your main concern is productivity, which is
why any Scala code has been restricted to a few, pretty independent modules.
You're not at all - this is really something we should discuss as a team.
+1 for keeping it isolated to specific modules :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
8:12 a.m.
The release date for Java 8 is not the date when Infinispan will
baseline to Java 8, there's always a lag. In the case of JGroups, some
folks are still on JDK 1.5, would you believe it, and were quite pissed
when I baselined JGroups to JDK 6....
On 1/31/13 2:14 PM, Manik Surtani wrote:
On 31 Jan 2013, at 12:47, Bela Ban <bban(a)redhat.com> wrote:
> On 1/31/13 1:37 PM, Manik Surtani wrote:
>> On 31 Jan 2013, at 12:35, Mircea Markus <mmarkus(a)redhat.com
>> <mailto:mmarkus@redhat.com>> wrote:
>>
>>> I don't think that encouraging scala code is good purely for
>>> maintenance reasons. If there's a choice, it should be java. Not
>>> saying that learning a new language is not cool - but in practice
>>> people are a bit put off by maintaining Scala code. Its not only
>>> about what the writer of the code prefers as a language: it's more
>>> important what the maintainers of the code
>>> will has to work with.
>> Would such maintainers also be put off by new language features
>> (lambdas) in Java 8 when we (eventually) baseline to it? :-)
> I don't think so. First, this will be a few years off anyway.
Sooner than you think - according to schedule, it is feature-complete (as of today) and
targeted for GA in September.
http://openjdk.java.net/projects/jdk8/
http://www.infoq.com/news/2012/04/jdk-8-milestone-release-dates
Java 6 is EOL from next month and Java 7 will be EOL by July 2014. Oracle's being
pretty aggressive with moving Java forward.
http://www.oracle.com/technetwork/java/eol-135779.html
> Second,
> this will not pose cross-language debugging problems. And third, even
> Java+closures is still Java.
What does that mean? It makes an imperative programming language more functional in
style. So yes, while it still has the Java brand, I'd argue that it is becoming more
than that. Best practices, paradigms and patterns will change and give way to even better
ways of doing things. It is, effectively, learning a new language (as opposed to just a
new API).
> Nice try, advocatus diaboli ! :-)
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
6:08 a.m.
I've said it before and am repeating myself here: I believe including
Scala code is a very bad decision for the following reasons:
- Not a lot of people are proficient in Scala
- What happens when the people who wrote the Scala code leave ? We'd
have to build up Scala knowledge in house to be able to develop/maintain
that code
- Support: same for knowledge: we have to support Scala code if there's
a bug, but IMO we don't have Scala folks in support
- Debugging: cross language debugging is hairy at least (or so I
heard/read from different people)
- I've had a few run-ins with the Scala compiler when compiling
Infinispan with Maven
If it was up to me, I'd flat-out *prohibit* any new Scala code in
Infinispan. Long-term I'd also replace Scala with Java, although the
server is probably not such a big problem as it is a standalone and
independent subsystem.
my 5 cents,
On 1/31/13 12:45 PM, Mircea Markus wrote:
Hi,
The REST module is written in Scala (both main + tests). We have some
*test* contributions written in Java (thanks mlinhard).
There was an IRC discussion on whether it's worth migrating the Java
contribution to Scala code or not.
Pros for migrating the contribution from Java to Scala:
- the REST module is written in Scala. Contributing these tests in
Java would make the module bi-lingual, potentially confusing future
contributors
- even though this is not the case with this particular contribution,
there might be code duplications between the scala test suite and java
test suite.
Cons for migrating the contribution from Java to Scala:
- there are contributors that are not familiar with Scala or are more
proficient with Java(such as mlinhard). Forcing them to contribute in
a language they are not familiar with would put them off
- my general feeling over time was that people (including me) are not
very enthusiastic about debugging and extending Scala code. So IMO if
there's a choice between scala and java (in the scope of the scala
modules) we should stick to Java wherever possible (such as this
contribution).
This email is not about the migration of scala code to java, but about
the very specific contribution described above (even thought the mix
of scala+java code in ISPN is a a very interesting topic by itself).
--
Bela Ban, JGroups lead (http://www.jgroups.org)
6:48 a.m.
On 31 Jan 2013, at 12:08, Bela Ban wrote:
I've said it before and am repeating myself here: I believe
including
Scala code is a very bad decision for the following reasons:
- Not a lot of people are proficient in Scala
- What happens when the people who wrote the Scala code leave ? We'd
have to build up Scala knowledge in house to be able to develop/maintain
that code
- Support: same for knowledge: we have to support Scala code if there's
a bug, but IMO we don't have Scala folks in support
- Debugging: cross language debugging is hairy at least (or so I
heard/read from different people)
- I've had a few run-ins with the Scala compiler when compiling
Infinispan with Maven
Agreed on all points.
OTOH learning/using a new language can be good fun, so with that in mind having Scala in
ISPN might be a positive think. From what I saw discussing with people is that not
everyone shares this enthusiasm in using Scala, and even fewer in debugging Scala.
If it was up to me, I'd flat-out *prohibit* any new Scala code in
Infinispan. Long-term I'd also replace Scala with Java, although the
server is probably not such a big problem as it is a standalone and
independent subsystem.
my 5 cents,
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
7:14 a.m.
On 1/31/13 1:48 PM, Mircea Markus wrote:
Agreed on all points.
OTOH learning/using a new language can be good fun, so with that in
mind having Scala in ISPN might be a positive think. From what I saw
discussing with people is that not everyone shares this enthusiasm in
using Scala, and even fewer in debugging Scala.
Agreed.
*If* someone wants to learn a new *great* language, learn Clojure. Blows
Scala right out of the water**1 :-)
But even if I like Clojure, would I write some of JGroups (e.g. a
protocol) in Clojure ? No way, exactly for the same reasons that I
listed in this email thread.
**1: OK, I have to admit that I did a fair amount of CLOS back in the
days, and love Lisp dialects...
--
Bela Ban, JGroups lead (http://www.jgroups.org)
7:17 a.m.
On 31 Jan 2013, at 13:14, Bela Ban <bban(a)redhat.com> wrote:
On 1/31/13 1:48 PM, Mircea Markus wrote:
> Agreed on all points.
> OTOH learning/using a new language can be good fun, so with that in
> mind having Scala in ISPN might be a positive think. From what I saw
> discussing with people is that not everyone shares this enthusiasm in
> using Scala, and even fewer in debugging Scala.
Agreed.
*If* someone wants to learn a new *great* language, learn Clojure. Blows
Scala right out of the water**1 :-)
I've heard some interesting arguments about how Clojure won't scale due to its
concurrency model (everything's immutable, defensive copies everywhere), meaning that
CPU caches end up being useless. :) I don't know enough about how it is implemented
to comment myself though.
But even if I like Clojure, would I write some of JGroups (e.g. a
protocol) in Clojure ? No way, exactly for the same reasons that I
listed in this email thread.
**1: OK, I have to admit that I did a fair amount of CLOS back in the
days, and love Lisp dialects...
--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
8:19 a.m.
On 1/31/13 2:17 PM, Manik Surtani wrote:
On 31 Jan 2013, at 13:14, Bela Ban <bban(a)redhat.com> wrote:
>
> On 1/31/13 1:48 PM, Mircea Markus wrote:
>> Agreed on all points.
>> OTOH learning/using a new language can be good fun, so with that in
>> mind having Scala in ISPN might be a positive think. From what I saw
>> discussing with people is that not everyone shares this enthusiasm in
>> using Scala, and even fewer in debugging Scala.
> Agreed.
>
> *If* someone wants to learn a new *great* language, learn Clojure. Blows
> Scala right out of the water**1 :-)
I've heard some interesting arguments about how Clojure won't scale due to its
concurrency model (everything's immutable, defensive copies everywhere), meaning that
CPU caches end up being useless. :) I don't know enough about how it is implemented
to comment myself though.
Those comments apply to functional languages in general, Scala included.
Immutability is a 'feature' of functional languages in general; and the
main reason IMO why they never caught on. At least, Clojure is not as
pure as scheme and does allow operations that have side effects
(refs/vars), e.g. change a data structure, so you can choose in some
scenarios to trade purity for efficiency.
Now that we have more memory, the CPUs have become faster, GC is better,
and data structures (e.g. in Clojure) have more efficient 'copying', the
severity of the problem has been somewhat reduced, but it is still
there. Clojure for example, has pretty efficient copying of maps or
lists, where they actually don't really copy stuff, but still reference
the same data until a a real copy is required. Quite similar to
copy-on-demand structures, or even to the read-committed / rep-read
implementations in Infinispan.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
7:25 a.m.
On 31 Jan 2013, at 13:14, Bela Ban <bban(a)redhat.com> wrote:
*If* someone wants to learn a new *great* language, learn Clojure.
Blows
Scala right out of the water**1 :-)
Also let's not forget:
"The most important thing in the programming language is the name. A language will
not succeed without a good name. I have recently invented a very good name and now I am
looking for a suitable language." - Donald Knuth
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
6:28 a.m.
In this special case I'm gonna try to rewrite the test case as an
excercise - it doesn't seem like that much extra work, and I'd rewrite
it anyway
I'm not satisfied with it's current form even if it was to stay in Java.
But this is just postponing of this important question.
As much as I don't like the idea of mixing in the Java code to now still
(almost) pure scala modules - maybe just an aesthetic preference of mine.
I'd like to have an oportunity to add a Java test if it's something more
complex in the future. - in cases where advantages and quickness of
availability of java unit test outweigh the unniceness of the mixing.
So +1 for allowing java test cases in scala modules
m.
On 01/31/2013 12:45 PM, Mircea Markus wrote:
Hi,
The REST module is written in Scala (both main + tests). We have some
*test* contributions written in Java (thanks mlinhard).
There was an IRC discussion on whether it's worth migrating the Java
contribution to Scala code or not.
Pros for migrating the contribution from Java to Scala:
- the REST module is written in Scala. Contributing these tests in
Java would make the module bi-lingual, potentially confusing future
contributors
- even though this is not the case with this particular contribution,
there might be code duplications between the scala test suite and java
test suite.
Cons for migrating the contribution from Java to Scala:
- there are contributors that are not familiar with Scala or are more
proficient with Java(such as mlinhard). Forcing them to contribute in
a language they are not familiar with would put them off
- my general feeling over time was that people (including me) are not
very enthusiastic about debugging and extending Scala code. So IMO if
there's a choice between scala and java (in the scope of the scala
modules) we should stick to Java wherever possible (such as this
contribution).
This email is not about the migration of scala code to java, but about
the very specific contribution described above (even thought the mix
of scala+java code in ISPN is a a very interesting topic by itself).
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org <http://www.infinispan.org>)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
6:37 a.m.
On 31 Jan 2013, at 12:28, Michal Linhard wrote:
In this special case I'm gonna try to rewrite the test case as an
excercise - it doesn't seem like that much extra work, and I'd rewrite
it anyway I'm not satisfied with it's current form even if it was to stay in
Java.
-1. If there's a choice it should be Java.
But this is just postponing of this important question.
As much as I don't like the idea of mixing in the Java code to now still
(almost) pure scala modules - maybe just an aesthetic preference of mine.
I'd like to have an oportunity to add a Java test if it's something more
complex in the future. - in cases where advantages and quickness of
availability of java unit test outweigh the unniceness of the mixing.
So +1 for allowing java test cases in scala modules
thanks for the feedback ;)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
7:57 a.m.
On 01/31/2013 01:37 PM, Mircea Markus wrote:
On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>
> In this special case I'm gonna try to rewrite the test case as an
> excercise - it doesn't seem like that much extra work, and I'd rewrite
> it anyway I'm not satisfied with it's current form even if it was to
> stay in Java.
-1. If there's a choice it should be Java.
So I did some Scala excercise, which
I quite enjoyed, but I have to
admit, it's not practical to require Scala in all the test code.
So how about this:
https://github.com/mlinhard/infinispan/commit/297c275a22f582eafb1aaf1b0eb...
@Galder can you please review the Scala part ?
MultiServerStartupListener - new class that I started in Java - this
will make the precedent of commits of Java code into server modules,
that may come out of this discussion
ServerInstance - continued in Scala
TwoServerTest - written in scala, but trivial, most of the code is
copypaste from other test cases, there is quite straightforward
line-by-line correspondence to java.
m.
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
8:38 a.m.
Is it possbile to convert MultiServerStartupListener servlet to java
too? Otherwise it looks like an odd crossbreed :) Do we really need a
servlet to bootstrap this or just a ServletContextListener will do?
On 02/01/2013 03:57 PM, Michal Linhard wrote:
On 01/31/2013 01:37 PM, Mircea Markus wrote:
> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>
>> In this special case I'm gonna try to rewrite the test case as an
>> excercise - it doesn't seem like that much extra work, and I'd rewrite
>> it anyway I'm not satisfied with it's current form even if it was to
>> stay in Java.
> -1. If there's a choice it should be Java.
So I did some Scala excercise, which I quite enjoyed, but I have to
admit, it's not practical to require Scala in all the test code.
So how about this:
https://github.com/mlinhard/infinispan/commit/297c275a22f582eafb1aaf1b0eb...
@Galder can you please review the Scala part ?
MultiServerStartupListener - new class that I started in Java - this
will make the precedent of commits of Java code into server modules,
that may come out of this discussion
ServerInstance - continued in Scala
TwoServerTest - written in scala, but trivial, most of the code is
copypaste from other test cases, there is quite straightforward
line-by-line correspondence to java.
m.
8:48 a.m.
MultiServerStartupListener is written in Java.
but maybe it would be ok to initialize ManagerInstance.instance directly
in ServerInstance.start()
actually the code could me much simpler that way :)
maybe one reason to let StartupListener to do it's work is that it's the
code that it's being tested as well.
In case of multiple servers the ManagerInstance could be initialized
directly...
On 02/01/2013 03:38 PM, Adrian Nistor wrote:
Is it possbile to convert MultiServerStartupListener servlet to java
too? Otherwise it looks like an odd crossbreed :) Do we really need a
servlet to bootstrap this or just a ServletContextListener will do?
On 02/01/2013 03:57 PM, Michal Linhard wrote:
> On 01/31/2013 01:37 PM, Mircea Markus wrote:
>> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>>
>>> In this special case I'm gonna try to rewrite the test case as an
>>> excercise - it doesn't seem like that much extra work, and I'd
rewrite
>>> it anyway I'm not satisfied with it's current form even if it was to
>>> stay in Java.
>> -1. If there's a choice it should be Java.
> So I did some Scala excercise, which I quite enjoyed, but I have to
> admit, it's not practical to require Scala in all the test code.
>
> So how about this:
>
https://github.com/mlinhard/infinispan/commit/297c275a22f582eafb1aaf1b0eb...
>
>
> @Galder can you please review the Scala part ?
>
> MultiServerStartupListener - new class that I started in Java - this
> will make the precedent of commits of Java code into server modules,
> that may come out of this discussion
> ServerInstance - continued in Scala
> TwoServerTest - written in scala, but trivial, most of the code is
> copypaste from other test cases, there is quite straightforward
> line-by-line correspondence to java.
>
> m.
>
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
8:52 a.m.
sorry, it obviously is java but I actually meant to say 'Is it possbile
to convert MultiServerStartupListener servlet to _scala_ too?'
On 02/01/2013 04:48 PM, Michal Linhard wrote:
MultiServerStartupListener is written in Java.
but maybe it would be ok to initialize ManagerInstance.instance
directly in ServerInstance.start()
actually the code could me much simpler that way :)
maybe one reason to let StartupListener to do it's work is that it's
the code that it's being tested as well.
In case of multiple servers the ManagerInstance could be initialized
directly...
On 02/01/2013 03:38 PM, Adrian Nistor wrote:
> Is it possbile to convert MultiServerStartupListener servlet to java
> too? Otherwise it looks like an odd crossbreed :) Do we really need a
> servlet to bootstrap this or just a ServletContextListener will do?
>
> On 02/01/2013 03:57 PM, Michal Linhard wrote:
>> On 01/31/2013 01:37 PM, Mircea Markus wrote:
>>> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>>>
>>>> In this special case I'm gonna try to rewrite the test case as an
>>>> excercise - it doesn't seem like that much extra work, and I'd
>>>> rewrite
>>>> it anyway I'm not satisfied with it's current form even if it was
to
>>>> stay in Java.
>>> -1. If there's a choice it should be Java.
>> So I did some Scala excercise, which I quite enjoyed, but I have to
>> admit, it's not practical to require Scala in all the test code.
>>
>> So how about this:
>>
https://github.com/mlinhard/infinispan/commit/297c275a22f582eafb1aaf1b0eb...
>>
>>
>> @Galder can you please review the Scala part ?
>>
>> MultiServerStartupListener - new class that I started in Java - this
>> will make the precedent of commits of Java code into server modules,
>> that may come out of this discussion
>> ServerInstance - continued in Scala
>> TwoServerTest - written in scala, but trivial, most of the code is
>> copypaste from other test cases, there is quite straightforward
>> line-by-line correspondence to java.
>>
>> m.
>>
>
8:56 a.m.
re: crossbreed:
that's what this discussion is supposed to be about: whether to allow
mixing java and scala in server module test code.
m.
On 02/01/2013 03:52 PM, Adrian Nistor wrote:
sorry, it obviously is java but I actually meant to say 'Is it
possbile to convert MultiServerStartupListener servlet to _scala_ too?'
On 02/01/2013 04:48 PM, Michal Linhard wrote:
> MultiServerStartupListener is written in Java.
>
> but maybe it would be ok to initialize ManagerInstance.instance
> directly in ServerInstance.start()
> actually the code could me much simpler that way :)
>
> maybe one reason to let StartupListener to do it's work is that it's
> the code that it's being tested as well.
> In case of multiple servers the ManagerInstance could be initialized
> directly...
>
> On 02/01/2013 03:38 PM, Adrian Nistor wrote:
>> Is it possbile to convert MultiServerStartupListener servlet to java
>> too? Otherwise it looks like an odd crossbreed :) Do we really need
>> a servlet to bootstrap this or just a ServletContextListener will do?
>>
>> On 02/01/2013 03:57 PM, Michal Linhard wrote:
>>> On 01/31/2013 01:37 PM, Mircea Markus wrote:
>>>> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>>>>
>>>>> In this special case I'm gonna try to rewrite the test case as
an
>>>>> excercise - it doesn't seem like that much extra work, and
I'd
>>>>> rewrite
>>>>> it anyway I'm not satisfied with it's current form even if it
was to
>>>>> stay in Java.
>>>> -1. If there's a choice it should be Java.
>>> So I did some Scala excercise, which I quite enjoyed, but I have to
>>> admit, it's not practical to require Scala in all the test code.
>>>
>>> So how about this:
>>>
https://github.com/mlinhard/infinispan/commit/297c275a22f582eafb1aaf1b0eb...
>>>
>>>
>>> @Galder can you please review the Scala part ?
>>>
>>> MultiServerStartupListener - new class that I started in Java - this
>>> will make the precedent of commits of Java code into server modules,
>>> that may come out of this discussion
>>> ServerInstance - continued in Scala
>>> TwoServerTest - written in scala, but trivial, most of the code is
>>> copypaste from other test cases, there is quite straightforward
>>> line-by-line correspondence to java.
>>>
>>> m.
>>>
>>
>
>
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
9:04 a.m.
Sure, but in this particular instance is revriting
MultiServerStartupListener to scala trivial or a PITA? Because if it's
trivial I then I would just do it.
On 02/01/2013 04:56 PM, Michal Linhard wrote:
re: crossbreed:
that's what this discussion is supposed to be about: whether to allow
mixing java and scala in server module test code.
m.
On 02/01/2013 03:52 PM, Adrian Nistor wrote:
> sorry, it obviously is java but I actually meant to say 'Is it
> possbile to convert MultiServerStartupListener servlet to _scala_ too?'
>
> On 02/01/2013 04:48 PM, Michal Linhard wrote:
>> MultiServerStartupListener is written in Java.
>>
>> but maybe it would be ok to initialize ManagerInstance.instance
>> directly in ServerInstance.start()
>> actually the code could me much simpler that way :)
>>
>> maybe one reason to let StartupListener to do it's work is that it's
>> the code that it's being tested as well.
>> In case of multiple servers the ManagerInstance could be initialized
>> directly...
>>
>> On 02/01/2013 03:38 PM, Adrian Nistor wrote:
>>> Is it possbile to convert MultiServerStartupListener servlet to
>>> java too? Otherwise it looks like an odd crossbreed :) Do we really
>>> need a servlet to bootstrap this or just a ServletContextListener
>>> will do?
>>>
>>> On 02/01/2013 03:57 PM, Michal Linhard wrote:
>>>> On 01/31/2013 01:37 PM, Mircea Markus wrote:
>>>>> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>>>>>
>>>>>> In this special case I'm gonna try to rewrite the test case
as an
>>>>>> excercise - it doesn't seem like that much extra work, and
I'd
>>>>>> rewrite
>>>>>> it anyway I'm not satisfied with it's current form even
if it
>>>>>> was to
>>>>>> stay in Java.
>>>>> -1. If there's a choice it should be Java.
>>>> So I did some Scala excercise, which I quite enjoyed, but I have to
>>>> admit, it's not practical to require Scala in all the test code.
>>>>
>>>> So how about this:
>>>>
https://github.com/mlinhard/infinispan/commit/297c275a22f582eafb1aaf1b0eb...
>>>>
>>>>
>>>> @Galder can you please review the Scala part ?
>>>>
>>>> MultiServerStartupListener - new class that I started in Java - this
>>>> will make the precedent of commits of Java code into server modules,
>>>> that may come out of this discussion
>>>> ServerInstance - continued in Scala
>>>> TwoServerTest - written in scala, but trivial, most of the code is
>>>> copypaste from other test cases, there is quite straightforward
>>>> line-by-line correspondence to java.
>>>>
>>>> m.
>>>>
>>>
>>
>>
>
9:34 a.m.
It's not PITA, rewriting it in Scala is actually quite enjoyable. But
also not trivial of course and there's not always time for it.
If I rewrite it now, then we're postponing the discussion to next time a
unit test comes up where for someone it is PITA and he wants to
contribute in Java.
So I'm waiting for the decision...
m.
On 02/01/2013 04:04 PM, Adrian Nistor wrote:
Sure, but in this particular instance is revriting
MultiServerStartupListener to scala trivial or a PITA? Because if it's
trivial I then I would just do it.
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
7:05 a.m.
On 1 Feb 2013, at 14:57, Michal Linhard wrote:
On 01/31/2013 01:37 PM, Mircea Markus wrote:
>
> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>
>>
>> In this special case I'm gonna try to rewrite the test case as an
>> excercise - it doesn't seem like that much extra work, and I'd rewrite
>> it anyway I'm not satisfied with it's current form even if it was to
>> stay in Java.
> -1. If there's a choice it should be Java.
So I did some Scala excercise, which I quite enjoyed, but I have to
admit, it's not practical to require Scala in all the test code.
Michal, sorry for not making this clearer: wherever we have the option to choose between
Java and Scala - like in this case - we should write the code in Java and NOT Scala.
Can you submit a pull request with the Java version for review?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
1:24 p.m.
no probs. so what about this one?
https://github.com/mlinhard/infinispan/commit/9cfadec82dbd082cdaf1f162e5e...
On 02/04/2013 02:05 PM, Mircea Markus wrote:
>> -1. If there's a choice it should be Java.
> So I did some Scala excercise, which I quite enjoyed, but I have to
> admit, it's not practical to require Scala in all the test code.
Michal, sorry for not making this clearer: wherever we have the option
to choose between Java and Scala - like in this case - we should write
the code in Java and NOT Scala.
Can you submit a pull request with the Java version for review?
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
8:34 a.m.
Hi,
On Jan 31, 2013, at 12:45 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
Hi,
The REST module is written in Scala (both main + tests). We have some *test*
contributions written in Java (thanks mlinhard).
There was an IRC discussion on whether it's worth migrating the Java contribution to
Scala code or not.
Pros for migrating the contribution from Java to Scala:
- the REST module is written in Scala. Contributing these tests in Java would make the
module bi-lingual, potentially confusing future contributors
- even though this is not the case with this particular contribution, there might be code
duplications between the scala test suite and java test suite.
Cons for migrating the contribution from Java to Scala:
- there are contributors that are not familiar with Scala or are more proficient with
Java(such as mlinhard). Forcing them to contribute in a language they are not familiar
with would put them off
- my general feeling over time was that people (including me) are not very enthusiastic
about debugging and extending Scala code. So IMO if there's a choice between scala and
java (in the scope of the scala modules) we should stick to Java wherever possible (such
as this contribution).
This email is not about the migration of scala code to java, but about the very specific
contribution described above (even thought the mix of scala+java code in ISPN is a a very
interesting topic by itself).
My preference is for Scala projects to keep all code in Scala unless there's a major
force (i.e. lack of equivalent enums in Scala that can be injected into).
If we focus on this specific case, unless there's a huge rush to integrate the test,
this is a chance for the contributor (Michal) to get familiar with another programming
language, which I think is a really good thing.
Cheers,
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4126
days inactive
4133
days old
infinispan-dev@lists.jboss.org
37 comments
8 participants
participants (8)
-
Adrian Nistor -
Alan Santos -
Bela Ban -
Dan Berindei -
Galder Zamarreño -
Manik Surtani -
Michal Linhard -
Mircea Markus