How We (Mostly) Moved from Java to Scala
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Graham Tackley is the Web Platform Team Lead for guardian.co.uk and a Pragmatic Scala Adopter. He and his team make sure the website can scale and evolve the platform to enable reader engagement in new and innovative ways. Recently, most of his time has been occupied with the Open Platform Content API which provides access to all of the Guardian's current and historical web content.
GOTO Aarhus is the enterprise software development conference designed for team leads, architects, and project management and is organized by developers, for developers. As software developers and architects ourselves, we wanted to craft the ultimate conference.
The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community, staged in an intimate environment needed to support as much learning and networking as possible.<a href="http://gotocon.com/">http://gotocon.com/</a>
Scala backwards compatibility?
by
Chris Kelly
What strategies if any did you use to mitigate this?
Are singletons still evil in Scala?
by
Chris Kelly
Are singletons still evil in Scala?
:)
Do you still have Python/Django?
by
Chris Matts
Did you replace the Python/Django app or do you now need to support java and scala and a legacy python/django app?
Chris
Bad example
by
arnaud m
ArrayList<String> myList = new ArrayList<String>();
is not very good.
It should be:
List<String> myList = new ArrayList<>();
which is not very far from the Scala version:
val myList = new ArrayList[String]
Even it's a bit more verbose, the advantage is that it clearly separates the implementation choice (ArrayList) from the abstract API (List) required for the rest of the code.
<></string></string></string>
Re: Bad example
by
Rhys Parsons
val list: List[String] = new ArrayList[String]
OR
val list = new ArrayList[String].asInstanceOf[List[String]]
You're wrong that your Java version and the Scala version are similar in this respect: in the Java version you *always* have to specify the type on the left and right. Your example is being kind to Java. Consider this:
GenericHeavyLiftingWidget<VeryHeavyObject> hLiftingWidget = new GenericHeavyLiftingWidget<>();
GenericLighweightLiftingWidget<VeryHeavyObject> lLiftingWidget = new GenericLighweightLiftingWidget<>();
InMyHumbleNotSoHonestOpinion op = new InMyHumbleNotSoHonestOpinion(new RandomOpinion());
compared to:
val hLiftingWidget = GenericHeavyLiftingWidget[VeryHeavyObject]()
val lLiftingWidget = GenericLighweightLiftingWidget[VeryHeavyObject]()
val op = InMyHumbleNotSoHonestOpinion(RandomOpinion())
Note that here I've made use of companion objects which can be a really simple way to implement a factory pattern (and mean that you don't have to use the 'new' operator).
<></veryheavyobject><></veryheavyobject></string></string>
Re: Bad example
by
arnaud m
As you say:
List<String> myList = new ArrayList<>(); // not: ArrayList<String> myList = new ArrayList<String>();
seems to be semantically equivalent to
val list: List[String] = new ArrayList[String]
... in _this_ case, the Scala code is longer.
In your example
val hLiftingWidget = GenericHeavyLiftingWidget[VeryHeavyObject]()
Yes, of course, if you want the left (abstract) and right (implementation) types to be the same, 'val' is more compact.
But it allows to write implementation-specific code easier (e.g. a method only in ArrayList, not in List) which is probably not always a good thing. When you read List<String> in a variable declaration, you know that the following code is not dependent on ArrayList or on another specific implementation. (It's not just "free" verbosity in this case.)
When comparing Scala to Java, just compare it to correct Java code.
I think Scala is rich enough (SAM vs first-class functions, covariant generics,...) so that you don't have to use a trick to amplify the difference.
(I see that several times in various Java/Scala comparisons.)
</string></string></string><></string>
Re: Scala backwards compatibility?
by
Graham Tackley
It's never been a real problem for us. We wait until all the libraries we use are published for a new scala version and then we upgrade. And it's just worked - there's never been anything other than trivial changes we've had to make to any of our codebases to compile with new scala versions.
For shared libraries, we cross compile against all the scala versions we have in use, using sbt.
Personally I prefer this to a backwards-compatibility-at-all-costs, which ends up with things like HttpServletRequest.getHeaders returning an Enumeration (effectively deprecated in java 1.2).
Re: Do you still have Python/Django?
by
Graham Tackley
Re: Do you still have Python/Django?
by
virtual eyes
A paradigm shift in the works methinks.
Love me some Scala, yes indeed ;-)
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think