★★Java質問・相談スレッド181★★
■ このスレッドは過去ログ倉庫に格納されています
プログラミング言語Javaに関する質問スレです。 JavaScript, Ajaxの質問は、ここでは受け付けていません。 Web製作管理 http://pc11.2ch.net/hp/ Webプログラミング http://pc11.2ch.net/php/ をご利用下さい。 よくある質問 ・「コマンドまたはファイル名が違います」 「'javac' は、内部コマンドまたは外部コマンド、 操作可能なプログラムまたはバッチ ファイルとして認識されていません。」 「Exception in thread "main" java.lang.NoClassDefFoundError: 」 (p)ttp://www.wikiroom.com/java/?path,classpath ・「\12288 は不正な文字です。」 文字リテラル以外で全角スペースは使えません。半角スペースに。 ・その他の質問→「APIのjavadoc見ろ」 ・String に == は使うな。equals() を使え。※ 質問時の心得 ・コンパイルエラーか実行時エラーか、エラーではないが意図しない動作なのかはっきりしろ。あとエラーメッセージちゃんと読め。 ・前提条件としてOS、開発環境、バージョン、使用フレームワーク等を明記。 前スレ ★★Java質問・相談スレッド180★★ https://mevius.5ch.net/test/read.cgi/tech/1492780397/ ぶっちゃけCUDでも呼び出していい 結局、意味を捉えて間違えないように書けということでしかない コーディング規約をどういじくってもそこから逃げれるわけじゃない if (a == 0 || b++ < 1) { } こういう書き方をすると一見bが常にインクリメントされるように誤解されやすいからやめとけよって言ってるだけでしょ。 真理式に複数の演算があって、かつ一部に副作用があるとまずい、ってことか 副作用・副作用完了点 評価順序・マクロ MISRA-C でも、こういう間違いやすい所の、ルールは厳しい >>785 それならないな。 残るは get() して 1 以下なのを検査した直後に別スレッドによって a の状態が変化して get() が返す値が変わるとかかな。 (そんなの想定の範囲内なら問題ないが)。 adopt openjdkのjdk11リリースされたじゃん。 ttps://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot LTSだぞ。 ttps://adoptopenjdk.net/support.html?variant=openjdk11&jvmVariant=hotspot クライアントJREは廃止された 今現在、要JREとして世に出ているアプリをエンドユーザーが実行する公式な方法は存在しない(自己責任で開発環境を入れるしかない) 今後のクライアントサイドJavaアプリの唯一の配布方法は、JDKに含まれるコマンドラインツールを使用して プラットフォーム毎に実行環境とアプリを同梱した実行可能なパッケージを作ることである クライアントサイドに関しては、もはやJavaはバイナリ互換ではない OracleはクライアントサイドJavaを段階的に廃止しようとしており、新規には決して使ってはならない >>793 当てにならんよこんなの こいつらはただのビルド屋で、自分達でソースに手を入れる体制はない 次のバージョンのOpenJDKがリリースされた後もOpenJDK公式リポジトリの旧バージョンのソースに対してLTS向けのパッチが提供されるかどうかは、 オラクル様の温情次第 Javaに型推論が無いことをディスられると、意識高い系Javaerさん達は ローカル変数の型もinterfaceにするべきだからそんなもん要らんと上から目線で反論してたけど 梯子外されちゃって哀れだな これ2じゃなくて1が出力される。何で? @Test public void mapObjTest() { Map<Long, Integer> m = new HashMap<>(); Long key = 1L; m.put(key, 1); Integer val = m.get(key); val++; System.out.println(m.get(key)); } 悪く言われるけどクライアントサイドについてJRE同梱は良いんじゃない? もはやファイルサイズは小さな問題だし、JREのバージョン違いでの誤作動を減らせる。 クライアントサイドJavaがそれで悪くなったと思わないけどな、俺は JavaFXが外されたのは悪くなったと思うけど、でもどうせ同梱する作業するときに入れるんだし 妥当な変化じゃないの? >>801 val++は↓これと同じ val = val + 1 変数valに値を代入してる ↓こう書けば値は2になる、value.valueはドット演算子を使ってオブジェクトの状態を変えてる public class Main { public static void main(String[] args) { Map<Integer, Value> map = new HashMap<>(); map.put(1, new Value(1)); Value value = map.get(1); value.value++; System.out.println(value.value); } } class Value { int value; Value(int value) { this.value = value; } } 変数に対する代入と オブジェクトの状態を変えることとは 異なる操作なんやで >>801 Integerをインクリメントした瞬間に新しくIntegerインスタンスが生成されるからだな 詳しくはオートボクシング、インクリメントとかでググるといい 要するにval++は↓の省略系 val = new Integer(val.intValue()+1) >>802 悪くはなってないよね 0に何を掛けても0だからな >>802 動的リンクしまくってるからFullJRE前提だわ。 Object#equals() public boolean equals(Object obj) { return (this == obj); } なんでreturn this == obj;じゃなく括弧で囲ってるの? return文に記述された式が複雑なときは括弧で括ったほうがmore readableだから推奨してる人のほうが多いように思うけど、 this == objが複雑かどうかは微妙だね。 でも自分なら括弧つけるかな。 理由は、括弧でくくることで、等式が値を返す数式として使われていることを明示できるから。 Javaの最黎期に書かれたものだろうから、コードスタイルが今の基準からすれば変でもおかしくない 今では一般的には括弧はつけないのが主流だね 計算がよくわからん時は、まず括弧で囲えって、 今でも教える人がいるからな >>815 演算子の優先順位の話なら不要だと思ってもあえてつけたままにすることはあるな + と * とかならいいけどビット演算子とか言語によって違う奴とかもあるしね javaでaccessdbと接続するようなソフト作ってみたいんですが フレームワークって必要ですか ちょっとフレームワーク自体よくわかってないです。 規模は社内で5人くらいで使用します。 検索すれば出てくるけど ハマることが多そうだからオススメしない Javaが要件なのかAccessが要件なのかわからんが >>812 Webで避けて通れないJavaScriptのせいとかもあるな。 JavaScriptのセミコロン省略可能はいまだに嵌る。 Ruby on Rails, Node.js などでは、開発環境では、SQLite を使うけど >>802 Write once,Run anywhere 配布しようと思ったら環境に応じたJRE添付してやらないといけないんだよね? 根本理念に喧嘩売ってる気がする >>822 バイナリ互換じゃなくなるけどソースコード互換ではあるので・・・ JavaでGUIアプリ作ってネットで配布する場合、エンドユーザーの環境に依存するの辛いでしょ むしろJRE同梱したい、と思うのが普通だよ JRE同梱によるファイルサイズ増加はもはや問題にならないし どうせJRE同梱作業するなら、その時にJavaFX入れれば良いので、分離されたのも妥当な気がするし むしろクライアントサイドで進歩してると言っても良いのでは >JavaでGUIアプリ作ってネットで配布する場合、エンドユーザーの環境に依存するの辛いでしょ JRE同梱だと回避できて、JARだけだとダメな問題ってどういうのがあるん? 実際にクライアントの環境が異なってたらどうやって提供しようが辛さは一緒におもえる だいたいJRE同梱なんかされたら何仕込まれてもわからん サンドボックスのしっかりした仕組みがあるわけじゃなし そもそもWindowsとかOS側が信用できない 共通のJavaだから信頼感あったのに 今どき.NETですらランタイム同梱する流れだからな >>824 何言ってるか良く分からんが、JRE同梱すればJREのバージョン違いによる問題が無くなるだろう。 いちいちJREをインストールしてもらう手間も無くなる。 例えば一部のJREはJavaFXを同梱しているが、一部はそうではない。 何仕込まれても、ってのは良く分からんが スタンドアロンアプリでもセキュリティマネージャーは動くはず 確かにこれまでと比べると、オラクルのサイトからJRE落としてそれで動かしてたのに比べると アプリ毎にJRE同梱されちゃうとおかしなネイティブ実行ファイルが同梱されてないか、という問題はある しかし同梱されたプラットフォーム固有の実行ファイルはハッシュ値とかで適切なファイルかを照合できるはず あとそもそもバイトコード部分でも相当な処理が可能だから、さほどセキュリティリスクが変わると思わない ネットからプログラムを落とすなら、オープンソースか信頼できる大御所か これまでと変わらないのでは 問題はJREのバージョンか たしかに多少の問題はあるが JRE同梱必須にしたらJavaの目指していた未来と可能性そのものを切り捨てることになる そうできるってのとそうしなきゃいけないってのはえらい違い JREを同梱しないと、10年経ったら動かなくなってると思う クライアントサイドはJRE同梱で作れと強制する事は、そんな悪い事じゃないと思う そうしないとJavaがバージョンアップしづらい問題もあるから、オラクルはそうしたいんだろう 元々Write once,Test anywhere って失望されてたじゃ無いか。。。 HTML5も同じだけど、理想と現実は遥かに遠い隔たりがある。 スタティックリンクの肥大した実行ファイルと一緒だよね Write Onceで全プラットフォームで動いたら開発者としては理想じゃないかな オラクルはJavaを高速バージョンアップしたいみたいな事も言ってるが、 一連の話は整合性がある サーバーサイドはエンジニアが管理しててJRE固定できる、 クライアントサイドはJRE同梱。 現状だとJavaから古いAPIを削除したら多くのアプリが動かなくなるから、 移行期間を作ってそのようなアプリが減るのを待つ。 そうしないとJavaに未来が無いという判断は、理解できなくない。 じぶんとこのOracleDBは枯れまくってても平気なくせに だから、同梱されたファイルのハッシュ値調べればわかるし、 アンチウイルスだって有名な実行ファイルについてハッシュ値を知識として持っておくべき。 オープンソースは誰かが検証すべき。 で、もともとバイトコード部分でも相当な事ができるからセキュリティリスクは変化してない。 クラス変数にもvar使わせてほしいよな 無名クラスにリフレクションで値を代入するフレームワークとかでてきそうだし class Hoge { public var xyz = new Object() { int x, y, x }; } それをやると型を特定するために延々先を辿らなきゃいけなくなるんだ… Class#forNameで動的リンクするときjlinkとかは依存するクラス検出できないから 結局手動で全部依存関係調べるかfull jre使うかの二択になる。 >>838 互換性が保証できなくなるからやらないだろ。 実行時の型と推論された型は違うから。 というかあれだぞ。 javapackagerなくなったからjava11ではjre同梱したパッケージ作れないし、 なくなったのはpublic jreだけでjreのビルド自体はadopt openjdkがやってるからjre自体はあるぞ。 >>838 コンパイラの仕組み上困難 Javaコンパイラはまず、メンバのシグネチャだけを解析してクラスごとにメンバのお品書きを作る そして、それが一通り終わった後に各メソッド本体やフィールド代入元の式を解析する ところがフィールドの型にvarを許してしまうと、お品書きを作る段階でフィールド代入元の式を解析しなきゃいけなくなる それによりコンパイラのパスが増えてしまうから、コンパイル速度が大きく低下する >>842 クラスにvar持てるHaxeのコンパイル遅いと感じたこと無いけど Scalaとかいう言語でものすごく遅くなったという話は聞く >>841 Java 11でクライアントサイドはどういう扱いになってるの? 新しいパッケージングツールの要件はJavaFX未対応とされている http://openjdk.java.net/jeps/343 JavaFX由来のパッケージングツールが削除された じゃあ、JavaFXアプリをエンドユーザーに配布したい場合、どうするの? 現在見つかる情報は、非JavaFXの自己完結型パッケージャ、 JavaFXのビルド方法だけで、JavaFXの自己完結型パッケージャが行方不明なんだけど >>844 Java Client Roadmap Update ttps://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf >>845 jep343がjavafx対応しないんだからないよ。 でも、javafxはただのライブラリなんだからjep343でほかと同じ扱いでしょ。 public synchronized void method1(){} こういうメソッドレベルでsynchronizedした場合、 synchronized(this){}ということですか? つまり他のところでsynchronized(this)が書かれていたら、どちらかが待機になるんでしょうか >>849 その通り thisをロックするのはパフォーマンスの低下やデッドロックの原因になるため、現代では一般には悪手とされている synchronizedがデフォルトでthisをロックするのはJavaがまだオモチャでカジュアルに排他制御してた時代の名残で、 ちゃんと作るなら排他制御には private メンバを使って外に漏らさないようにした方が安全 thisをロックするのとロック専用オブジェクトをロックするのは 性能の違いがあるんですか? >>851 thisはクラス外からも当然見えているわけで、他のクラスも同じオブジェクトを同時にロックしている可能性がある どえせ内部的に同期してるんなら他のクラスが同時にアクセスしてくることは何の問題もないはずで、これは完全に無駄なブロックだ クラス外から見えるオブジェクトをロックするのはパフォーマンスだけではなくてデッドロックの可能性を高める非常に悪い行為 デッドロックの可能性は分かるんですが、 その性能の劣化というのは、クラス外でたまたまロックに使われていた場合、 待機時間が生じるから、ということですか? 待機時間以外に構造的に複雑なオブジェクトをロックすることでの性能劣化はありえますか? >>853 それはない ロックはオブジェクトヘッダにロック中であることを示す情報を書き込むだけ ロック可能なのは全部ロックしたら苦しんだ黒歴史・・・ 専用オブジェクトでロックしても結局プログラマーが入念にチェックする以外 無い気がするんですが合ってますか? よく言われてるようなロック順序云々では解決しない気がするんですが デッドロックと言えば、サーバをまたいだロックを掛けててデッドロックになった時は原因究明が大変だったなあ。 >>857 外に漏らさなければ入念にチェックする範囲がクラス内だけに留まるだろ 外から見えるオブジェクトならそれを触ってる可能性のある範囲全てをチェックしなきゃいけない >>863 クラスA#method1() method3呼び出し クラスA#method2() クラスB#method3() method2呼び出し この状況でmethod1,3を異なるスレッドが呼び出したらデッドロックになりうるのでは? クラスA,Bがそれぞれ専用のロックオブジェクトを持っていて method1,2,3の内部でロックオブジェクトでロックしているとして そういやJavaVMって実行時にデッドロックを見つけ出す機能はないのかな? OSのファイルロックだと見つけてくれたりするよな。NFS絡むと無理だけど。 (あ、でも2プロセスでロック掛け合った場合だけかな?) デッドロックを通知する仕組みはあるようです。JConsole 安全なsynchronizedというものは、そのメソッドがどこから呼び出されているか、 どれを呼び出しているかというような依存関係で決まって、 単純な記述方法で安全性を確保する事はできないのではと思いました。 どのオブジェクトをロックしてもこの問題は残ります。 https://www.jpcert.or.jp/java-rules/lck07-j.html これなんかもそうですが、ロック順序だけで解決できると考えてしまっていますが、 synchronizedブロック内のロジックが他のメソッドを呼び出している場合、 まだデッドロックが発生する可能性があると思います。 派生していくメソッド呼び出しのどこかにsynchronizedブロックがあれば。 もちろん、多くの場合、プログラムは様々なメソッドを呼び出します。 >>857 はこの理解で正しいかという意味です >>864 のケースで仮にAがthisをロックしていたとしたら、B#method3がA#method2を呼ばずともB#method3内で直接または間接的にAのロックを試みただけでデッドロックするだろう。 privateなロックオブジェクトを用いたからといってデッドロックの可能性はゼロにはならないが、thisを使うのに比べれば確実に可能性は低くなる。 あえてリスクの大きくパフォーマンスの低下する方を選択する積極的な理由がない。 >>866 何を言いたいのか理解できないが、どこの誰がどんなタイミングでロックを取りに来ようとも、ロックの順番さえ守ってれば絶対にデッドロックは起こらないよ。 DB などほとんどのアプリでは、デッドロックでタイムアウトする。 絶対に回避できない ロックする順番は、2プロセスの場合、 プロセスAがX, Y、 プロセスBがY, X 3プロセスの場合、 プロセスAがX, Y、 プロセスBがY, Z、 プロセスCがZ, X >>870 ロックの順番があべこべなのだからデッドロックするのは当然だろう >>870 バカにロックを使わせるな って言う見本 せめて初歩の初歩ぐらい理解してからレスしろよ w >>869 ロックの順番を守る事ができないということです ブロック内にメソッド呼び出しがあることは普通です >>868 >どのオブジェクトをロックしてもこの問題は残ります。 現在している話は、普通のプログラムにおいてロックの順番を守る妥当な方法は存在しないという話です。 synchronizedブロック内でメソッド呼び出しがあった時点でそうなります。 それに対してロックの順番を守ればいいとかthisをロックしろとか言い続けているのは話が分かっていません。 もう少し分かり易い説明を思いつきました。 ここにある問題は、synchronizedブロックで一旦ロック順序を守ったとしても、 そのブロック内から呼び出されているメソッド及びそこから派生的に呼び出されている全てのメソッドにおいて synchronziedブロックを使う場合デッドロックが生じうるという問題で、 リファクタリング等において恒久的に懸念が残り続けるという問題です。 これは一時ロック順序を守ったコードを書いても解決しません。 すみません、経験上凡人レベルの人に話しても理解されなくて、辛い思いをするだけです。 話を終わります。 そうや。情報処理資格のテキストに書いてある。 楽観的とか、ああいうやつ 何も知らない奴が、ギャアギャア言ってるだけ ID:QZT9zuHU = ID:m171VN/W バカのまま永遠にデッドロックしとけ 例題とかじゃなくて、どういう時にロックが必要になるか考えて実際にやってみたらいいんじゃないか そんな複雑なsynchronizedの使い方をしたことはしないだろう >すみません、経験上凡人レベルの人に話しても理解されなくて、辛い思いをするだけです。 世間は俺のことを分かってくれない(馬鹿のFAQ)w ID:m171VN/Wは天才すぎる故に凡人レベルの嫉妬を買ってしまった いや本当。凡人レベルの人には話が通じませんよね。 という具合にみんなして同調しておけばいいのに。 凡人にも理解出来る様に説明出来る能力を持ってるのが、天才の条件だな 説明出来ない人は紙一重の方 まあ責任と前提の問題だな 正常な頭してたらクラスAとクラスBが相互に密結合するような設計をすることはありえないから、 似た状況が起こりうるのはBがAに自身を登録してAがBをinterface経由で「コールバック」するようなパターンだろう その場合、BのメソッドがAのコンテキストから呼び出されることはBを作る側は当然知っているはずで、Aを更に別のスレッドから呼ぶような基地外的行為をしないという人間としての最低限度の責任はB側にある そしてA側はそのようなリスクのある拡張ポイントをなるべく作るべきではないし、やむを得ないときはドキュメントに明記するべき あれだ スレッドを知った初心者が無駄に使いたくなってる状態に近いんじゃないか ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる