Java有償化まとめ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2018/07/23(月) 15:03:10.26ID:JAUjD514
よく分からんのでまとめて下さい。
会社のローカル開発環境はお金払うの？
JavaRuntimeとかあったような…
諸々よろしく。
0753デフォルトの名無しさん
垢版 |
2018/11/07(水) 21:30:55.74ID:h4FWJh3K
MSの良い？所は(開発環境を作った)コードに対してしか課金しない。
(最近はApple真似て開発環境無料で年会費取るけど)

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

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

個人でも最適化欲しさにProは買ってた。
0755デフォルトの名無しさん
垢版 |
2018/11/07(水) 21:34:24.80ID:h4FWJh3K
デスクトップや小規模なwebアプリには今はいい時代になったと思うけど、モバイル向けの環境は学習にはやや不便。
0756デフォルトの名無しさん
垢版 |
2018/11/09(金) 02:47:06.75ID:TZ8SOU7V
あるtwitterより

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

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

今後Oracleが何するか読めないのも面倒くさいし、どうしても必要な場合を除き弊社ではJavaでの開発はやめました。
0757デフォルトの名無しさん
垢版 |
2018/11/09(金) 06:30:24.87ID:/ZPieRkK
>>756
言語そのものしか使っていないならその通りだが、それ以外のツールなどを使って
エコシステムにどっぷり漬かっていると、そうできないからみんなこんなに騒いでいる。
0758デフォルトの名無しさん
垢版 |
2018/11/09(金) 08:17:18.34ID:Eqr6+fNZ
今後の新規開発にJavaを一切使わないのは現在Javaにべったり依存している組織においても技術的にはそれほど難しいことではない
問題は、>>757の「それ以外のツール」ってのがSIerにとってはJavaドカの工数と事実上ほぼ同義であることで、この状況を覆すのは容易ではない
そもそもJava自体が何よりも "Learn Once, Work Everywhere" の性質を背景にして普及してきたプラットフォームであるわけで、
他の言語と比べても人的リソースに特に強く左右される言語であることはいうまでもないだろう
0760デフォルトの名無しさん
垢版 |
2018/11/09(金) 14:58:51.56ID:/QitoG9m
>>693
Androidのアプリ開発してるところは、Android 6.x以前の端末に対してアプリ提供を
続けていくつもりなのかな？
Android 6.x以前の端末に対しては、そもそもGoogleがOSサイドでOpenJDK対応して
ないから色々難しい面があるのではないかと思うけど
0762デフォルトの名無しさん
垢版 |
2018/11/09(金) 22:58:22.21ID:zMMfYdX4
古いバージョンのJVMを使っていても強制的に金払わないといけないんですか？
0763デフォルトの名無しさん
垢版 |
2018/11/09(金) 23:13:39.87ID:zMMfYdX4
Java8があと数年更新されるから
Java8を使って置いて、サポートが切れた＆Java8で脆弱性が見つかったら
OpenJDKの最新版に乗り換える、とかで良いのかな？
0764デフォルトの名無しさん
垢版 |
2018/11/10(土) 00:45:41.82ID:nBJ6AH5S
>>763
Java8の無償サポートって、期限来年の１月末までなんですが....
もう残り3ヶ月切ってるよ
個人のPCでネット接続しないスタンドアローンのものならば構わないけど、
そうじゃない限りサポート無しっていう訳にはいかないだろ
金払いたくないけどJava使いたいならOpenJDKぐらいかな選択肢は
0765デフォルトの名無しさん
垢版 |
2018/11/10(土) 00:46:54.88ID:XE+BpAI8
OpenJDKの開発環境のセットアップとか
アプリへの同梱作業は難しかったりするの？
0766デフォルトの名無しさん
垢版 |
2018/11/10(土) 00:49:46.77ID:XE+BpAI8
OpenJDKもLTSが無いとかでAdoptOpenJDKが最有力に思える
でも信頼性が無い・・・
0768デフォルトの名無しさん
垢版 |
2018/11/10(土) 01:06:50.31ID:6+49N6C+
>>254
バトルフィールド５の初日パッチで修正される不具合
135ページに渡るらしいぞ。
開発間に合わなかったのかね
0769デフォルトの名無しさん
垢版 |
2018/11/10(土) 01:16:17.70ID:XE+BpAI8
Java8+JavaFXでやってるけど
AdoptOpenJDK 11に乗り換えるか・・・
Eclipseもアプリ側も変更になる
どれくらい大変なんだろうか
0772デフォルトの名無しさん
垢版 |
2018/11/10(土) 02:09:29.48ID:XE+BpAI8
ありがとう。とりあえず11で試みて、ダメそうだったら8でビルドしてみる
0774デフォルトの名無しさん
垢版 |
2018/11/10(土) 15:53:21.95ID:XE+BpAI8
・AdoptOpenJDKのLTSは、オラクルのサポートが打ち切られた後にバグが見つかったら、
独自修正するんだろうか？
・その場合、その修正はオラクルの特許に絡まないんだろうか？
・絡んだ場合、AdoptOpenJDKの再配布はリスクだろうか？
0775デフォルトの名無しさん
垢版 |
2018/11/10(土) 20:24:22.62ID:nQarlXc8
あらゆるソフトウェアが数多ある特許の何れかを侵害してしまうリスクを抱えているのでは
0776デフォルトの名無しさん
垢版 |
2018/11/10(土) 22:23:41.41ID:KkzjltfE
>>774
結局Javaそのものがリスクになるんだよ。
Oracle以外がそうならないように頑張っているのは周知のとおりだけど、
Oracleが自分のところ以外のLTSを潰しにかかって言いがかりをつけ始めたら
泥沼化は避けられない。
そこまで馬鹿ではないだろうとか勝ち目はないだろうとか、そうならない
だろう材料は当然あるけど、どんな馬鹿が台頭するかもわからないわけで。

