Java有償化まとめ

**デフォルトの名無しさん** · 2018/07/23(月) 15:03:10.26

よく分からんのでまとめて下さい。
会社のローカル開発環境はお金払うの？
JavaRuntimeとかあったような…
諸々よろしく。

**デフォルトの名無しさん** · 2018/11/05(月) 23:23:36.71

うんにゃ
移行先としては妥当って話

**デフォルトの名無しさん** · 2018/11/05(月) 23:54:29.41

OracleのリスクはギャーギャーいうのにMSはいいんかーい

**デフォルトの名無しさん** · 2018/11/05(月) 23:58:01.01

>>724
C#やってないから知らんのだけどLinux上のJavaのシステムをC#でリプレイスするぞー
というのは堅実的なんか？

**デフォルトの名無しさん** · 2018/11/05(月) 23:58:37.98

>>726
堅実的→現実的

**デフォルトの名無しさん** · 2018/11/06(火) 00:01:28.20

>>726
元がJavaって前提ならね
下手なスクリプト言語よっかよっぽど現実的だしパフォーマンスもダンチ

**デフォルトの名無しさん** · 2018/11/06(火) 00:12:52.19

>>728
周辺ライブラリやエコシステムも？

**デフォルトの名無しさん** · 2018/11/06(火) 00:38:21.95

>>729
も？

**デフォルトの名無しさん** · 2018/11/06(火) 00:46:04.34

>>730
も以降先として充実してる？

**デフォルトの名無しさん** · 2018/11/06(火) 01:01:36.23

>>731
具体的に何がしたいのか知らないけど、.NETで駄目なら相当ニッチな分野かと

**デフォルトの名無しさん** · 2018/11/06(火) 01:33:01.17

>>725
リスクないもの。

**デフォルトの名無しさん** · 2018/11/06(火) 02:11:14.68

Java→C#はプログラムソース転用出来ないからね
ソース転用出来ないならVB.NETでも変わらん
それこそJava→PHP,Perl,pythonでも同様
組み替えになるのは変わらない

**デフォルトの名無しさん** · 2018/11/06(火) 05:37:14.36

スクリプトで済むんなら最初からスクリプトで組んでるだろうし、そうなるとJavaの移行先はC#しか無いわな。
MSのエコシステムで固めれば至れり尽くせりではあるし。

**デフォルトの名無しさん** · 2018/11/06(火) 05:51:41.46

C#はJavaと同じ運命をたどるかもわからん、もう嫌だわ
かといってRubyはやる気が起きん
特許抵触部分を取り除いたJ--言語を誰か作ってくれんかな

**デフォルトの名無しさん** · 2018/11/06(火) 07:29:42.86

>>734
そのまま転用はできないけど、スクリプト言語よりマシ
てかVB.NETとか頭おかしいわ

**デフォルトの名無しさん** · 2018/11/06(火) 08:37:10.10

Javaの代わりにOCamlはどうだろう？
MSのF#もOCamlがベース。
BucklescriptでOCamlでJavaScriptも書ける。
便利だよね？

**デフォルトの名無しさん** · 2018/11/06(火) 12:54:04.86

サーブレット、JSPはスクリプト系言語に取って変わられる
それ以外の部分はC#と言うか.NET

**デフォルトの名無しさん** · 2018/11/06(火) 19:05:24.00

Scala終了ということでok?
Android開発には影響なさそう&nativeという道があるkotlinは将来性ありそうだが

**デフォルトの名無しさん** · 2018/11/06(火) 21:33:04.78

ScalaはOracle問題とは一切無関係にとっくに完全終了してるよ
もうElixirくらいのマニア言語の一つであり、実用的には全く無視して差し支えない

**デフォルトの名無しさん** · 2018/11/06(火) 21:35:48.70

あるtwitterより

というかOpenJDK、Windows版もあるのか。わざわざアプレットのために仮想環境用意しなくて済むかもしれぬ

アプレットとかまだ使ってるヤツ居るんだな

**デフォルトの名無しさん** · 2018/11/06(火) 21:46:03.13

>>741
いつ始まってたの？

**デフォルトの名無しさん** · 2018/11/06(火) 21:51:16.68

