2019/04/20 このエントリーをはてなブックマークに追加 はてなブックマーク - JVM言語とJDKバージョンを今後どう組み合わすのか

JVM言語とJDKバージョンを今後どう組み合わすのか


さて、Java is still freeなわけですが
https://medium.com/@javachampions/java-is-still-free-2-0-0-6b9aa8d6d244
https://www.sakatakoichi.com/entry/javaisstillfree

どのJDKをどのバージョンで使うかねぇという話がありますよね。

JDK 8を使い続けるという選択肢もあります。
いろんなベンダーがLTS(long term support)としているJDK 11を使うということも出来ます。
色々考えてみましょう。

※ JDKも色々種類があったりで迷ったんですが、一旦バージョンを区別するだけのためにJDK 8などと表記しています。(Java SEとかいう言葉を使うかどうかも迷った)
※ 分かってる人は読まないで良い内容を書きます。
※ 分かってるけどお時間ある人は、読んで間違いなどあれば指摘もらえると嬉しいです。
※LTS https://en.wikipedia.org/wiki/Long-term_support
※いろんなディストリビューションのJDKがいつまでどのバージョンでサポートするかは各ベンダー次第ですが、大体JDK 11をLTSとしていると思います


Java と JVM言語、どれを使用するにしても気にする大前提は

  • JDK 8で大体のJVM言語は動くと思う(思う)
  • しばらくこのままJDK 8 を使おうという場合は、OpenJDKのディストリがおすすめです
  • バージョン上げるならJDK 11です。2019年04月現在、LTSだから
  • JDK 9はLTSじゃないから忘れましょう(JEPやJSRは忘れないで)
  • JDK 10はLTSじゃないから忘れましょう(JEPやJSRは忘れないで)
  • バージョンアップ(or 何か変更)するということはテストが必要ということです
  • 自分の開発プロジェクトの依存ライブラリ・フレームワークのバージョンごとの対応状況をまず見よう
  • ビルドツールのバージョンごとの対応状況を見よう
  • JAXBのことを考えよう
  • 実行環境のバージョンごとの対応状況(サーバーサイド?Android?デスクトップ?マルチプラットフォーム?とか)を見よう

あたりだと思います。


ScalaのバージョンごとJDKのcompatibilityが公表されています。
このあたりScalaはドキュメントきっちりしていて良い。

https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html

sbtなどに関してはこの記事が今でも有用な気がします。
ScalaコンパイラやsbtとJava 9の対応表

これも重要そうですね。
https://github.com/scala/bug/labels/jdk9
https://github.com/scala/bug/labels/jdk10
https://github.com/scala/bug/labels/jdk11

その他、言語 + AkkaだとかPlay2だとかScalaの各ライブラリやフレームワークの対応状況を見つつということになると思います。


大前提としても前述しましたが、順々にアップデートすれば良さそうですね。

  • Leiningenのバージョン気にする必要がある。
  • 各ライブラリのアップデートをする必要がある。
  • JAXB気にする必要がある。

https://www.deps.co/blog/how-to-upgrade-clojure-projects-to-use-java-11/


この記事に良いこと書いてあって、ライブラリのバージョンを先にあげて、
JDKのバージョンアップ後から上げる方が楽というのは確かに…!!と思いました。

この他の情報はきっと、Clojure詳しい人たちが教えてくれる…!


Groovy 3.0でJDK 11をサポート予定のようです。
しばらくはJDK 8にしといた方が良さそうですね。

https://www.infoq.com/jp/news/2018/08/apache-releases-groovy-2.5
http://groovy.329449.n5.nabble.com/Groovy-and-JDK-11-Compilation-issue-td5752777.html


Kotlinはコンパイラで JDK 6 or JDK 8 コンパチなビルドをするので
後方互換のあるJDK11でも大丈夫というスタンス。 ワイルドだろう?
https://stackoverflow.com/questions/52888341/does-kotlin-support-java-11

サーバーサイド


サーバーサイドだったらSpringとかあたりのフレームワークのバージョンとかを気にした方が良さそうですね。これはJava + Springであっても言えることだと思います。

Android


アンドロイド用途だったらJDK 8のまんまでも良い、というか無難な気はします。zuluやadopt open jdkとかをおすすめします。
Android SDKとの差が少ないという意味で開発しやすそうに思います。
でも開発はOpenJDK 11でするというのも出来るはず。


OpenJDKの選び方としてはこれが参考になるっぽいです。 と、JDKソムリエが言っていたので良い資料のはず。 https://ipc.kyokyo-u.ac.jp/page/696

自分のプロジェクトにあった計画を立てましょう。
(JDK云々の話は、今に始まった話ではなく1年前から公表されてたので、気にしているところはもう計画立ってるはず…)