それを、ある日インターネットが世界的に禁止されたら、と同じ程度の
リスクと考えるか、ガソリンがレギュラー160円になるくらいのリスクと
考えるかはあなた次第。それをうまく立ち回れるのが求められている事。
0777デフォルトの名無しさん
垢版 |
2018/11/10(土) 23:10:32.74ID:IfXeU3kb
OracleJDKはいやだ
サード󾮕パーティーもいやだ
OpenJDKを追いかけるのもいやだ

理想の世界はなんなの？
0778デフォルトの名無しさん
垢版 |
2018/11/11(日) 00:17:44.59ID:Sc7c1qwR
俺が今作ってるからもう少し待て
0780デフォルトの名無しさん
垢版 |
2018/11/11(日) 01:22:36.16ID:Sc7c1qwR
Java以外に行っても解決しないだろ
例えばC#に行ったら、次はMSに振り回されるだけだ
0781デフォルトの名無しさん
垢版 |
2018/11/11(日) 03:10:44.83ID:4b5Szb0b
C#は標準化してるからMSに振り回されることはないだろ
トランプやEUがケチつけてくるとかはあるかもしれないが
0782デフォルトの名無しさん
垢版 |
2018/11/11(日) 08:09:41.71ID:ZG9KPLpE
今からJavaで開発なんて、無謀すぎる。
0784デフォルトの名無しさん
垢版 |
2018/11/11(日) 09:02:59.51ID:B3f/927d
標準化ってISOでの標準化でしょ。
JavaはSunやOracleが権利振りかざして管理してただけで。
C#はMS以外からコンパイラでても訴えられる事はない。
(ただし、MonoみたいにMSに買収されることはあり得るが)
0786デフォルトの名無しさん
垢版 |
2018/11/11(日) 15:29:06.31ID:Q27An75F
古くから標準化されてるからって、それがなんなの？
それをいったらCOBOLはそれのずっと前から標準化されてるって話になるけど
0787デフォルトの名無しさん
垢版 |
2018/11/11(日) 16:04:16.37ID:jnAEWA8A
つまり変な仕変にや環境ごとの仕様の違いに振り回されることはない
C#みたいに誰かの思惑でいいように内容を変えられたりしにくいってこった

COBOLがだめなのは別の理由
0788デフォルトの名無しさん
垢版 |
2018/11/11(日) 16:54:14.37ID:Sc7c1qwR
MS系はやっぱり振り回される可能性高いと思うよ
何だったかWindowsストアと連携した機能とかあった気がする