Scalaも遅まきながらnative開発に乗り出している
https://github.com/scala-native/scala-native

とはいえ、Kotlinとは違いGoogleのAndroid公式サポート言語宣言のような大きなプッシュをしてくれる
IT界の巨大企業なんかもついていないし、コミュニティ自体も小さいし
かりにnative開発に成功して脱JVMを成し遂げても、メジャーな言語への変貌はおそらくないだろうな

◆QZaw55cn4c · 2018/11/06(火) 22:37:12.24

>>744
CPU でさえ x86 の皮をかぶっているだけで、中身は別物だときいています、そんな世にあえて native にこだわる理由はなんでしょうか？

**デフォルトの名無しさん** · 2018/11/06(火) 23:48:25.30

scalaはむしろJavaから離れたら枯れる気がする

**デフォルトの名無しさん** · 2018/11/07(水) 17:23:45.30

oracleは、tck通ってればjavaに関して保有してる特許権も無償で利用できるようにするけど、tck通ってない場合はダメってはなしだったかなと

**デフォルトの名無しさん** · 2018/11/07(水) 19:41:30.43

TCK通過じゃないのは裁判起こします

**デフォルトの名無しさん** · 2018/11/07(水) 20:31:28.11

現状Oracleの許可なしで改変されたソースバイナリ共あちこちで配布されてるわけだが

**デフォルトの名無しさん** · 2018/11/07(水) 21:09:58.42

今から業務系のシステムを作るとなったらJava以外に何採用すればいいの？

**デフォルトの名無しさん** · 2018/11/07(水) 21:11:36.24

すぐ上でC#とか話されてた
失礼

**デフォルトの名無しさん** · 2018/11/07(水) 21:12:25.78

>>746
とっくに枯死してるんだが

**デフォルトの名無しさん** · 2018/11/07(水) 21:30:55.74

MSの良い？所は(開発環境を作った)コードに対してしか課金しない。
(最近はApple真似て開発環境無料で年会費取るけど)

CPUやコア数で課金しない。
(開発人数では課金するけど、逆にVSエンプラが無いのは、それだけ開発者を揃えられない(悪い意味での)証だったから、VSエンプラ入れてない会社なんてなかった)

個人的にはWinMobileとかの方が初期投資さえ済ませれば好きに作って配布できた分楽だった。
(ファイルへのアクセス含め)
ユーザーやセキュリテイ的には今の方が安全かもだけど、開発的には楽。

個人でも最適化欲しさにProは買ってた。

**デフォルトの名無しさん** · 2018/11/07(水) 21:32:32.93

>>753
日本語

**デフォルトの名無しさん** · 2018/11/07(水) 21:34:24.80

デスクトップや小規模なwebアプリには今はいい時代になったと思うけど、モバイル向けの環境は学習にはやや不便。

**デフォルトの名無しさん** · 2018/11/09(金) 02:47:06.75

あるtwitterより

効率よく開発できるならプログラミング言語は何でも良い派ですが、

Javaに関してはOracleJDKにしてもOpenJDKにしても、そこまでしてJavaにこだわる必要はもうほぼないよねという印象です。

今後Oracleが何するか読めないのも面倒くさいし、どうしても必要な場合を除き弊社ではJavaでの開発はやめました。

**デフォルトの名無しさん** · 2018/11/09(金) 06:30:24.87

>>756
言語そのものしか使っていないならその通りだが、それ以外のツールなどを使って
エコシステムにどっぷり漬かっていると、そうできないからみんなこんなに騒いでいる。

**デフォルトの名無しさん** · 2018/11/09(金) 08:17:18.34

今後の新規開発にJavaを一切使わないのは現在Javaにべったり依存している組織においても技術的にはそれほど難しいことではない
問題は、>>757の「それ以外のツール」ってのがSIerにとってはJavaドカの工数と事実上ほぼ同義であることで、この状況を覆すのは容易ではない
そもそもJava自体が何よりも "Learn Once, Work Everywhere" の性質を背景にして普及してきたプラットフォームであるわけで、
他の言語と比べても人的リソースに特に強く左右される言語であることはいうまでもないだろう

