Visual Studio Code (VSCode) で SpringBoot の実行時に Active Profile を指定する
はじめに
VSCode で Active Profile を設定する場合、どうするのが良いだろうと調査したので書いておきたいと思います。
SpringBoot には Active Spring Profile という機能が存在します。
開発環境、本番環境で使うDBの種類やリクエスト先のサーバーURLが異なる場合に、設定値で切り替えると思いますが、
この機能で環境毎に設定ファイル自体を切り替えることができるようになります。
方法
デバッグ実行の設定から Active Profile を指定して起動するものを追加するのが良さそうです。
Active Profile を有効にして起動するには以下の方法があります。
- コマンドライン引数にして渡す。起動時のオプション指定に --spring.profiles.active を指定する。
- Java System Option に渡す方法。起動時のオプション引数に -Dspring.profiles.activeを指定する。
「Run and Debug」から設定を追加します。
左サイドメニューから「Run and Debug」のボタンをクリックし、
歯車マークを押すことでlaunch.jsonファイルを開くことができます。
launch.json の configurations に、argsに --spring.profiles.active=<環境名>を指定した設定を追加します1。
今回追加した設定は以下になります（product 毎に変化する場所は必要に応じて変更してください）。
{ "type": "java", "name": "Launch SpringTutorialApplication Local", "request": "launch", "mainClass": "jp.co.who.spring_tutorial.SpringTutorialApplication", "projectName": "spring_tutorial", "args": "--spring.profiles.active=local" },
この設定を保存後、Debug Run の項目から、追加したRunタスクを選択できるようになります。
今回の例だと「Launch SpringTutorialApplication Local」になります2。
application-local.property 、application-local.yaml を使って SpringBoot が起動されます。
参考
Visual Studio Code (VSCode) でJavaの開発環境を用意する
はじめに
動機
私は普段Javaなどの開発をするとき、IntelliJ IDEA Ultimateを使って開発しています1。
しかし、私の周りの環境ではVisual Studio Code (VSCode)を使われるケースが多く、
Javaの開発もVisual Studio Codeで整えたいという要望があるのですが、
私に知見がなく、説明するのが困難で合ったため、
一度真剣に開発環境を構築し、その時の情報を保存しておこうとしました。
Visual Studio Code が望まれる理由
Visual Studio Code を使う場合のメリットについても少し考えてみました。
これは私の観測範囲ベースも含まれていますが、
Visual Studio Codeの長所であったり、
こちらの方が（少なくとも IntelliJ IDEA よりも）望まれている理由としては以下があります。
- 豊富や拡張パックで柔軟に機能をカスタマイズできる
- 他言語の開発を扱う現場で、ワンツールで完結する
- 無料で使うことができる
もしこの中で魅力に感じる部分があれば
Visual Studio CodeでのJava開発環境に挑戦して見ても良いかもしれません。
Visual Studio Code 設定
Visual Studio Code のインストール
以下のダウンロードサイトから環境に合った圧縮ファイル、またはインストーラーをダウンロードし、
開発環境にインストールします。
- Windows の場合、インストーラー、またはzipファイルをダウンロードします。
インストーラーからインストールする場合は、手順に従ってインストールしてください。 - zipファイルをダウンロードし、解凍すると実行ファイルが含まれています。
実行ファイルを適切な場所に移動すると良いと思います。
Mac の場合、必要に応じてAppにコピーします。
JDK のインストール
JDKをダウンロードし、開発環境から使用できるように準備が必要です。
Java は複数の組織がバイナリを提供しているため、提供元が複数存在します。
Java は互換性があるため、多くの場合では違いを意識する必要はありません、
環境毎で指定のJDKがあれば、指定のものをダウンロードして利用してください。
特に指定やこだわりがなければ Oracle、もしくは Adoptium あたりを使われる場合が多い印象があります。
SDKMAN を用いたインストール
SDKMAN を用いてJDKのインストールすることが可能です。
Windows 以外であればこの方法が一番おすすめです。
ディストリビューションの一覧やダウンロードまで実施できますし、
利用に必要な設定や管理も行えます。
SDKMANのインストール方法・使用方法は以下を参考にしてください。
SDKMAN を用いたJDKのインストールの例を以下に示します（java.net OpenJDK 18 の場合）。
sdk install java 18.0.1.1-open
実行すると、以下のような出力がされ、インストールが実行されていきます。
Downloading: java 18.0.1.1-open In progress... ################################################################################################################### 100.0% Repackaging Java 18.0.1.1-open... Done repackaging... Cleaning up residual files... Installing: java 18.0.1.1-open Done installing! Do you want java 18.0.1.1-open to be set as default? (Y/n): Y Setting java 18.0.1.1-open as default.
Java Extension Pack の Getting Start の機能からダウンロードする
後述する「Java Extension Pack」インストール後であれば、Visual Studio Code 上の操作から JDK をダウンロードすることが可能です。
Java Extension Pack の「Get Start with Java Development」の機能からもJDKをインストールすることができます。
Visuial Code Studio を開き、「Help」->「Get Start」を選択します。
「Walkthroughs」の「More...」をクリックし、「Open Walkthroughs...」という検索ボックスが出るので「Get STarted with Java Development」を入力し実行する。
「Get STarted with Java Development」の画面に遷移するので、「Get your runtime ready」という項目から「Install JDK」をクリックします。
「Install New JDK」という画面が表示されるので、必要なJDKをインストールすることができます。
各JDKディストリビューションのダウンロードサイトから取得する
各JDKのディストリビューションのダウンロードサイトから取得する方法があります。
何箇所かのディストリビューションとダウンロード先は以下になります。
Visual Studio Code の設定
拡張パックの追加
Javaの開発で必要となる拡張パックをインストールします。
必要となる主な拡張パックは以下になります。
| 拡張パック名 | パッケージURL | 概要 |
|---|---|---|
| Extension Pack for Java | https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack | Java の開発用拡張パックです。 Javaのコード補完、ビルド、GUIからのJUnit（ユニットテスト）実行などが可能になります。 |
| Spring Boot Extension Pack | https://marketplace.visualstudio.com/items?itemName=Pivotal.vscode-boot-dev-pack | SpringBoot 開発用拡張パックです。 SpringBoot由来のアノテーションの解決や機能と参照できるようになります。 SpringBootを使用しない開発では不要です。 |
| Lombok Annotations Support for VS Code | https://marketplace.visualstudio.com/items?itemName=GabrielBB.vscode-lombok | Lombok 用の拡張パックです。@Getter, @Setter, @Slf4jなどのLombok由来のアノテーションの解決ができるようになります。Lombokを使用しない開発では不要です。 |
Java用の設定追加
設定ファイルにJavaを実行するための設定を追加します。
setting.json にJDKへのパスを指定する java.jdt.ls.home を設定します2。
{ "java.jdt.ls": "/Users/<user_name>/.sdkman/candidates/java/current/" }
<user_name> は環境に応じて読み替えてください。
java.home のパス自体も環境に応じて変更してください。
settings.json を表示させる方法は設定画面から、右上の方にある「Open Settings」の画像をクリックして表示することができます
設定画面の出し方は以下のいずれか
| OS | 画面での操作 | ショートカットキー |
|---|---|---|
| Mac | 「Code」-> 「Preferences」->「Settings」 | 「Command」+「,」 |
| Windows | 「File」-> 「Preferences」->「Settings」 | 「Ctrl」+「,」 |
設定の完了
以上で設定は完了です。
開発が必要なレポジトリーを使って確認してみてください。
開発対象のレポジトリーがない、Javaプロジェクトの作成方法がピンとこない。という方がいましたら、
動作確認用に以下のレポジトリーを用意しましたので、お試しください。
ご参考までに。
最後に
結び
Visual Studio Code でJavaの開発ができるようになりました。
開発ツール自体の初期設定やJDKのダウンロードなどが必要でしたが、
手順を進めれば開発環境が作れることが実証できました。
参考
Intellij IDEA の GUI から force push したい
JetBrain IDE から remote branch に対して force push をするための方法について
git push -f 相当をしたい場合です。
どこかに書くほどではないのですが、最初わからず彷徨っていたので備忘録も兼ねて記載します。
環境については以下
- MacBook Air（M1 2020）
- IntelliJ IDEA 2022.1 (Ultimate Edition)
以下の記事で設定変更をする方法が説明されているのですが、現行（2022現在）では設定変更は不要です。
IntelliJ の GUI から git push -f したい - Qiita
local branch でamend commit や rebaseを行った際、
remote branch と差が出てしまい、デフォルトの設定のままでは push しても失敗します。
※２種類の矢印で差分があることがわかる。rebase や merge をして push しても、reject される。
この対処方法として、コマンドラインから Git を使う場合は、git push -f で強制 Push する方法がありますが、
JetBrain IDE では Push するときに「Force Push」を選択して実行することが可能です。
Commnad + Shift + K で Push ダイアログを表示。
「Push」ボタンの右下のプルダウンから「Force Push」を選択し、強制Pushを行うことが可能。
追記:
masterへの force push はデフォルト設定では無効になっています。
もし master へ force push したい場合は設定変更が必要になります。
（業務ではほぼないと思いますが）
[Preference]から設定ダイアログを開き、[Version Controle]->[Git]で設定。
[Push] の[Protected branches]の設定を変更。
保護するブランチ名を変更、もしくは空白にします。
「良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方」を読みました
はじめに
技術書を読みました。 読んだのは以下の本、「良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方」です。
設計について有名なミノ駆動さんが書かれた本ということで発売前から注目度の高かった本なので、 ご存知の方も多いと思います。 逆張り思考の私としては「読んでなるものか」と思っていたのに、誘惑には勝てず購入をしてしまい、 読んだ後には充実感を得るほどの満足できる内容の本だったため、ブログに記載してみようと思いました。
該当書籍を読んでみて
おすすめしたい部分
実際に読んで感じた、おすすめできる部分として以下の部分を感じました。 - 構成が構造的、表現も理解しやすい内容の文章で読みやすい - 悪い設計の例がかなり具体的（あるあるすぎて共感する） - 悪い例の後に、良い例を説明している。悪い例の課題への対処方法が書かれている。 - 経験があるエンジニアの持っている「設定をするときの当たり前」をしっかり言語化されている
もう少し
まず、かなり「読みやすかった」というのが第一印象です。 構成がしっかりされていて、課題の説明から入り、解決方法について、解説という流れが全体にあるので、 納得しながら読み進められました印象です。 表現も理解しやすいもので説明されている印象だったため、解釈がとてもわかりやすかった印象です。
内容で説明されているリファクタリングテクニックもかなり具体的かつ実用的なものが多いと感じました。 悪い設計・実装例について、例文がソースコードとして載っていますし、 問題点だけでなく、しっかりその対応方法についても説明されているのがとても好印象を受けました。 どういう風に当てはめれば良いか、という点についても前述した課題の説明からされているので、想像しやすいと思います。
この手の本や資料は「課題だけ」や「テクニックだけ」となるものも少なくない印象ですが、両方説明されているのが良いと感じました。 「理想像をイメージする大切さ」について、著者が取り組んできた空手の経験から説明もされていましたので、 そういった部分を意識し、意図した内容になっているのかなと想像しています。
発売記念勉強会1で話されていた時、「プログラムの入門を終え、設計の専門書に挑む前に読むエントリー本のイメージ」という旨の発言をされていたと記憶しているのですが、 まさにその表現の通りの内容になっていると感じました。
一度設計について学んだ人でも、再確認や復習として、とても参考になるのではないかと思います。
さらに勉強を進めたい人用に参考書籍の紹介や取り組み方も最終章に記載されているので、どこまでもフォローが行き届いているという充実ぶりでした。
M1 Macと docker compose の付き合い方について考えた
はじめに
背景
Mac Book Air 2020 年モデル、いわゆるM1 Macを買いました。 今まで使っていた Dockerを動かすとき、docker composeの使い方が変わったので、その内容について記載します。
まえがき
CPUが Apple Silicon と呼ばれるもので、ARMプロセッサーのCPUになります。 以前までのIntell製のCPUと違う点がよく挙げられるのですが、 ソフトウェア開発者視点で遭遇するものの一つにDockerがあります。
今までIntel製で動いていたDockerファイルが動かない。と言われたり、実際になったりすることがあります。 というか、なりました。
M1 mac の Docker、アーキテクチャが違って起動できない場合はちゃんと表示してくれるんだな pic.twitter.com/gKDkf6XxI5
— 名前迷子 (@maigo_name) 2022年4月30日
その時の Docker、docker compose の使い方についてをまとめようと思います。
環境
今回試した環境は以下 - OS: macOS Monterey - CPU: AppleM1 - メモリ: 16GB
方法
具体的な対応方法について、知っている範囲で説明を記載していこうかと思います。
ARM CPU 対応版の Docker ファイルを利用する
既存のDockerファイルがあり、コミュニティの方でDockerファイルを管理されている場合、 ARM CPU 対応されたイメージがある場合があります。
cassandra を例にすると、Intel CPU で動く cassandra、 ARM 対応した arm64v8/cassandra があります。 そういった対応版を使うとよさそうです。
その他：アーキテクチャを指定する
Docker の起動時、プラットフォームを指定する方法です。 マルチ CPU アーキテクチャのサポートを活用 — Docker-docs-ja 19.03 ドキュメント
1年ほど前（2021年）の時点では、mysql などはM1 Mac で起動すると起動が失敗するケースがあったようです。 （いま手元で試したら mysql は起動したので、Docker側で対応されている気がする）
その際は docker で起動した時にアーキテクチャ指定を行うことで起動していました。
起動時のオプションに--platform linux/x86_64を指定します。
docker compose について
Intel CPU、arm CPU が混在する環境、チームではどうすると良いかと考えた時について。 個人的な解決しては「docker composeファイルの差分ファイルを作って、読み込むようにする」という結論に落ち着きました。
docker-compose.yaml は複数指定すると、差分を上書きして実行してくれます。
ファイル間、プロジェクト間での Compose 設定の共有 — Docker-docs-ja 19.03 ドキュメント
これを利用して、開発者ごとに差分を読み込むようにします。
共通の docker compose ファイル。docker-compose.yamlとする。
version: '3' services: sandbox-service: build: context: . dockerfile: ./Dockerfile tty: true volumes: - ../:/app working_dir: /app ports: - 8080:8080 cassandra: image: cassandra:4.0 tty: true ports: - 9042:9042
差分の docker compose ファイル。m1mac.yamlとする。
version: '3' services: cassandra: image: arm64v8/cassandra:4.0
それぞれの環境ごとでコマンド実行時に読み込みを行います。
- Intel CPU ユーザー
docker compose -f docker-compose.yaml up -d
- ARM CPU ユーザー
docker compose -f docker-compose.yaml -f m1mac.yaml up -d
アーキテクチャ指定で起動する場合でも、docker-compose ファイル、環境差分ファイルにも起動オプションに上記を指定すれば問題ないのかなと思います。
終わりに
無事にM1Mac でも Docker、docker composeが使える目処がたちました。 まだ触れ出したばかりなので、色々試していきたいと思います。
SpringBoot/Gradleのlogback脆弱性更新したときの方法
はじめに
log4j2 の脆弱性 が2021年12月10日に報告され、
任意のプログラムを実行できる危険性があるため、早急に対応することが必要という事で話題になりました。
logback にも「同じ脆弱性の懸念がある」という報告が12月14日におこなわれました。
https://jira.qos.ch/plugins/servlet/mobile#issue/LOGBACK-1591
これらの脆弱性の対応方法はライブラリのバージョンアップすることになります。
log4j2, logback の更新を自分のレポジトリーで行ったので、実績として残しています。
脆弱性バージョン更新の対応
log4j 2 の脆弱性対応について
私の関係しているものでは log4j2（log4j-core） をログ出力の実装ライブラリとしてつかっているのはなかったのですが、
slf4j は使っていたので、log4j2-api は依存として含まれていました。
脆弱性の原因とされていた JNDI lookup 機能は log4j-core で使われているので、関係ないのですが、
影響度が大きさと、あげない理由もなかったので対応しておこうと思いました。
その時に参考にさせていただいたブログは以下になります。
自分は SpringBoot/Gradle/io.spring.dependency-management plugin の構成だったので、
上で参考にさせていただいたブログのとおり、以下の記述を build.gradle に設定することで対策できました。
ext['log4j2.version'] = '2.15.0'
※ブログ記載現時点で lookup 機能自体が削除された 2.16.0 がリリースされているので、そちらを使うのが良いと思います。
補足
この方法が良いと思ったのは、関連する log4j 2 のライブラリバージョンをまとめてバージョンアップできるためです
dependencies で個別のライブラリのバージョンを更新しても対象のライブラリの更新は可能ですが、
他にも log4j 2 関連の依存ライブラリが含まれていて、更新しておけばよかったとか、
log4j 2 のバージョンが異なって食い合わせが良くないとが発生するのが気になるところが懸念としてありました。
※バージョン違いによる懸念は参考にさせてもらったブログにも書かれていましたね。IFやシグネチャの変更などが理由。
logback の脆弱性対応
12月14日時点ですでに対応版の 1.2.8 がリリースされているので対応しました。
log4j 2 と同様にgradle の ext に logback のバージョンを指定することでバージョン更新可能です。
- build.gradle
ext['logback.version'] = '1.2.8'
アップデートの確認。依存する logback が 1.2.8 に更新されているのが確認できる
> .\gradlew dependencies |findstr logback | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8
追伸
build.gradle の dependencies にライブラリを直接している場合は注意した方がよさそうです。
そちらにバージョン指定していた場合、そちらが優先されるため。
dependencies {
// log
implementation "ch.qos.logback:logback-core:1.2.7"
}
> .\gradlew dependencies |findstr logback | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7 +--- ch.qos.logback:logback-core:1.2.7 +--- ch.qos.logback:logback-core:1.2.7 (n) | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7 +--- ch.qos.logback:logback-core:1.2.7 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7 +--- ch.qos.logback:logback-core:1.2.7 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7 +--- ch.qos.logback:logback-core:1.2.7 | | | +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8 | | | | +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7 +--- ch.qos.logback:logback-core:1.2.7
最後に
迅速な対応をいただいたライブラリメンテナーの皆様、 情報共有をいただけた皆様にまことに感謝いたします。
Java /Gradle shadow プラグインの力で fat Jar を簡単に作る
はじめに
動機
今はあまりなくなってしまいましたが、Java のプログラムを fat Jar として作って頒布する機会があったので、その時に試した方法について記載します。
Java は長期的に動くサーバーサイドの開発などに使うことが多いと思うので、そういうケースは少ないと思いますが、
Java の資産を使ったモジュールを作ったり、古いソフトウェアのメンテナンスなんかでそういうユースケースがあるという認識です。
Gradle の shadow plugin*1 を使えば簡単に fat Jar を作れました。
環境
今回、私の実行するために利用した環境は以下になります
fat Jar について
fat Jar とは依存関係含む、すべての class を含んだ jar ファイルのことです。
plugins {
id 'java'
}
group 'com.github.keyno63'
version '1.0-SNAPSHOT'
repositories {
mavenCentral()
}
dependencies {
implementation 'com.fasterxml.jackson.core:jackson-databind:2.13.0'
}
// jar 実行の manifest の設定
jar {
manifest {
attributes "Main-Class": "com.github.keyno63.app.Main"
}
}
例えば、Jackson を使ってコマンドラインから渡した Json 文字列を分解するような、
以下のようなプログラムがあったとします。
package com.github.keyno63.app;
import ...;
public class Main {
public static void main(String[] args) throws JsonProcessingException {
final List<String> argsList = Arrays.asList(args);
if (argsList.size() > 0) {
ObjectMapper mapper = new ObjectMapper();
final JsonData json = mapper.readValue(argsList.get(0), JsonData.class);
System.out.println(json);
}
}
public static class JsonData {
private final String value;
@JsonCreator
public JsonData(@JsonProperty("json_key") String value) {
this.value = value;
}
@Override
public String toString() {
return String.format("""
{
"json_key": "%s"
}
""", value);
}
}
}
単純にビルドして実行すると以下のように失敗するかと思います。
> .\gradlew clean build
BUILD SUCCESSFUL in 1s
3 actionable tasks: 3 executed
> java -classpath ".\build\libs\gradle-shadow-1.0-SNAPSHOT.jar" com.github.keyno63.app.Main '{\"json_key\": \"json_value\"}'
エラー: メイン・クラスcom.github.keyno63.app.Mainを初期化できません
原因: java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/JsonProcessingException
依存関係の com.fasterxml.jacksonが生成した jar に含まれていないので、実行時に依存関係が解決されずに失敗します。
実行するためには依存関係のある jar への classpath を通すと実行することもできます。
> java -classpath "<jackson の jar への path>;.\build\libs\gradle-shadow-1.0-SNAPSHOT.jar" com.github.keyno63.app.Main '{\"json_key\": \"json_value\"}'
{
"json_key": "json_value"
}
それでも動くのですが、頒布する場合とかに利用してもらう人に依存関係の jar ファイルを用意してもらうのもハードルが高いので、fat Jar を作ることにしました。
fat Jar にすれば、依存関係をすべて含むその jar のみで完結して実行することができます。
> java -jar .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar '{\"json_key\":\"json_value\"}'
{
"json_key": "json_value"
}
fat Jar を作る選択肢
fat Jar を作る他の選択肢としてあがるのは以下になるかと思います。
build.gradle 設定を変更する方法は複雑かつややこしいように感じたので、できれば自動化に近い仕組みを使いたかったので選択肢から外れました。
gradle-fatjar は 2015 年以降更新されていないので、選択肢から外れました。
以上の理由から shadow プラグインを使うようしました。
Gradlew にshadow プラグインを使う
すること
対応することは以下の2点です。
- plugin に shadow を追加する
- gradle shadow コマンドでfatJar を作る
build.gradle の編集
build.gradle にすることは plugins に shadows を追加するだけです。
plugins {
id 'java'
id 'com.github.johnrengelman.shadow' version '7.1.0' // 追加
}
jar をそのまま実行できるように manifest の設定を追加しておくのもお勧めです。
// jar 実行の manifest の設定
jar {
manifest {
attributes "Main-Class": "com.github.keyno63.app.Main"
}
}
fat Jar 生成
あとはターミナル、およびIDEのコマンドから gradle shadowJar相当を実行します。
デフォルト設定のままであれば .\build\libs配下に実行用の jar ができています。今回であれば gradle-shadow-1.0-SNAPSHOT-all.jar というのができています。
> .\gradlew clean shadowJar
> dir .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar
jar の中身をみると、依存関係のパッケージのクラスも含まれているのがわかります。
> jar tf .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar
META-INF/
META-INF/MANIFEST.MF
com/
com/github/
com/github/keyno63/
com/github/keyno63/app/
com/github/keyno63/app/Main$JsonData.class
com/github/keyno63/app/Main.class
META-INF/LICENSE
META-INF/maven/
META-INF/maven/com.fasterxml.jackson.core/
:
動作確認
生成した jar を指定して、実行可能なのが確認できます。
> java -jar .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar '{\"json_key\": \"json_value\"}'
{
"json_key": "json_value"
}
以上で無事やりたいことが達成できました。
最後に
かなり簡単に目的を達成できる方法だと感じました。
追加の設定も特に不要なのがありがたいですね。