あとC#アプリ作ったとして、WindowsとLinux(Mono)で起動方法が違ってくるはず、昔調べた結果によると
確かWindows限定で動作する起動コードが同梱されるんだったか
Windowsだとダブルクリックだけで起動できるけど、
Linuxだと.exeとMonoを関連付けないといけない
でも.exeはC#限定拡張子ではない
.jarはJavaを意味する拡張子だからJREと関連付けるのは妥当なんだけど
0789デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:16:01.70ID:4b5Szb0b
>>786
だから今でも生き残ってるし、Javaが死んでもCOBOLは安泰。

>>788
環境毎の違いをあげつらって、振り回されるとか言われてもなあ。
0790デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:18:47.03ID:Sc7c1qwR
そうじゃなくて、俺が言ってるのは、
MSが自社製品を優遇するような仕様を入れるのは珍しい事じゃないということ
0791デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:24:16.88ID:Sc7c1qwR
http://www.atmarkit.co.jp/fdotnet/special/mono10_01/mono10_01_04.html
＞「え！ Linuxなのに拡張子が“.exe”なの！」と思う読者もいると思うが、そのとおりである。

.exeは”MS系OSの実行可能ファイル拡張子”で、クロスプラットフォームな拡張子じゃない。
まずこの時点で自社製品優遇の仕様が入れられてる。
0792デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:25:58.64ID:zAxEw/s4
>>788
Linux用のバイナリ起動はよくは知らないんだけど、例えそうだとしたらexeからmonoとかに拡張子変えればいいだけじゃないのん？
後、細かいことだけどMonoはC#環境じゃなくて.NET互換環境じゃないのん？
0793デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:28:01.73ID:Sc7c1qwR
それ言ったら言語とかの基礎的な仕様の意味が無いでしょ
「これしかできない」とか「これが標準的なやり方」っていうのを定めて、
それ以外を想定しなくていいことがメリットなんだから。

あとC#と.NETは適当に読み替えてくれ
0795デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:32:33.83ID:zL+4Qkmb
仕様には入ってないだろ

Microsoft.*名前空間にいろんなパッケージを作って配布はしてるのは事実だけど
それは他のサードパーティ製パッケージやオープンソースパッケージを使うのと同じことだよね
0796デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:35:14.26ID:Sc7c1qwR
それは仕様という言葉を極端に狭くとらえてる。
お前は今仕様という言葉を”言語仕様”に限定したんだろ？

標準的な実行可能ファイルがexeである時点で、MS製品への誘導を行っていて、
クロスプラットフォームを純粋に追及できていない。
0797デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:35:37.20ID:zL+4Qkmb
>>791
そもそもMonoはオープンソースで拡張子を決めたのはMicrosoftじゃないだろ
exeはMicrosoft優遇とかいう理論も全くもって意味不明
格安はファイル名の延長でしかなくファイル名を解釈するプロセス側の問題
0798デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:36:18.39ID:zAxEw/s4
>>793
喧嘩売るつもりは全くないんだけど、Linux環境では「exeはMono用のIL」ってルールで運用しちゃダメなのん？
気持ちいいか悪いかだけの問題な気がする。
0799デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:40:09.07ID:Sc7c1qwR
Monoだけじゃなく当然Visual Studioとかで実行可能ファイルを作成してもexeだ
その状況が何らかの標準化された仕様によるのか慣習なのかは知らないが、
クロスプラットフォーム的ではない。

>>798
もしexeに.NETと無関係な他のプログラムが関連付けられていたら？
jarにjreを関連付けるのはそういう問題が無い
0800デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:42:05.86ID:Sc7c1qwR
＞ファイル名の延長でしかなくファイル名を解釈するプロセス側の問題