**デフォルトの名無しさん** · 2018/11/09(金) 10:14:37.95

Learn Once, Work Everywhere, Pay Someday

**デフォルトの名無しさん** · 2018/11/09(金) 14:58:51.56

>>693
Androidのアプリ開発してるところは、Android 6.x以前の端末に対してアプリ提供を
続けていくつもりなのかな？
Android 6.x以前の端末に対しては、そもそもGoogleがOSサイドでOpenJDK対応して
ないから色々難しい面があるのではないかと思うけど

**デフォルトの名無しさん** · 2018/11/09(金) 16:12:24.58

>>760
Android6.0.1以前は切り捨てでしょ

**デフォルトの名無しさん** · 2018/11/09(金) 22:58:22.21

古いバージョンのJVMを使っていても強制的に金払わないといけないんですか？

**デフォルトの名無しさん** · 2018/11/09(金) 23:13:39.87

Java8があと数年更新されるから
Java8を使って置いて、サポートが切れた＆Java8で脆弱性が見つかったら
OpenJDKの最新版に乗り換える、とかで良いのかな？

**デフォルトの名無しさん** · 2018/11/10(土) 00:45:41.82

>>763
Java8の無償サポートって、期限来年の１月末までなんですが....
もう残り3ヶ月切ってるよ
個人のPCでネット接続しないスタンドアローンのものならば構わないけど、
そうじゃない限りサポート無しっていう訳にはいかないだろ
金払いたくないけどJava使いたいならOpenJDKぐらいかな選択肢は

**デフォルトの名無しさん** · 2018/11/10(土) 00:46:54.88

OpenJDKの開発環境のセットアップとか
アプリへの同梱作業は難しかったりするの？

**デフォルトの名無しさん** · 2018/11/10(土) 00:49:46.77

OpenJDKもLTSが無いとかでAdoptOpenJDKが最有力に思える
でも信頼性が無い・・・

**デフォルトの名無しさん** · 2018/11/10(土) 01:00:53.51

>>766
信頼性とかRedHatエンプラやIBMもねーよ

**デフォルトの名無しさん** · 2018/11/10(土) 01:06:50.31

>>254
バトルフィールド５の初日パッチで修正される不具合
135ページに渡るらしいぞ。
開発間に合わなかったのかね

**デフォルトの名無しさん** · 2018/11/10(土) 01:16:17.70

Java8+JavaFXでやってるけど
AdoptOpenJDK 11に乗り換えるか・・・
Eclipseもアプリ側も変更になる
どれくらい大変なんだろうか

**デフォルトの名無しさん** · 2018/11/10(土) 01:52:14.25

8u192はadoptopenjdkに4日後に来てた

https://adoptopenjdk.net/archive.html?variant=openjdk8&;jvmVariant=hotspot
jdk8u192-b12 2018/10/20

https://adoptopenjdk.net/archive.html?variant=openjdk8&;jvmVariant=openj9
jdk8u192-b12 2018/10/20

https://www.oracle.com/technetwork/java/javase/8u192-relnotes-4479409.html
2018/10/16

http://openjdk.java.net/projects/jdk8u/releases/8u192.html

**デフォルトの名無しさん** · 2018/11/10(土) 01:58:05.98

https://openjfx.io/
https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#release-notes-for-javafx-11

バグは修正していってるみたいだけど、8->11の互換性のことは触れてなさそう。

そういえば、openjfx8はoraclejdkがないとビルドできなかったけど、どうなったんだろ。

**デフォルトの名無しさん** · 2018/11/10(土) 02:09:29.48

ありがとう。とりあえず11で試みて、ダメそうだったら8でビルドしてみる

**デフォルトの名無しさん** · 2018/11/10(土) 05:46:20.37

>>769のJavaFX 11体験談に期待。
http://mevius.5ch.net/test/read.cgi/tech/1404491265/
あたりでお待ちしています。
こちらはGluonのOpenJFX11を使いたいけど、32bit環境が残っているので足踏み状態。

**デフォルトの名無しさん** · 2018/11/10(土) 15:53:21.95

