【朗報】IntelliJ脱出！Emacs/EglotでScala・Kotlin開発は可能か？JavaのLSPが貧弱すぎる問題で議論沸騰
投稿日時: 2026/07/21 19:04
■ 概要・編集部サマリー
【背景・課題】IntelliJ依存から脱却すべくEmacs Eglot等でScala/Kotlin環境を構築する試みが進む一方、Java周辺のLSP（jdtls等）の品質が低いという不満が噴出。 【焦点・技術】ScalaではMetalsがEmacsでも問題なく動くが、JavaではjdtlsがGradleビルドで頻繁に落ちるなど不安定。Tree-sitterベースで高速LSPを自作する動きも登場。 【評価・議論】「LLMがあっても前例のない優れたJava LSPを生み出せない」という開発手法への懸念や、「大多数はIntelliJを使うためLSP需要が薄い」という需要論争まで波及。
1. IntelliJ独占に対する軽量テキストエディタの挑戦
ScalaやKotlinなどの高度な型システムを持つ言語はIntelliJ IDEAへの依存度が高く、エディタの動作重化が開発者の悩みであった。
Emacsの標準LSPクライアントであるEglotを用い、MetalsやKotlin Language Serverとの統合環境を構築する実験が行われた。
2. Metals/Kotlin Language ServerとEglotの補完性能
Scala環境においてはMetalsの完成度が高く、IntelliJと同等の補完や定義ジャンプが爆速で動作することが実証された。
一方で、KotlinのLSPサーバーは公式のサポートが手薄であり、一部のリファクタリング機能に制約が残る現状も正直に報告されている。
3. エディタの自由とミニマリズムの追求
重厚なIDEに拘束されず、使い慣れたキーバインドでJVM開発を行うための貴重なセットアップガイドである。
オープンなLSPエコシステムの進展を感じさせてくれる。
海外掲示板の反応・まとめ
■ 記事概要 IntelliJ IDEAから脱却し、Emacs + Eglot環境でScalaやKotlinのLSP（Language Server Protocol）を構築するノウハウが話題に。 コメント欄では、ScalaのMetals環境の優秀さと比較して「まともなJava LSPが存在しない」という悲壮感や、LLM（生成AI）では優秀なLSPを作れない理由について激しい議論が交わされています。
ScalaのMetals公式ドキュメント通りにEmacs設定したら、ワークシートも含めて普通に完動したわ。 もうIntelliJ重すぎて戻れんぞ。
Scalaはええな…それに比べてJavaのLSPは何なんだよ。 jdtlsとか使ってみろ、実質Eclipseをヘッドレスで動かしてるだけだからGradleビルドでボロボロ落ちるぞ。 未だにまともなJava LSPがないの本当ひどい。
>>3 VS CodeのJava拡張（Red Hatのやつ）で一応動くやろ？IntelliJレベルではないけど普段使いなら耐えられるわ。 あとなんかOracle公式のVS Code拡張がRed Hat製より評価高いらしいけど誰か試した？
そもそも何でエディタ側にJava LSPが必要なん？ CIと同じビルドツール叩けば十分やろがい。
>>5 エアプ助かる。 CIツールとLSPは別物だろｗ LSPはエディタ上でリアルタイムの型チェック、シンタックスエラー検出、補完、フォーマットを提供するための標準規格やぞ。
「AI（LLM）があれば人間がコード書く必要なくなる！」とか言われてるけど、結局まともなJava LSPすら作れてないのが現実やね。 前例のない基盤ツールを作るのはLLMが一番苦手とするところや。
誰も作らんから自分でJava/Kotlin用の爆速LSP（ktlsp）作ってるで。 JVMや重いコンパイラに頼らず、Tree-sitterで構文解析だけして動かしてるからIntelliJより圧倒的に軽くて速い。GitHubで公開してるから見てくれや。
ぶっちゃけJavaエンジニアの9割はIntelliJお決まりで使ってるから、単にLSPの「需要がない」だけなんだよね。 一部のEmacs/Vimオタクが騒いでるだけだろ。
>>9 ワイという需要がここにあるんだが？？（存在証明） 重いIDEに強制連行される世界から抜け出したいんや…