そうじゃない。世界のソフトウェア開発全般のエコシステムの問題で、
exeを.NET限定拡張子であるかのように扱う事ができないんだけど、
それを要求されてしまってるんだよ。
0801デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:43:31.86ID:zAxEw/s4
>>799
実際にLinuxでデファクトスタンダードにexe拡張子が何かに割り当てられてるんだっけ？
もし「仮に割り当てられたら」という話ならjarだって同じ話になるんじゃないのん？
0802デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:44:18.59ID:SJp8Yfn9
>>787
COBOLは金勘定特化言語ゆえ無くならない
コンセプト勝ち
Javaは開発も実行も無料で、どこでも動く、だったのが
実行したければ金払え、になったから
0803デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:45:22.68ID:Sc7c1qwR
>>799はWindows環境で.NET FrameworkでVSで実行可能ファイルを作成しても、という意味
0804デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:46:15.61ID:zAxEw/s4
>>800
ああ、ようやく貴方の言いたいことがわかった。
「Windowsでexeが実行ファイルの拡張子である限り、LinuxでのexeはMonoの拡張子じゃ許されない」ってこと？
0805デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:48:27.17ID:Sc7c1qwR
>>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およびその互換・後継環境の実行ファイルフォーマットである。
0806デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:49:40.25ID:Sc7c1qwR
>>804
「exeがWindows用実行可能ファイル全般の形式として定義されている限り、
Linux環境でMonoとexeを関連付ける事ができない」ということ
0807デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:51:36.78ID:zL+4Qkmb
>>800
だれもexeを.NET限定拡張子としてないし要求もしてない
アプリケーションがexeという拡張子を見てどう解釈するか？
それを決めるのはアプリケーションの開発者の自由
0809デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:52:34.23ID:zAxEw/s4
>>806
Linux環境でMonoとexeが関連付けできないと言い切るのは少し違和感があるけど、Monoはオープンソースなんだしコミュニティに要望出してみたらどうだい？
0811デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:54:48.12ID:Sc7c1qwR
>>807
Windowsと同じ起動方法を取らせるにはlinux環境でmonoを.exeと関連付ける必要があるから。
>>798もLinux環境でexeをmono専用にしようというアイデアを持ってしまってる。

>>808
それでどんな事情が変わるのかを教えてくれ
0812デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:55:46.69ID:KBFxC5Cm
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 とクラス・ライブラリーが同じリリースからのものになるようにしてください。
0813デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:56:16.02ID:Sc7c1qwR
>>810 >>800
例えばLinux向けデスクトップアプリを配布するにあたって
monoとexeを関連付けるように呼び掛ける事はできない。
世界のソフトウェア開発のエコサイクルのため、できない。意味が違うから。
コンピューターがチューリング完全であるという意味から可能というのは、違う。
0814デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:57:44.79ID:KBFxC5Cm
Javaはｳﾝｺ
（証明終）
0815デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:58:54.93ID:KBFxC5Cm
jarとかclassﾌｧｲﾙをzip化しただけのｸｿのくせに
なにいきってんの
0816デフォルトの名無しさん
垢版 |
2018/11/11(日) 17:58:56.33ID:zL+4Qkmb
>>813
起動スクリプトでもなんでも書けばいいだろがい
お前の言い分が通るならjarをjavaの拡張子としてシステムに登録することを個々のユーザーに強いることはできないからjarもアウトだぞ？
0817デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:00:40.39ID:KBFxC5Cm
複数のvmをｲﾝｽﾄｰﾙして動作させてる環境では
複数のjarﾌｧｲﾙがあった場合
どのvmで動作させるのが適切か判別すらできない
0818デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:01:27.31ID:Sc7c1qwR
>>816
＞jarをjavaの拡張子としてシステムに登録することを個々のユーザーに強いることはできない
できる。jarはjava専用拡張子だから。

起動スクリプトを書いたとして、linuxユーザーは起動スクリプトを使う、
windowsユーザーはexeを直接使うといった事を指示しなきゃいけない。
クロスプラットフォーム的じゃない。
0819デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:04:29.53ID:zAxEw/s4
うん、さすがに論理展開が強引になってきちゃったな。
早い話がLinuxとWundowsで少しでも起動方法が違うのが許せない、真のマルチプラットフォームとは言えないって事だよね。
OSが違うんだし、そのぐらいは許容してよ。
0820デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:05:56.28ID:Sc7c1qwR
>>819
俺の主張が変化したかのように印象操作をするのをやめてくれ。
俺の主張は少しも変化していない。

>>788
>WindowsとLinux(Mono)で起動方法が違ってくるはず、
0821デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:06:55.45ID:KBFxC5Cm
JVMJ9CL000E 非互換クラス・ライブラリー
説明　クラス・ライブラリーの .jar ファイルはクラス・ライブラリーのネイティブ・コードと互換性がありません。
システムの処置　JVM は開始できません。
ユーザーの処置　vm.jar ファイルが JVM と同じバージョンになるようにしてください

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