・AdoptOpenJDKのLTSは、オラクルのサポートが打ち切られた後にバグが見つかったら、
独自修正するんだろうか？
・その場合、その修正はオラクルの特許に絡まないんだろうか？
・絡んだ場合、AdoptOpenJDKの再配布はリスクだろうか？

**デフォルトの名無しさん** · 2018/11/10(土) 20:24:22.62

あらゆるソフトウェアが数多ある特許の何れかを侵害してしまうリスクを抱えているのでは

**デフォルトの名無しさん** · 2018/11/10(土) 22:23:41.41

>>774
結局Javaそのものがリスクになるんだよ。
Oracle以外がそうならないように頑張っているのは周知のとおりだけど、
Oracleが自分のところ以外のLTSを潰しにかかって言いがかりをつけ始めたら
泥沼化は避けられない。
そこまで馬鹿ではないだろうとか勝ち目はないだろうとか、そうならない
だろう材料は当然あるけど、どんな馬鹿が台頭するかもわからないわけで。

それを、ある日インターネットが世界的に禁止されたら、と同じ程度の
リスクと考えるか、ガソリンがレギュラー160円になるくらいのリスクと
考えるかはあなた次第。それをうまく立ち回れるのが求められている事。

**デフォルトの名無しさん** · 2018/11/10(土) 23:10:32.74

OracleJDKはいやだ
サード󾮕パーティーもいやだ
OpenJDKを追いかけるのもいやだ

理想の世界はなんなの？

**デフォルトの名無しさん** · 2018/11/11(日) 00:17:44.59

俺が今作ってるからもう少し待て

**デフォルトの名無しさん** · 2018/11/11(日) 01:15:02.61

>>777
Javaなんて無かったことにする

**デフォルトの名無しさん** · 2018/11/11(日) 01:22:36.16

Java以外に行っても解決しないだろ
例えばC#に行ったら、次はMSに振り回されるだけだ

**デフォルトの名無しさん** · 2018/11/11(日) 03:10:44.83

C#は標準化してるからMSに振り回されることはないだろ
トランプやEUがケチつけてくるとかはあるかもしれないが

**デフォルトの名無しさん** · 2018/11/11(日) 08:09:41.71

今からJavaで開発なんて、無謀すぎる。

**デフォルトの名無しさん** · 2018/11/11(日) 08:23:31.19

>>781
Javaの方がずっと古くから標準化されていると思うんだけど。

**デフォルトの名無しさん** · 2018/11/11(日) 09:02:59.51

標準化ってISOでの標準化でしょ。
JavaはSunやOracleが権利振りかざして管理してただけで。
C#はMS以外からコンパイラでても訴えられる事はない。
(ただし、MonoみたいにMSに買収されることはあり得るが)

**デフォルトの名無しさん** · 2018/11/11(日) 09:23:25.96

何にせよ
Javaの旬は終わった
と言う事

**デフォルトの名無しさん** · 2018/11/11(日) 15:29:06.31

古くから標準化されてるからって、それがなんなの？
それをいったらCOBOLはそれのずっと前から標準化されてるって話になるけど

**デフォルトの名無しさん** · 2018/11/11(日) 16:04:16.37

つまり変な仕変にや環境ごとの仕様の違いに振り回されることはない
C#みたいに誰かの思惑でいいように内容を変えられたりしにくいってこった

COBOLがだめなのは別の理由

**デフォルトの名無しさん** · 2018/11/11(日) 16:54:14.37

MS系はやっぱり振り回される可能性高いと思うよ
何だったかWindowsストアと連携した機能とかあった気がする

あとC#アプリ作ったとして、WindowsとLinux(Mono)で起動方法が違ってくるはず、昔調べた結果によると
確かWindows限定で動作する起動コードが同梱されるんだったか
Windowsだとダブルクリックだけで起動できるけど、
Linuxだと.exeとMonoを関連付けないといけない
でも.exeはC#限定拡張子ではない
.jarはJavaを意味する拡張子だからJREと関連付けるのは妥当なんだけど

**デフォルトの名無しさん** · 2018/11/11(日) 17:16:01.70

>>786
だから今でも生き残ってるし、Javaが死んでもCOBOLは安泰。