2019/03/15 このエントリーをはてなブックマークに追加 はてなブックマーク - とりあえず動かすためのCircle CI 1.0からCircle CI 2.0への移行

とりあえず動かすためのCircle CI 1.0からCircle CI 2.0への移行


FINAL NOTICE: Two days left to upgrade your CircleCI configuration by March 15


This is the final notice reminding you that one or more of your projects has recently used the CircleCI 1.0 infrastructure, which will no longer be available after March 15, 2019.

In order to address this issue and keep your project(s) building, please see:

Instructions on seeing which projects still use CircleCI 1.0 config
A guide to migrating from 1.0 to 2.0
CircleCI 1.0 EOL policy
In two days, all projects will require a circle/config.yml, the 2.0 configuration file type, to build on CircleCI. It’s possible that your project is currently missing a configuration file, and is building on CircleCI 1.0 by default. 

We know we have sent you a number of notifications in recent weeks regarding 1.0 EOL. At the risk of over-informing you, our goal is to make sure that zero teams or projects are caught unawares when they can no longer build on CircleCI 1.0 on March 15, 2019. 

We are here to help in making this switch, please visit the migration center.

Thanks again, 
The team at CircleCI

こんなメールが来ていたわけで。超めんどいな、と思ってスルーしていたんですが、
まぁ書き直すかぁということでやってみました。