そもそもjavaがﾈｲﾃｨﾌﾞｺｰﾄﾞ埋め込むのを許容してる
もともとｸﾗｽﾌﾟﾗｯﾄﾎｰﾑである保証なんかどこにもない
0822デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:07:08.79ID:zL+4Qkmb
javaはコマンドからしか使わないから
jarをダブルクリックしたらzip解凍してほしいと考える特殊なユーザーだっている(俺のことな)
なので俺は関連付けでそうなるようにしてる
拡張子は「使う側がどうしたいか？」それだけなんだよ

monoユーザーは大部分の人がexeでいいと納得してる
でもお前みたいなexeは嫌だと考える人が居てもいいんだ
嫌なら関連付けの設定を変えるだけでいい
それは誰も禁止なんてしてない
0823デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:09:00.36ID:Sc7c1qwR
>>821
＞クラス・ライブラリーのネイティブ・コード
これはJVMの標準ライブラリのネイティブコードであって、
アプリ側のネイティブコードを指してるわけじゃないと思う。
0824デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:09:02.35ID:KBFxC5Cm
関連付けても
利用者の計算機で実行できる保証なんかどこにもない

javaのﾊﾞｲﾄｺｰﾄﾞだけであっても動作する保証がどこにもない
そんな関連付けられるほうが迷惑
0825デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:10:58.16ID:zL+4Qkmb
>>818
java専用じゃない
俺は解凍に割り当ててる
それは法律も認める俺の自由だ

違いが気になるならWindowsの方も起動スクリプトを書けばいいだろがい
0826デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:11:55.31ID:zAxEw/s4
>>820
ごめんな、やっぱり何を主張したいか俺にはよく分からない。
LinuxでexeをMonoと関連付けできないという主張なのは分かるんだけど、その理由がさっぱり分からない。
0827デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:12:20.33ID:Sc7c1qwR
>>822
jarに解凍プログラムを関連付けるという行為は個人的な特殊な対応だから、
何が標準的に期待できるかということに影響しない。

＞monoユーザーは大部分の人がexeでいいと納得してる
"monoユーザーは"そうだったとしても、
.NET以外に.exeにプログラムを関連付ける事を推奨しようとするプロジェクトが出現してもおかしくないんだよ。
そしたらそのプロジェクトのユーザーはそのプロジェクトのプログラムを
.exeに関連付ける事に納得しているかもしれないね。
0828デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:13:49.28ID:Sc7c1qwR
>>825
それは世界的に流通してる定義を無視した個人的な対応だから、
世界のソフトウェアエコシステムにおいて意味を持つ主張じゃない。
0829デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:14:32.22ID:KBFxC5Cm
つまりjavaなんかつかってんのは
池沼しかいない
0830デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:15:52.56ID:4b5Szb0b
>>818
Javaってパス区切りは統一されてるんだっけ？
されてなければクロスプラットフォーム的じゃないはJavaにも当てはまるよ。
されてるというのなら、されてる方を優遇しているだけで、あんたがexeを叩いてるのと同じことだ。
0831デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:16:40.78ID:Sc7c1qwR
>>825
>java専用じゃない
これが間違い。
jar=java archiveで、”java専用拡張子であることが定義されている”。
その定義を無視した個人的対応が存在する事はjarがjava専用拡張子であるという主張を否定しうるものではない。
0832デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:19:30.68ID:zL+4Qkmb
>>827
monoの知名度は十分
新しい拡張子を広めようとするようなコミュニティがexeに関連する著名なアプリケーションを知らない&調べないなどということはまずありえないだろう
だから気にしなくていい
0833デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:24:27.80ID:zAxEw/s4
>>831
jar拡張子ってISOやIEEEやRFCみたいな公的機関や事実上それに準ずる機関が決めてるんだっけ？
もしjarがそういう機関で決まってるならあなたの主張はその通り。
0834デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:25:02.24ID:Sc7c1qwR
>>832
定義や標準化された仕様ではなく勢力によって守られているという事になるし、
その拡張子の競合問題は、もし.NET系言語が流行った場合、
LinuxではなくWindowsを使おうという誘因になってしまう。
0835デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:28:46.70ID:zL+4Qkmb
>>834
ITの歴史を見ればスタンダードを無視して広く使われているものが事実上のスタンダードになった事例はいくつもある
デファクトスタンダードというのだけど知らなかった？新人かな？