>>788
環境毎の違いをあげつらって、振り回されるとか言われてもなあ。

**デフォルトの名無しさん** · 2018/11/11(日) 17:18:47.03

そうじゃなくて、俺が言ってるのは、
MSが自社製品を優遇するような仕様を入れるのは珍しい事じゃないということ

**デフォルトの名無しさん** · 2018/11/11(日) 17:24:16.88

http://www.atmarkit.co.jp/fdotnet/special/mono10_01/mono10_01_04.html
＞「え！ Linuxなのに拡張子が“.exe”なの！」と思う読者もいると思うが、そのとおりである。

.exeは”MS系OSの実行可能ファイル拡張子”で、クロスプラットフォームな拡張子じゃない。
まずこの時点で自社製品優遇の仕様が入れられてる。

**デフォルトの名無しさん** · 2018/11/11(日) 17:25:58.64

>>788
Linux用のバイナリ起動はよくは知らないんだけど、例えそうだとしたらexeからmonoとかに拡張子変えればいいだけじゃないのん？
後、細かいことだけどMonoはC#環境じゃなくて.NET互換環境じゃないのん？

**デフォルトの名無しさん** · 2018/11/11(日) 17:28:01.73

それ言ったら言語とかの基礎的な仕様の意味が無いでしょ
「これしかできない」とか「これが標準的なやり方」っていうのを定めて、
それ以外を想定しなくていいことがメリットなんだから。

あとC#と.NETは適当に読み替えてくれ

**デフォルトの名無しさん** · 2018/11/11(日) 17:29:43.27

>>787
日本語

**デフォルトの名無しさん** · 2018/11/11(日) 17:32:33.83

仕様には入ってないだろ

Microsoft.*名前空間にいろんなパッケージを作って配布はしてるのは事実だけど
それは他のサードパーティ製パッケージやオープンソースパッケージを使うのと同じことだよね

**デフォルトの名無しさん** · 2018/11/11(日) 17:35:14.26

それは仕様という言葉を極端に狭くとらえてる。
お前は今仕様という言葉を”言語仕様”に限定したんだろ？

標準的な実行可能ファイルがexeである時点で、MS製品への誘導を行っていて、
クロスプラットフォームを純粋に追及できていない。

**デフォルトの名無しさん** · 2018/11/11(日) 17:35:37.20

>>791
そもそもMonoはオープンソースで拡張子を決めたのはMicrosoftじゃないだろ
exeはMicrosoft優遇とかいう理論も全くもって意味不明
格安はファイル名の延長でしかなくファイル名を解釈するプロセス側の問題

**デフォルトの名無しさん** · 2018/11/11(日) 17:36:18.39

>>793
喧嘩売るつもりは全くないんだけど、Linux環境では「exeはMono用のIL」ってルールで運用しちゃダメなのん？
気持ちいいか悪いかだけの問題な気がする。

**デフォルトの名無しさん** · 2018/11/11(日) 17:40:09.07

Monoだけじゃなく当然Visual Studioとかで実行可能ファイルを作成してもexeだ
その状況が何らかの標準化された仕様によるのか慣習なのかは知らないが、
クロスプラットフォーム的ではない。

>>798
もしexeに.NETと無関係な他のプログラムが関連付けられていたら？
jarにjreを関連付けるのはそういう問題が無い

**デフォルトの名無しさん** · 2018/11/11(日) 17:42:05.86

＞ファイル名の延長でしかなくファイル名を解釈するプロセス側の問題

そうじゃない。世界のソフトウェア開発全般のエコシステムの問題で、
exeを.NET限定拡張子であるかのように扱う事ができないんだけど、
それを要求されてしまってるんだよ。

**デフォルトの名無しさん** · 2018/11/11(日) 17:43:31.86

>>799
実際にLinuxでデファクトスタンダードにexe拡張子が何かに割り当てられてるんだっけ？
もし「仮に割り当てられたら」という話ならjarだって同じ話になるんじゃないのん？

**デフォルトの名無しさん** · 2018/11/11(日) 17:44:18.59

>>787
COBOLは金勘定特化言語ゆえ無くならない
コンセプト勝ち
Javaは開発も実行も無料で、どこでも動く、だったのが
実行したければ金払え、になったから