ちょうど今日、pushしたら動かなくなっていて…(ちなみにきっかけは、せらさんのこのプルリク…ほんとすみません!!! https://github.com/yyYank/kotlin-rev-solution/pull/23)
3/15だからそうか、ということで修正しました。


Circle CI 1.0から Circle CI 2.0へ移行するために必要なことは以下です。


出来上がったものをガッと修正したら、以下のようになりました。
正直、元々のcircle.yml が綺麗人変換されているということはなく、勢いで書き換えました。

version: 2
jobs:
  build:
    working_directory: ~/yyYank/kotlin-rev-solution
    parallelism: 1
    shell: /bin/bash --login
    # CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did.
    # If any of these refer to each other, rewrite them so that they don't or see https://circleci.com/docs/2.0/env-vars/#interpolating-environment-variables-to-set-other-environment-variables .
    environment:
      CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
      CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
    # In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages.
    # In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images.
    # The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job.
    # We have selected a pre-built image that mirrors the build environment we use on
    # the 1.0 platform, but we recommend you choose an image more tailored to the needs
    # of each job. For more information on choosing an image (or alternatively using a
    # VM instead of a container) see https://circleci.com/docs/2.0/executor-types/
    # To see the list of pre-built images that CircleCI provides for most common languages see
    # https://circleci.com/docs/2.0/circleci-images/
    docker:
    - image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
      command: /sbin/init
      command: /sbin/init
    steps:
    # Machine Setup
    #   If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
    # The following `checkout` command checks out your code to your working directory. In 1.0 we did this implicitly. In 2.0 you can choose where in the course of a job your code should be checked out.
    - checkout
    # Prepare for artifact and test results  collection equivalent to how it was done on 1.0.
    # In many cases you can simplify this from what is generated here.
    # 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/'
    - run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS
    # This is based on your 1.0 configuration file or project settings
    - run:
        working_directory: ~/yyYank/kotlin-rev-solution
        environment:
          TZ: Asia/Tokyo
        command: 'echo ''Asia/Tokyo'' |  sudo service mysql restart; sudo service postgresql
          restart; '
    - run:
        working_directory: ~/yyYank/kotlin-rev-solution
        command: sudo rm -rf /var/lib/apt/lists/*
    - run:
        working_directory: ~/yyYank/kotlin-rev-solution
        command: sudo apt upgrade
    - run:
        working_directory: ~/yyYank/kotlin-rev-solution
        command: sudo apt-get update --fix-missing
    - run:
        working_directory: ~/yyYank/kotlin-rev-solution
        command: sudo apt install python3-pip
    # Dependencies
    #   This would typically go in either a build or a build-and-test job when using workflows
    # Restore the dependency cache
    - restore_cache:
        keys:
        # This branch if available
        - v1-dep-{{ .Branch }}-
        # Default branch if not
        - v1-dep-master-
        # Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly
        - v1-dep-
    # This is based on your 1.0 configuration file or project settings
    - run: pip install mkdocs==0.16.3
    # Save dependency cache
    - save_cache:
        key: v1-dep-{{ .Branch }}-{{ epoch }}
        paths:
        # This is a broad list of cache paths to include many possible development environments
        # You can probably delete some of these entries
        - vendor/bundle
        - ~/virtualenvs
        - ~/.m2
        - ~/.ivy2
        - ~/.bundle
        - ~/.go_workspace
        - ~/.gradle
        - ~/.cache/bower
    # Test
    #   This would typically be a build job when using workflows, possibly combined with build
    # This is based on your 1.0 configuration file or project settings
    - run: echo "-----start test-----"
    # This is based on your 1.0 configuration file or project settings
    - run: echo "-----no test-----"
    # This is based on your 1.0 configuration file or project settings
    - run: echo "-----end test-----"
    # Deployment
    # Your existing circle.yml file contains deployment steps.
    # The config translation tool does not support translating deployment steps
    # since deployment in CircleCI 2.0 are better handled through workflows.
    # See the documentation for more information https://circleci.com/docs/2.0/workflows/
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: mkdocs --version
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: mkdocs build --clean
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: git config --global user.email yy.yank.me@gmail.com
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: git config --global user.name yyYank
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: git commit ./site/* -m "build [ci skip]"
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: git pull git@github.com:yyYank/kotlin-rev-solution.git master
    - run: 
        working_directory: ~/yyYank/kotlin-rev-solution
        command: git push git@github.com:yyYank/kotlin-rev-solution.git master

元々やっていた、リポジトリのpushからのherokuデプロイはCircle CI 2.0でもできるようになりました。
https://yyyank.blogspot.com/2016/06/circlecibuildgitpush.html


なんか、deploymentとかteardownが書かれたymlが生成されたわけですが、
なかなかうまくいってなかったのでごりっと直しました。
あと、pipのインストールとかあたりも全然ダメそうだったので、書き直しました。


ただ、これだと各phase(build, deploy, test)がごっちゃになってて綺麗じゃないですね。

stormcatさんの記事でも見て、そのうち綺麗にしようと思います。

https://blog.stormcat.io/post/entry/circleci2.0-overview01/




2019/03/13 このエントリーをはてなブックマークに追加 はてなブックマーク - brew install go @ 1.10するとGOROOT指定しないとgo get出来ない!?

brew install go @ 1.10するとGOROOT指定しないとgo get出来ない!?



表題の通り。


  • Max OS X (high sierra)

  • go@1.10をbrewでインストール

    brew install go@1.10

    して、インストールし/usr/local/opt/go@1.10/bin/goにPATHを通す

  • なにかしらをgo getする

    go get -u github.hogehogeohge

import path does not begin with hostname
が発生。


import path does not begin with hostnameは
GOROOTがらみの時に発生することが多いようで、つまりはPATH通ってないからgo自体のパッケージが見つかってないよということみたいです。

で、GOROOTを設定しないといけないわけですが、
GOROOTってそもそも設定しないで良い時代なのではという気持ちになります。

https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really
https://kwmt27.net/index.php/2013/06/14/you-dont-need-to-set-goroot-really/

GOROOTの設定が必要なるのはGOROOTを移動させる時ぐらいらしい。


  • もうユーザーが環境変数として設定する必要は無いらしい
  • go env GOROOTすると、goのビルド時のGOROOTが取得できる。ユーザーが環境変数を設定しない場合はこれが使用されるらしい
  • goのプロセス実行前にGOROOTは決定するので、goのコードでosにset envとかしてもGOROOTは書き変わらないらしい

https://golang.org/pkg/runtime/
https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
https://github.com/golang/go/issues/22302


ということで、実際に確認してみる。
brew install したものをみてみると

 /usr/local/opt/go@1.10/bin/go env GOROOT 
/usr/local/opt/go/libexec

実際のGOROOTにあたるディレクトリをのぞいてみると

ls /usr/local/opt/go@1.10/libexec/
bin     go      gocache tmp 

ls /usr/local/opt/go@1.10/libexec/go 
AUTHORS         PATENTS         bin             misc            test
CONTRIBUTING.md README.md       doc             pkg
CONTRIBUTORS    VERSION         favicon.ico     robots.txt
LICENSE         api             lib             src

…どういうことや!?

というと、GOROOTの位置が変わっちゃってるみたいなんですよね。brewからinstallしただけのはずなのに。
そして、何回かbrew unistallとbrew installを繰り返しても再現するのでした。
自分だけなんだろうか。
(2019/03/12の出来事)

しかし、以前 別の端末にbrew install go@1.10した際は

/usr/local/opt/go@1.10/libexec/go
なんてディレクトリはなくて、
/usr/local/opt/go@1.10/libexec 
が GOROOTになっていました。


  • 最近の変更で、brewでインストールするgo@1.10がぶっ壊れてる(brewが原因)
  • brewでインストールしたものがぶっ壊れた(自分の端末が原因)

  • GOROOTを環境変数として設定して調整する
  • GOROOTをgo env GOROOTと合わせる(戻す?)

いかがでしたか?(言ってみたかった)

ということで、ハマった時はそのあたり見直してみてください。