拡張子の競合がどうなればWindowsを使おうになるんだ？
後半は何いってるかまったく意味不明だね
0836デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:32:41.80ID:Sc7c1qwR
>>835
exeの意味のデファクトは既にあって、「MS系OSの実行可能形式」なの。
そのデファクトに挑むように（Linux環境でだけ）.NET専用拡張子だという勢力が出現してるということ。
それはLinuxの拡張子と処理系の関連付けを荒らすような行為だ。
0837デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:36:31.03ID:zL+4Qkmb
>>836
ちがーう
exeのデファクトは「Windowsでは実行可能形式。Unix系ではmono」
拡張子が異なるプラットフォームで同じ意味を持たなければならないという決まりはない
それは解釈する側の問題だからだ
0838デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:37:21.30ID:Sc7c1qwR
>>837
＞拡張子が異なるプラットフォームで同じ意味を持たなければならないという決まりはない
これが間違い。
bmp,jpg,gif,いずれもプラットフォームを超えて同じ意味を持ってる。
その解釈がデファクト。
0840デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:39:17.30ID:Sc7c1qwR
拡張子全般を見渡して、プラットフォームによって意味が変わるような定義は見たことが無い。
.html .jpg .bmp .gif .zip .mp3 .mp4　どれでもプラットフォーム非依存な定義されてる。

拡張子一覧
http://www.tohoho-web.com/wwwxx061.htm
ここ見て全部確認してみよう。どこにプラットフォームによって意味が変わる拡張子がある？
0841デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:40:03.28ID:Sc7c1qwR
＞拡張子が異なるプラットフォームで同じ意味を持たなければならないという決まりはない
この主張はいきなり終わりか？
0842デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:41:34.00ID:Sc7c1qwR
だからC#はLinuxの環境破壊だけでなく
”拡張子がプラットフォーム非依存で同じ意味を持つという想定”
をも破壊しにかかってるということになる。
0843デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:41:51.80ID:3EVRCt7d
そろそろスレ違うだと思うんだが、、、
0845デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:44:30.21ID:zAxEw/s4
まぁ早い話がデファクトな拡張子ルールに従ってないから俺は気持ち悪いぜ！って主張でしかないわな。
確かにスレチなのでもし本気でそう思うならこの続きはMonoコミュニティでやればいいよ。
0848デフォルトの名無しさん
垢版 |
2018/11/11(日) 18:59:42.07ID:B3f/927d
http://ascii.jp/elem/000/001/770/1770229/index-4.html

　.NETは、Windowsに組み込まれている「.NET Framework」とは別に、オープンソースで更新速度の速い「.NET Core」がある。
.NET Coreは、プラットフォームに依存しない.NETの実装で、特定のプラットフォームの事情や細かい互換性を考慮しないため、
新機能がすぐに搭載され、更新の速度も速い。

　現在では、.NET Coreとその標準ライブラリとなる.NET Standardによりデスクトップアプリケーションの開発も可能になっている。
こちらは.NET Frameworkの仕切り直し的な部分があるが、デスクトップアプリケーション側から見れば、アプリケーションモデルの選択が増えた格好になる。

　.NET Core 3.0では、WPFやWinFormがサポートされた。また、複数バージョンの.NET Coreを共存させることも可能になり、
アプリケーションは、特定バージョンの.NET Coreを使い続けることができるようになった。
アプリケーションに.NET Coreを組み込んで出荷することも可能であり、ホストシステム側のバージョンに依存しない実行環境を維持できる。
0849デフォルトの名無しさん
垢版 |
2018/11/11(日) 19:04:42.99ID:Sc7c1qwR
>>845
＞デファクトな拡張子ルールに従ってないから俺は気持ち悪いぜ！
”俺は”じゃなく、世界のソフトウェア開発のエコシステムにとって間違っていると主張している。

.NET coreの話を持ち出しているやつがいるが
exeもdllも.NET専用拡張子ではないのでこの議論の事情を変化させる主張ではない
0850デフォルトの名無しさん
垢版 |
2018/11/11(日) 19:07:01.83ID:zL+4Qkmb
間違ってないから今も問題なく動いてるし
今後は勝手にexeを使おうとするやつはデファクトに反する無法者ということになる
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況