Javaの10個のBad Partsのほとんどはscalaだと解決されちゃうんだぜ

ネタ元
業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策

結論から先に言うと、3と10以外は結構直接的にscalaで解決できるというか、javaに比べてscalaの方が便利だとおもいます。*1
あと、元ネタのblogの人はgroovy詳しいみたいですが・・・
groovyとscala比べるとgroovyの方が手軽で便利だったり、scalaのほうが型安全だったり*2いろいろあるかもしれませんが、groovyあまり詳しくないので、その辺の言及というか、比較はやめておきます。*3

1.標準APIのチェック例外が扱いにくい

チェック例外ってなにそれおいしいの?(・ω・)

java

Field field;
try {
	field = getClass().getField("testField");
	Object value = field.get(this);

} catch (SecurityException e) {
	// 例外処理
} catch (NoSuchFieldException e) {
	// 例外処理
} catch (IllegalAccessException e) {
	// 例外処理
}

scala

val field = getClass.getField("testField")
val value = field.get(this)
//例外処理書きたくないなら書かなくていいよ

2リソースの解放処理の適切な記述が面倒

scalaは、リソースの開放の処理分離して書けるんだぜ

// tryブロックの外で宣言
Reader in = null;

try {
    in = new BufferedReader(new FileReader("ファイル名"));

    // 入力処理
    
} catch (IOException e) {
    // 例外処理

} finally {
    // finallyブロックで後処理
    if (in != null) {
        try {
            in.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

元ネタのblogでもコメントで言及されてますが、C#的なusingという制御構造*4を定義しておけば、

using(new BufferedReader(new FileReader("ファイル名"))){
in =>

//inがBufferedReader型になり、それを使用した処理をここに書く。

}//この時点で、自動で閉じられる

という感じで書けます。

3 日付関連APIの使い勝手が悪い

scalaの標準ライブラリに専用のものはないので、とりあえずはJavaのモノ使うしかなく、使い勝手は悪いです(・ω・｀)jodaTimeとか使ってください。immutableでscalaと相性いいし。まえにjodaTimeラップするようなちょっとしたDSL作ったことがあります。

追記:
jodatimeをwrapしたscala-timeっていうのがあるらしいです*5
https://github.com/jorgeortiz85/scala-time

4 BigDecimalを使った固定小数演算が面倒

scala.math.BigDecimalっていう、javaのBigDecimalをラップしたものがあります。

java

BigDecimal num1 = new BigDecimal("123456.789");
BigDecimal num2 = new BigDecimal("111.111");
		
BigDecimal result = num1.multiply(num2);

scala

//new も不要
val num1 = BigDecimal("123456.789")    
val num2 = BigDecimal("111.111")   
// * で演算できる。* はscala.math.BigDecimalのメソッド
val result = num1 * num2

かけ算するのにmultiplyって書くのはめんどくさいよね・・・
すべてがオブジェクトで、すべてメソッドで処理しよう!そしてメソッドには省略せずにわかりやすい名前付けよう的なJavaの文化はいいときもありますが、こういう場合くらいは短く書きたいよね。
scalaなら、methodの名前に記号が使えるので、上記のようなことができます。

5 標準の文字列演算APIが限られている

StringUtils.isEmpty(str);

なぜisEmptyを例に出した・・・
nullと空文字かをチェックするなら大してめんどくさくないっていうか。*6
isBlankならわかるけど・・・*7

コメントもらった

まえそのisBlankについてscalaに書き直す方法的な感じで書いたことあったな・・・

複数文字列からの文字の生成については
javaの場合、apache commonsを使って、こうなるけど・・・

String[] strArray = {"data1", "data2", "data3"};
StringUtils.join(strArray);

scalaなら、

//標準ライブラリしか使ってないよ!
Seq("data1", "data2", "data3").mkString(",")

あと、Stringのmethodに関しては、scalaでも、implicit使うことによってWrappedStringというものに変換され、自動でjava.lang.Stringにmethod追加されたような感じで便利に使うことができます。*8

6 正規表現APIを使うのが面倒

Rubyとか正規表現リテラルがある言語に比べればちょっと使いにくいかもしれませんが、Javaよりは確実に使いやすいものが、標準ライブラリにあります。

一番便利なのが、 r という名前のメソッドで、Stringから簡単に正規表現のオブジェクトをつくれることでしょうか?
あと、パターンマッチの構文と統合されていたり。

ちょっとそのほかいろいろ解説するのは大変なので、あとはググッてください(・ω・`)

7 長い文字列の記述方法が面倒

Groovyには「'''」「"""」という3つのクオーテーションを使って長い文字列を定義する仕組みがあります。

scalaも同じで、「”””」という3つのダブルクォーテーションの文法あるので、略。*9

8.基本型とラッパークラスの存在

scalaではIntやDoubleも全部オブジェクトですよ。基本的には意識する必要ないようにできてます。それでいて、primitiveのままでいいところは、実際のbytecode上ではprimitive型のまま扱ってくれて、パフォーマンスもそんなに問題になりません。

9 配列型とコレクションとの不統一

配列はlengthフィールドで長さを取り出すのに、Listはsize()メソッドで長さを取得するなど、まるで統一感がありません。

scalaでは、引数なしのメソッドはカッコ省略できるので、*10この問題発生しない*11

Genericsについては、もう一つ大きな違いとして配列と違いコレクションの型は反変性

・・・反変? Javaの配列が共変っていう話じゃなくて？ 本人からコメントもらったので修正

scalaには、Listなどのimmutableなclassが共変(covariance)になっているので、List型がList