**デフォルトの名無しさん** · 2018/11/11(日) 17:45:22.68

>>799はWindows環境で.NET FrameworkでVSで実行可能ファイルを作成しても、という意味

**デフォルトの名無しさん** · 2018/11/11(日) 17:46:15.61

>>800
ああ、ようやく貴方の言いたいことがわかった。
「Windowsでexeが実行ファイルの拡張子である限り、LinuxでのexeはMonoの拡張子じゃ許されない」ってこと？

**デフォルトの名無しさん** · 2018/11/11(日) 17:48:27.17

>>801
>>788

”意味が違う”。現時点で実際に関連付けられているかじゃなく、
今後exeに.NETと無関係なプログラムを関連付ける事が行われても不思議じゃないということ。
jarにjavaともjvmとも無関係なプログラムを関連づけるなら、それは関連付けたやつが間違い。

jar = java archive
https://ja.wikipedia.org/wiki/JAR_(%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88)
＞JAR（ジャー）またはJava Archive（ジャバアーカイブ）とは、コンパイルされた複数のJavaバイトコード及びそれが使用する画像などのリソースを一つにまとめZIP形式で圧縮されたファイル、及びそれを出力するツールのこと。

exe
https://ja.wikipedia.org/wiki/EXE%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88
>EXEフォーマット（エグゼフォーマット）とはMS-DOSおよびその互換・後継環境の実行ファイルフォーマットである。

**デフォルトの名無しさん** · 2018/11/11(日) 17:49:40.25

>>804
「exeがWindows用実行可能ファイル全般の形式として定義されている限り、
Linux環境でMonoとexeを関連付ける事ができない」ということ

**デフォルトの名無しさん** · 2018/11/11(日) 17:51:36.78

>>800
だれもexeを.NET限定拡張子としてないし要求もしてない
アプリケーションがexeという拡張子を見てどう解釈するか？
それを決めるのはアプリケーションの開発者の自由

**デフォルトの名無しさん** · 2018/11/11(日) 17:51:55.92

>>806
.NET Core知らないおばかさんかな？

**デフォルトの名無しさん** · 2018/11/11(日) 17:52:34.23

>>806
Linux環境でMonoとexeが関連付けできないと言い切るのは少し違和感があるけど、Monoはオープンソースなんだしコミュニティに要望出してみたらどうだい？

**デフォルトの名無しさん** · 2018/11/11(日) 17:53:34.24

>>806
関連付けできるよ
お前は何が言いたいんだ？

**デフォルトの名無しさん** · 2018/11/11(日) 17:54:48.12

>>807
Windowsと同じ起動方法を取らせるにはlinux環境でmonoを.exeと関連付ける必要があるから。
>>798もLinux環境でexeをmono専用にしようというアイデアを持ってしまってる。

>>808
それでどんな事情が変わるのかを教えてくれ

**デフォルトの名無しさん** · 2018/11/11(日) 17:55:46.69

JVMJ9CL002I　クラスは、非 J9 ライブラリーか、誤って縮小された JXE からのものです
説明　クラス・ライブラリーの .jar ファイルは、この仮想マシンと互換性がありません。
システムの処置　JVM は開始できません。
ユーザーの処置　クラス・ライブラリーを JVM と互換性があるようにしてください。

JVMJ9CL003E　互換性のないクラス・ライブラリー・バージョン: JCL %1$x、VM %2$x
説明　クラス・ライブラリーが、JVM と同じリリースからのものではありません。
システムの処置　JVM は開始できません。
ユーザーの処置　JVM とクラス・ライブラリーが同じリリースからのものになるようにしてください

JVMJ9CL005E　互換性のないクラス・ライブラリー・バージョン: VM v%1$i が必要ですが、v%2$i が見つかりました
説明　クラス・ライブラリーが、JVM と同じリリースからのものではありません。
システムの処置　JVM は開始できません。
ユーザーの処置　JVM とクラス・ライブラリーが同じリリースからのものになるようにしてください。

**デフォルトの名無しさん** · 2018/11/11(日) 17:56:16.02

