【IT】来月にはJava 10が登場し、9月にはJava 11が登場予定
■ このスレッドは過去ログ倉庫に格納されています
2017年9月に「Java 9」が登場したばかりですが、いまから1カ月後の2018年3月には早くもJavaの新バージョン「Java 10」がリリースされます。そしてその6カ月後の9月にはさらに次の「Java 11」がリリース予定です。
Java 9以後のJavaは、毎年3月と9月の年2回メジャーバージョンアップを行う、タイムベースのリリースモデルを採用することになりました。今年はその最初の年となります。
オラクルによるJDKの提供方法やサポートポリシーも、これから大きく変更されることが明らかになっています。一般公開され無償でダウンロードできたOracle JDKの公開はJava 10が最後となり、サポートは3年ごとに登場する長期サポート（LTS）対応のメジャーバージョンに対して行われる、といったことが予定されているのです。
こうしたリリースモデル、提供形態、サポートポリシーの変更は、既存のJavaアプリケーションの保守や今後の開発体制にも影響を与えるはずです。
バージョン番号は今後もJava 10、Java 11、Java 12と連番に
Java 9以降のJavaのバージョン番号は、これまで通りJava 10、Java 11、Java 12と連番で増えていくことになりました。
Java 9のリリース後、Javaのバージョン番号がリリース年とリリース月を合わせた数字、例えば2018年3月にリリースされるJava 10は「Java 2018.3」になるという説明もありました。その名残として、公式サイトでもバージョン表記が「Java 10（18.3）」や「Java 11（18.9）」と、バージョン番号とリリース年月の並列表記になっています。
しかし現在の方針は、いままで通り連番でバージョン番号を表していくことだそうです。バージョン番号とリリース年月を併記した「Java 10（18.3）」は、いずれバージョン番号のみにあらためられていくことになるのでしょう。
バージョンアップサイクルは6カ月ごと
Javaのバージョンアップサイクルは前述の通り、2018年3月にリリースされるJava 10から、6カ月ごとにメジャーバージョンアップが行われます。つまり2018年3月にJava 10、2018年9月にJava 11、2019年3月にJava 12、2019年9月にJava 13と続いていくのです。
そしてその合間の1月、4月、7月、10月の年4回、バグフィクスやセキュリティ対策に対応したマイナーバージョンが提供される予定です。
バージョンアップの基本的なポリシーは、機能の追加変更についてはメジャーバージョンアップで行われ、マイナーバージョンアップでは機能に影響のないバグフィクスやセキュリティ対応変更だけが行われるとされています。
なぜ6カ月ごとのメジャーバージョンアップを行うのか？
なぜJavaは6カ月ごとのメジャーバージョンアップへとリリースモデルを変更するのでしょうか。
Javaはこれまで、大きな機能追加に合わせてメジャーバージョンアップを行ってきました。大きな新機能の開発には長い時間がかかり、ときとして開発スケジュールの遅れにも苦しんでもきました。
例えば、Java 6から7へのメジャーバージョンアップには4年8カ月、Java 7から8へは2年8カ月、Java 8から9へは3年6カ月かかっています。
これはつまり、Javaの進化は数年ごとにしか起きなかったということを示しています。
安定が重視されるエンタープライズのシステム開発分野で使われることが多いJavaにおいて、この数年ごとのゆっくりした進化のペースは好ましいものでもありました。しかし最近ではJavaはほかの言語や技術と比較すると、進化の遅い、やや古めかしいものと見られるようになってきてもいました。
従来のリリースモデルをあらため、6カ月ごとにメジャーバージョンアップを行うタイムベースのリリースモデルへとJavaが移行したのは、こうした反省に立ってJavaをこれまでより速いペースで前進させようとしているためです。
http://www.publickey1.jp/blog/18/java_109java_11java.html Ｅタックスや電子入札システムが古い方を要求するので いつの間に9出てたんや
使ってんのまだ8だぞw
通知も来てないし ブラウザもそうなんだけどバージョンアップばかりうざい だいぶ前に信用切っている言語からよくわからない
今回のも互換性厳しいのか？ >>4
薄くなったけど１０年くらい前のシステムで現役のは結構Javaで作ってあるからメンテのお仕事あるよ Javaは画像を立体のようにドラッグで動かすのに欠かせないものだが、
最近ではこれをセキュリティ上危険だとして使えなくしているブラウザが多いようだ。 『人生はリベンジマッチ』
↑
名曲、ユーチューヴ検索 １５
それだけ勉強するの大変な言語なんですか？
できるひとすくないのかな >>9
html5のcanvasとか使えばいいじゃん 言語のアップデートは、もっと慎重であるべき
だと思う。書かれたものの寿命は、言語のそれより
ずっと長いのだから。比較的慎重だったPython3ですら
やっと追い付いてきた感じなんだから。 マジいい加減にしろよjava
もはやグローバルなVBライブラリだろコレ >>16
単純に仕事の量が多い
前時代的な軍隊方式の仕事をしてるところで使われてることが多くて
切り替えるにはコストがかかるので無くならない
ゆえにブラック派遣が多く、できる人ほど寄り付かないために常に需要ギャップがある
言語としては少し時代遅れな上に
古い資産にがんじがらめになってたりして、面倒なところはあるけど
とりわけ難しい言語じゃないです
というか、難しい言語と言うのはとくにないです、どれも慣れの問題です いや、そのオラクルがやる気無くしてるのが問題なんだって。
マイクロソフトのウインドウズと同じよ 現在のJavaの用途を考えると現場ではバージョンアップなんか要らねえと思ってるだろうな。
JavaScriptはJavaと違うものだから勘違いすんなよ。 >>13
>>15
百姓しながら兼業で土方やってるが、出稼ぎしなくてもいいから稼げる 早めに一度廃棄して
new Javaとして再定義しておけば
こんな地獄絵図は生まずに済んだのになぁ >>21 >>16
横槍で少し補足すると、言語自体は若干古臭いが決してクソと言うほどではない
まあ言語としては覚えやすい部類だろう
ただ、開発部隊のアホ率が高く、基本そいつらに合わせて作らされるから、
どアホでトンチキな構造のプロジェクトが出来上がる これきっかけにjava人口減るんかな
素直にcでもやろうか >>27
言語としては超糞って程ではないけど
やはり、過去のしがらみから抜けられずに引っ張って来てる分、根本的な部分の糞がそのまま引き継がれてる
で、問題は言語よりフレームワーク
オープンソースによって作られた同一目的の幾多ものフレームワークを
意識高い脳味噌のない開発者たちが使い方を理解せずに嬉々として積み上げたがために
溢れ続ける糞を際限無く拭き続ける仕事がまわってくる
結局、文化として糞 >>24
"Write once, run anywhere"じゃなかった？ 言語は安定させてこそだろうに。
バグフィックスなら必要だが、昨日今日出来た言語でもあるまいし
そんなに頻繁に機能追加する必要あるんか？ >>35
有料にして儲けるためには煩雑なアップデートで買わせる必要があるような 何が一回書くだけでOKだよ(笑)
もうめんどくさいだけだな 結果バージョン違いのVMを山ほどインストールすることになるのであったｗ
うんこすぎんだろ Javaが一回書けばどこでも動くというならばCだって一回書けばどこでも動くと言っていいレベル。 JavaをインストールしてもアンインストールしてもWindowsが壊れるから絶対に使わないようにしてるわ
Javaをいまだに使ってる会社とは完全に縁を切った。 >>2みたいに官公庁によって
要求されるverが違ったりしたことあるので
半年ごとだとver違い発生するだろうから
いくつものPCが必要になる可能性があるよね。 JavaとJSの立場が入れ替わる時代が来るとは思わなかったな ある会社が、毎回毎回検証作業をやってられん！
と業務システムの脱javaしたな
本当、いい迷惑 >>21
javaは異様に宣言が多い
Cベースと言えど、全く奇妙 >>36
そうやって言語の寿命を短くしている。ビジネスのためにシンプルで良いのにわざわざ難解にする。
javaは死ぬ。 >>35
設計が古臭いからな
モダンな仕組みをガンガン取り入れていかないと、新規案件で採用されなくなる
結果COBOLみたく閉鎖した社会が出来上がることになる >>3
9からは64bitのみのサポートに変わりました
32bitは切り捨てられた Javaの何が嫌いって、すぐに古い仕様を非推奨にしてくること。
昔買った分厚いJavaの解説本とか全部ゴミだ。 すぐ非推奨->廃止のせいでホイホイバージョンアップできない。うっかりやると動かなくなるからな。
結果として古いのが何時までも残ってセキュリティどうなんそれ？ 学生の頃にJava7アプデが来て、便利な機能が追加されたなぁって嬉々として見てた記憶
アノテーションの追加とかあの頃だったかな >>54
ほんとに困ったことある？
廃止されたメソッドに引っ掛かったことないな。
コンパイル時にdeprecatedが出るのは何度もあったが。 屋上屋を架すような追加はもうやめて、
一度リセットして言語仕様から新しく作り直した方がいい時期 gimpには大変世話になっているが
あれがjavaで作ったやつだっけ？
操作した時の反応が、わずかににぶいんだよね。 もうクライアントサイドのJavaは止めてサーバー側だけの開発に集中したらどう？ アップデートされずバージョンが違うマシンがそこら中にはびこる以外の未来が見えない。
あと、頻繁なメジャーアップデートは、問題解決に検索かける時のググラビリティにすげー負担がでるぞ。 >>61
クライアントでjava使ってるアホはもういないだろ
業務系サーバサイドは未だにjavaが多いよ
特に金融はjava一色 古いウエブサイトのゲームがこれがないと動かない
だがこれだけのために毎度毎度更新やら除外指定やらが必要になるという
ブラウザもほぼそれ専用のを用意する羽目に >>63
入門本とかで紹介されてるから、独学でJavaできますって人は大抵クライアントサイドのアプレットのことだったりする 未だにstruts1を魔改造してる日本のSI屋には関係ない話だなw 海外でも今でもJavaは最大勢力だけどな
ApacheプロジェクトがJavaばかりなのもあって海外でも特定言語への入れ込みがない、またはプロジェクトが大きくて特定言語に肩入れできないものほど無難にJavaで書かれてるし、それはこれからも続く >>51
最近はそのCOBOLをJavaに移行してるところがあるんだぜ？ Java EE は理想掲げすぎて仕様も動作も重くてクソだと思ってたけど
ああやって中央集権的にやらないとフレームワークが乱立して
フレームワークのスパゲッティになんだなと
JavaScript のフロントエンド界隈を見てわかった バージョンよりOracleのJVMが有料になる方が影響あると思う javaって
互換性の問題がつきまとう
現行バージョンで問題なく動作しても
アプデすると動かなくなるとか
勘弁してくれ >>73
むしろOracle独自扱いだった機能の多くがopenJDKでも使えるようになる >>74
それでは互換性問題のない言語を挙げてみるといいよ >>4
とは言えJavaの後継ってしっくり来るの無くない？ javaはもう要らんやつ多そうやけど
JVMはなんだかんだでまだ必要だろうなあ もともとちゃんとしたサポートが欲しいとか長期サポートを受けたいとかいった企業はOracle Javaの有償サポートを買ってた。
その今まで有償サポートオンリーで提供していた付加機能も含めてオープンソースで公開するので、自力で使える会社はそちらをどうぞって話でしょ。
別に今までと変わらないし、むしろJava Flight Recorder使いたかった自力のある企業にはかなり嬉しい話だよ。 Javaの有償化はAndroid(kotlin)にどういう影響あるの？ 意味のないバージョンアップに付き合わされるのは勘弁だなあ
セキュリティパッチが昔のバージョンもしっかりやってくれるならどうでもいいけど 流石にサイクル短すぎだろ。
コンシューマー製品でもない
そんな不安定な開発言語誰が好き好んで使うんだ？ LTSが分かりにくいな〜
LTSが10ならnon LTSは10.1とか10.2とかに...もダメだな
商用にはLTSで有償契約を結ぶ以外に選択肢なし か。サーバーサイドはともかく、クライアントサイドは死んだな JDK有料化か
ってことはAndroid開発環境も有料になってしまうな 有償なのはサポートで、JDK自体は無料やで。
問題は有償契約を結ばないLTSのセキュリティパッチがどこまで提供されるか。
まぁAndroid開発環境は大丈夫じゃないかな。最後はGoogleが何とかしてくれる。 >>77
C#は今のところ基本Windowsでしか動かないのでNG
業務アプリでMonoは問題外だしLinux版の.netはまだ何ともいえないし >>91
AndroidやiOSでの採用例増えてきてるけどな >>71
結構バッチはCOBOLでオンラインをJavaってパターンはあるな Java有料化したらマイナーOSでの開発は何でやればいいのか
Cですかそうですか >>82
Kotlinでもライブラリはjavaだよね？ バージョン番号がわかりにくい
8なのか1.8なのかはっきりしろ Java 10でもっとも含まれる可能性が高い機能は、
JEPで現在対象の状態がTargetedもしくはProposedのものだ。
現時点で以下の機能が該当する。
★ 286: ローカル変数の型推論
296: JDKフォレストの単一リポジトリへの統合
304: ガベージコレクタインタフェース
307: G1でのパラレルフルGC
★ 310: アプリケーションのクラスデータ共有
312: スレッドローカルのハンドシェイク ・OracleがJDKの全ての機能をオープンソース化し、Java EEの欠点に取り組む計画を発表した・・・・・2017年11月27日
今年のJavaOneオープニングの基調講演において、Oracleは、GPLでJava SEをリリースし、
Oracle JDKの全ての機能について、オープンソース化する計画を発表した。
また、Java EEは、マイクロサービスとサーバレスの新世界に適合していないことを認め、
この問題に取り組む計画について話した。現代のマイクロサービスアーキテクチャのケーススタディは、
AlibabaとSpotifyによって提供された。基調講演のビデオは、YouTubeで視聴できるが、ここでは、
重要な情報を要約して提供する。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
★Oracle、Java EEの移管先にEclipse Foundationを選ぶ・・・・・2017年9月22日 ★「Javaのバリュータイプに対する設計が進んでいる・・・・・2017年12月12日 ★JavaのMVC 1.0の仕様に対するパブリックレビューが公開に・・・・・2018年2月2日
JSR-371、
これはModel-View-Controller (MVC) バージョン1.0の仕様であるが、パブリックレビューが公開されている。
2017年4月にオラクルが所有権をIvar Grimstad氏へ移管して以来、これが最初のメジャーリリースである。
移管のあとすぐにIngenit GmbHのシニアソフトウェア開発者であるChristian Kaltepoth氏が共同スペックリードとして
Grimstad氏に加わった。JSR-371は後にApache License 2.0ライセンスとなり、
2017年10月にGrimstad氏は最終的なリリース後にMVC 1.0をEclipseファウンデーションへ移管する意向を公表した。
初期ドラフトレビュー2以降の新機能は以下のものである。
国際化 - I18Nのサポート。
データバインディングの改善 - データバインディングとバリデーションに対して@MvcBindingアノテーションと
BindingResultクラスを使ったMVC仕様のルールが可能に。
仕様ドキュメントに挙げられているように、MVC 1.0の目標は以下のものである。
既存のJava EE技術を活用する。
CDI (JSR-346)とBean Validation (JSR-349)を統合する。
MVCアプリケーションを構築するためのしっかりした核を定義する。最初のバージョンで必ずしも全機能をサポート
するのではない。
JAX-RSの上に重ねる方法を調査する。マッチングとバインディングのレイヤを再利用するため。
JSPとFaceletsをビュー言語としてビルトインでのサポートを提供する。
EE4JのEclipse OzarkプロジェクトはJSR-371の完全な実装を提供する。これはRESTEasyとJersey、Apache CXFをサポート
する。Ozarkのバージョン1.0はJSR-371の最終リリースとともに2018年の第2四半期にリリースされると思われる。 素のjavaでの開発案件はたいてい奴隷を募集してる Javaと書いている人のレス とりあえず一度は真剣に目を通して吟味する
javaと書いている人のレス 業界知識はありそうだけどプログラムはやらないんだろうな
JAVAと書いている人のレス がんばれCOBOLおじいちゃん！
ジャバと書いている人のレス ケンカすることしか考えてなさそうなので読まない >>89
有償結ばないとパッチのDLもできなくなるそうな Open Javaってあった気がするんだけどどうなったの？あれ 質問スレからの転載となりますが何卒ご了承下さい。
eclipseでメモ帳を作っています。
テキストファイルの文字列を編集可能な状態で出力したいのですが、やり方が分かりません。
Scanner(System.in)でキーボードから入力された文字列のような、そのまま直接キーボードで編集可能な文字列として出力したいのですが……。
何卒知恵を御貸しください。
お願いします。
追記、Scanner(file名)による入力のやり方を発見しましたが、そのままSystem.inと繋げるようなやり方はできないのでしょうか？
Scanner(file名)で得た文字列をSystem.inで編集したいのです android端末売れても儲からんから作る側を締めに来たか >>111
オラクルがAndroid端末作ってるの？ androidは二年前にOpenJDKに移行してる NetBeansなどのIDEが追いつかなくなったら、廃れそう。 ■ このスレッドは過去ログ倉庫に格納されています
