Scala/Java cheat sheet feedback request

Syntax
1

Hello!
I’m looking for feedback for a page I’m working on to help people read Scala or Java if they know the other one. Things I’d like help with include errors and omissions.

https://www.jeffshaw.me/cheat/


Thanks

1 Like
2

I’ve purposefully left out most topics involving collections, since it’s too big a topic for a beginner’s reference. It could be another page.

3

I sent you a pull request with some additions and a fix.

Overall, I think your cheat sheet is good for looking up things if you have used both languages at least some time, but if a Java developer used this cheat sheet while learning Scala, it may cause him to write code that isn’t idiomatic Scala, especially because of the various examples using var. But that problem may be inherent to the cheat sheet format, because the idiomatic solution may not have a direct java equivalent without also changing several other parts of the program. I don’t know if this could be improved.

4 
class C(var i: Int)

isn’t shorthand for

class C {
  var i: Int = _
  def C(i: Int) {
    this.i = i
  }
}

The second should be written

class C() {
  var i: Int = _
  def this(i: Int) = {
    this()
    this.i = i
  }
}

but note that this has two constructors, a no-params one, and a one param one. It’s not syntactic sugar for the former.

I would suggest removing the second entirely, and just list class C(var i: Int)

5

Then, shouldn’t it be:

class C private () {
  var i: Int = _
  def this(i: Int) = {
    this()
    this.i = i
  }
}

?

6

Then it still has two constructors, but one is private. A better alternative would be

class C(i_: Int) {
  var i = i_
}

but I don’t see why listing syntactic sugar that’s just a normal constructor would be a good idea.

7

This is a subtle point. Thanks @martijnhoekstra and @charpov for pointing this out. I’ll just remove the expansion.

8

It’s sufficiently subtle that I had to consult the spec to be entirely sure, and come to the conclusion that the code example on the spec didn’t compile, so don’t worry about that :smiley:

9

A few remarks after a quick look at the sheet:

  • Interfaces:

    interface I {
  void method(int i) {}
}

    should probably be:

    interface I {
  void method(int i);
}

  • Wildcards:
    Scala’s [A <: T1 with T2] would be <A extends T1 & T2> in Java (using &, not a comma).

  • The section on statics is not clear and probably cannot be without getting into companion objects. You need an example of a Java class with bot static and non-static fields/methods.

  • You could mention the private[this] of Scala, which has no Java equivalent.

  • I don’t understand you scoping discussion of switch. If really there is a single scope in Java (which I doubt), shouldn’t the second int i declaration be rejected?

  • Why not use the standard CompletableFuture in Java?

      CompletableFuture<Integer> add(CompletableFuture<Integer> f1, CompletableFuture<Integer> f2) {
    return f1.thenCompose(i1 ->
      f2.thenApply(i2 ->
          i1 + i2
      )
  );
}

    (The async/non-async distinction is more complicated; Java offers more control than Scala there.)

  • The lambda section reminded me of why I prefer to program in Scala :slight_smile: (and that’s without even mentioning that Java’s lambdas cannot throw checked exceptions…)

10
  • interfaces: I added a method stub example, since Java and Scala can each do both
    @charpov
  • wildcards: Thanks for the correction
  • statics: Good points. I’ll have to think about this more.
  • private[this]: added
  • switch: Java’s switch has one lexical scope that is shared between the cases. In fact it’s the same lexical scope as the surrounding block, so you really can’t redeclare values inside of a switch. I know, it’s weird to me too.
  • CompletableFuture: I’ll use your example. I used ListenableFuture since it’s what I’m familiar from code we have at work. It’s from Google’s Guava.
  • lambdas: Ya that part about checked exceptions sucks. I’ve run into it before.
11

You might want to check the document for compliance with the Web Content Accessibility Guidelines (WCAG). For example, run it through WebAIM’s WAVE tool http://wave.webaim.org/

12

Thanks @hccunningham. That gives me some ideas about how to structure the page better.

13

As a person who teaches in a US university and produces course materials, I have recently become sensitized to the need to produce materials that are accessible to individuals who use screen readers (e.g for persons with visual impairments) and other assistive technologies.

1 Like
14
  • For an interface method to have a body in Java, you need the default keyword.
  • Your own code example shows that separate switch cases have their own scopes, since you introduce a variable i in each one. I think the difference with Scala is that Scala lets you shadow a local variable in an inner scope, which Java doesn’t:
    // possible in Scala but not in Java
val i = 0;
{
  val i = "foo"
}
    This makes it impossible in Java to introduce in a switch case a variable name that is already in the scope of the switch statement.
15

Are you suggesting someone might use my page for teaching? That’d be very cool.

16
  • default: done
  • scoping: That’s a good point and something I’ve never come across except in switch/case statements. Thanks for helping me understand the reason it’s like that. I tried to clarify it by making a new section for lexical scoping and moving the switch example there.
17

I will likely put a reference link to it in my course materials for the Scala-based course on functional programming I am teaching beginning in a couple days. … But in any event, it is a good practice to make any document or Web page reasonably accessible to individuals who need to use assistive technologies to consume or interact with the content.