>>810 >>800
例えばLinux向けデスクトップアプリを配布するにあたって
monoとexeを関連付けるように呼び掛ける事はできない。
世界のソフトウェア開発のエコサイクルのため、できない。意味が違うから。
コンピューターがチューリング完全であるという意味から可能というのは、違う。

**デフォルトの名無しさん** · 2018/11/11(日) 17:57:44.79

Javaはｳﾝｺ
（証明終）

**デフォルトの名無しさん** · 2018/11/11(日) 17:58:54.93

jarとかclassﾌｧｲﾙをzip化しただけのｸｿのくせに
なにいきってんの

**デフォルトの名無しさん** · 2018/11/11(日) 17:58:56.33

>>813
起動スクリプトでもなんでも書けばいいだろがい
お前の言い分が通るならjarをjavaの拡張子としてシステムに登録することを個々のユーザーに強いることはできないからjarもアウトだぞ？

**デフォルトの名無しさん** · 2018/11/11(日) 18:00:40.39

複数のvmをｲﾝｽﾄｰﾙして動作させてる環境では
複数のjarﾌｧｲﾙがあった場合
どのvmで動作させるのが適切か判別すらできない

**デフォルトの名無しさん** · 2018/11/11(日) 18:01:27.31

>>816
＞jarをjavaの拡張子としてシステムに登録することを個々のユーザーに強いることはできない
できる。jarはjava専用拡張子だから。

起動スクリプトを書いたとして、linuxユーザーは起動スクリプトを使う、
windowsユーザーはexeを直接使うといった事を指示しなきゃいけない。
クロスプラットフォーム的じゃない。

**デフォルトの名無しさん** · 2018/11/11(日) 18:04:29.53

うん、さすがに論理展開が強引になってきちゃったな。
早い話がLinuxとWundowsで少しでも起動方法が違うのが許せない、真のマルチプラットフォームとは言えないって事だよね。
OSが違うんだし、そのぐらいは許容してよ。

**デフォルトの名無しさん** · 2018/11/11(日) 18:05:56.28

>>819
俺の主張が変化したかのように印象操作をするのをやめてくれ。
俺の主張は少しも変化していない。

>>788
>WindowsとLinux(Mono)で起動方法が違ってくるはず、

**デフォルトの名無しさん** · 2018/11/11(日) 18:06:55.45

JVMJ9CL000E 非互換クラス・ライブラリー
説明　クラス・ライブラリーの .jar ファイルはクラス・ライブラリーのネイティブ・コードと互換性がありません。
システムの処置　JVM は開始できません。
ユーザーの処置　vm.jar ファイルが JVM と同じバージョンになるようにしてください

JVMJ9CL001I -jcl:%s を指定して実行してください
説明　クラス・ライブラリーの .jar ファイルは、クラス・ライブラリーのネイティブ・コードおよび JVM と互換性がありません。
システムの処置　JVM は開始できません。
ユーザーの処置　クラス・ライブラリーのネイティブ・コードおよび JVM を、指定されたクラス・ライブラリーの .jar ファイルと互換性があるようにしてください。

そもそもjavaがﾈｲﾃｨﾌﾞｺｰﾄﾞ埋め込むのを許容してる
もともとｸﾗｽﾌﾟﾗｯﾄﾎｰﾑである保証なんかどこにもない

**デフォルトの名無しさん** · 2018/11/11(日) 18:07:08.79

javaはコマンドからしか使わないから
jarをダブルクリックしたらzip解凍してほしいと考える特殊なユーザーだっている(俺のことな)
なので俺は関連付けでそうなるようにしてる
拡張子は「使う側がどうしたいか？」それだけなんだよ

monoユーザーは大部分の人がexeでいいと納得してる
でもお前みたいなexeは嫌だと考える人が居てもいいんだ
嫌なら関連付けの設定を変えるだけでいい
それは誰も禁止なんてしてない

**デフォルトの名無しさん** · 2018/11/11(日) 18:09:00.36

>>821
＞クラス・ライブラリーのネイティブ・コード
これはJVMの標準ライブラリのネイティブコードであって、
アプリ側のネイティブコードを指してるわけじゃないと思う。