Java入門・初心者質問スレ Part.10

2020/04/01(水) 15:09:15.95

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

Java初心者のためのスレッドです。

※前スレ
Java入門・初心者質問スレ Part.９
https://mevius.5ch.net/test/read.cgi/tech/1552143555/

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

2021/05/22(土) 19:49:20.98

>>895
ObjectからKyokumenに型変換してる
てかなにこのひどいメソッド

2021/05/22(土) 19:51:28.10

Java将棋のアルゴリズムという本からの抜粋です
ありがとうございました。

2021/05/23(日) 01:42:48.15

邪悪なコードに見えるけど、きっと抜粋元では型チェックしてるし、オーバーロードもprivateなんでしょう

2021/05/23(日) 13:09:09.14

インスタンス同士の等価でしょ。
丸投げ判定

Ruby で言う、<=> 宇宙船演算子

2021/05/23(日) 13:40:34.46

１　equalsはObjectで受け取るのがお約束
２　次のステップでは適切な型かどうかチェックするのもセオリー
３　その後にようやくホントの比較をする

これをすっ飛ばすとセオリーだけがヘンにこびりついた謎コードが出来上がる
曰く「equalsではObjectで受けとれ」てな村の伝承で型チェックせず無条件にキャストしてる

でも局面と局面以外を比較するミスなんてそうそう起きないでしょコレ
昔からの惰性でキャストしてる

2021/05/23(日) 13:44:08.84

・キャスト知らない
・equalsの典型的な書き方知らない

将棋の本読んでる場合じゃねーぞ
Javaの教科書一通り読んだ方が早いゾ

基本と分かってて基本をやって無いんだからこの先幾度となくつっかかって読み通せなくなるのが目に見えてる

2021/05/23(日) 14:33:42.74

たいてい、どの言語でも「Effective 何々」と言う本に書いてある

インスタンス同士の比較を定義しましょうとか、
インスタンス.to_string を定義しましょうとか

2021/05/23(日) 14:39:32.91

>>902
違うじゃん
キャストが何なのか知らない、分からない、と書いてる

2021/05/23(日) 15:42:25.84

なんでobjectで受け取ってるか理解してないガチ素人しかいなくてワロタｗ
回答側も初心者しかいなくてワロタｗ

2021/05/23(日) 16:04:36.11

Object は基底クラスだから、

つまり、すべてのクラスを受け付けるように作っている

2021/05/23(日) 16:13:39.47

>>899
RubyおじさんJava分かってないじゃん
インスタンス等価を評価したいならそもそもオーバーライドする必要がない
super.equals(k) と書いていない以上、Objectクラスのインスタンス等価の実装が呼ばれることはない
再起でスタックオーバーフローになってないならオーバーロードが省略されてると考えるのが妥当

ついでに言うと、equalsをオーバーロードするのは悪手もいいところ
ただしequalsのオーバーロードをprivateで書いた場合は直ちに実害はない（やりたいとは決して思わんけど）

2021/05/23(日) 16:15:22.80

そういう意味じゃねーんだなぁ

2021/05/23(日) 16:19:28.38

>>906
> equalsをオーバーロードするのは悪手もいいところ

これはどうしてなの？

2021/05/23(日) 16:32:49.81

ルビーのおっさんは論外だからもうレスしないほうがいいぞ

2021/05/23(日) 17:03:37.00

>>908
書くだけ無駄な上にミスを誘発する
特にオーバーロードだけ書いてオーバーライドを忘れるとMapなどでまともに動かなくなる
サブクラスを増やしたときもオーバーロード向けのオーバーライドがいちいち必要になって冗長だしこれまたミスを誘う
オーバーロード間で挙動に一貫性がなかったりするとこれまた分かりにくいバグを生む

2021/05/23(日) 18:20:34.20

>>908
オーバーライドではなくオーバーロードだよ？　悪手に決まってんじゃん
元のコードを読み返してみて equals の中から equals が呼ばれてる
これがスタックオーバーフローしないのは equals(Kyokumen k) というオーバーロードが存在するからと推測できる

このようなオーバーロードをしてるとちょっとしたことでスタックオーバーフローしがち
だからやめようね

2021/05/23(日) 18:56:42.05

内側の隠蔽用途なら、適当に_つけるとかなんかすればいいしな。

2021/05/23(日) 19:05:03.23

>>910
そうなんだ

2021/05/23(日) 19:05:53.77

>>911
キャストしてるからオーバーロードが成立するわけで再帰するわけじゃないっすよね
スタックオーバーフローにはならないですよね

2021/05/23(日) 19:07:30.09

間違って書いたとしてもスタックオーバーフローになるなら実装時に気づくと思うけどなあ
なんでダメなのかあまり説得力を感じなかった

2021/05/23(日) 19:08:22.16

オーバーライド忘れてMapが動かなくなるのはオーバーライドがあろうがなかろうがそんなの当たり前じゃん
君たちの批判はすべて言いがかりレベルの些末なことだよ

2021/05/23(日) 19:09:45.22

僕はそんなミスをしたことがないんだよね、僕が優秀なだけなのかな
なんか優秀でごめんだけど、本当に意味がわからないんだよね

2021/05/23(日) 19:18:10.69

”君たち”じゃないから
くそみたいな低レベルな話してるのはおまえともう一人の奴だけだ
関係ないやつを巻き込むな

2021/05/23(日) 19:19:24.44

>>918
君も含めて、意味がわからないんだよね
君がその代表です

2021/05/23(日) 19:20:23.07

>>918
> equalsをオーバーロードするのは悪手もいいところ

これはどうしてなの？

2021/05/23(日) 19:26:05.46

別にワイは握手なんて言ってない
噛みつくな阿呆

2021/05/23(日) 19:30:45.97

>>921
そうなんです
あなたは何も言ってないんです、だから意味がわからないんです
equalsをオーバーロードするのはあなたにとってどう？

2021/05/23(日) 19:31:01.71

率直に

2021/05/23(日) 19:35:54.83

> public boolean equals(Object o) {
> Kyokumen k=(Kyokumen)o;
> if (k==null) return false;
> return equals(k);
> }

このメソッドはKyokumenでないオブジェクトが渡されたときに
実行時例外が投げられるけれども、実行時例外が投げられるからこそ
実装ミスに気づける良いコードとも言えるわけです

2021/05/23(日) 19:39:00.17

Javaの標準ライブラリはジェネリクス使ってコンパイル時に型の間違いを検出できるようにするのが
理想なんでしょうけどね

2021/05/23(日) 19:50:40.79

頭悪そうだからわかってて言ってるのか知らんが
オバマロードの糞な点はメソッドの選択が動的ではないということだろ

2021/05/23(日) 19:52:33.86

>>914
そりゃあちゃんと書いてれば再帰にはならないけどさ
equals(Kyokumen k) の型を間違えたり変更したりしただけで equals(Object o) がマッチしてしまう危険性がある
たとえば equals(KyokumenB k) にしてしまったりとか

2021/05/23(日) 19:58:09.23

>>926
> オバマロードの糞な点はメソッドの選択が動的ではないということだろ

それはオーバーロードの説明であってクソなところの説明ではないよね
いまだにあなたは何も言ってない状況です、給料泥棒だよ

2021/05/23(日) 19:59:35.86

>>927
型を間違えるっていうのはそれはもうバグなので
スタックオーバーフローでそれに気づけるので良いことですよね

2021/05/23(日) 20:03:19.38

＞それはオーバーロードの説明であってクソなところの説明ではないよね

動的でないメソッドの選択が実装者にとってとてつもなく糞で言語の欠陥って言ってるのが
わからないくらいアホなんだからレスつけるな低能

2021/05/23(日) 20:04:24.08

>>930
どうしてクソなのか説明できる？

2021/05/23(日) 20:05:58.14

説明できなきゃ動的でないってレスもできないよなぁアホ
「私は低能だからわからないので教えてください」って言ったら説明してやるよ低能

2021/05/23(日) 20:07:50.86

>>932
私は低能だからわからないので教えてください

2021/05/23(日) 20:08:15.84

言っとくけど僕にはプライドなんてないからね！！

2021/05/23(日) 20:20:11.34

ほんとド低能は低能すぎてしょうがないにゃぁ
オバマロードしたメソッドはコンパイルされた段階でどのメソッドが呼び出されるか既に確定してるんだよ
今回のように同じ型を引数に渡せるメソッドが2つあった場合Objectの方のメソッドしか絶対に呼ばれない
これが糞な理由だ
これでわからなかった諦めて入門書からやりなおせ低能

2021/05/23(日) 20:22:39.10

今回のようにとは言ったがオーバーロードしたメソッドがあるかは全くわからんけどな
そんなもん作っても呼ばれないんだから無意味だしないと考えるのが妥当

2021/05/23(日) 20:28:33.19

>>935
え、全然わかんないんだけど、何言ってるのこの人、ちゃんと説明してる？

> 今回のように同じ型を引数に渡せるメソッドが2つあった場合Objectの方のメソッドしか絶対に呼ばれない

実引数の型によるよね

2021/05/23(日) 20:29:59.37

よらねーんだアホ
だから低能なんだよお前は
あほ

2021/05/23(日) 20:31:43.15

疑問に思う前に手を動かせ糞初心者
ピーチクパーチク喚きやがって
あほ

2021/05/23(日) 20:38:40.39

>>939
手を動かしてみたけど、引数の型によるよね
https://paiza.io/projects/6YXcZ8p6aqjXKYR2MKMlew

2021/05/23(日) 20:39:30.35

じゃあコンパイラが進化したんだろ
よかったな

2021/05/23(日) 20:40:56.61

>>941
昔はそうだったってこと？いつのとき？ Javaのバージョンは？あなたは手を動かして確認したのだよね？
バージョンいくつで確認したの？

2021/05/23(日) 21:42:48.93

さすがFラン
教える側のスキルも高いww

2021/05/23(日) 23:20:27.21

初心者なんですけどﾜｯﾁｮｲ 4e10-lMMI の涙目敗走負けってことでいいんですか？？

2021/05/23(日) 23:24:15.67

逆
オバマロードが静的であることは事実だから
おまえの負け

2021/05/23(日) 23:32:32.83

SpringBootでコンソールアプリケーションを作成したいんだけど
コマンドライン引数解析でいい感じのライブラリってある？
.NETでは↓こういうのがあってこれの類似品がJavaにあれば助かる
https://github.com/Cysharp/ConsoleAppFramework

2021/05/23(日) 23:42:14.02

ApplicationRunner標準のApplicationArgumentsしか使ってないや

2021/05/23(日) 23:48:00.16

>>944
バグりやすいからequalsのオーバーロードは避けたほうがいいのは間違いない

それ以外にも元のサンプルコードはいきなりキャストして
それからnullチェックとか意味がわからん

2021/05/24(月) 00:37:58.81

>>948
nullのときfalseにしたいだけだと思うよ

2021/05/24(月) 01:14:48.10

>>949
nullのときにfalseにするならキャスト前に o == null で十分
instanceof 使わずに強制キャスト試みるなら k も要らんな
equals((Kyokumen)o) でいいな
どうせテキトーなコードなんだから

2021/05/24(月) 01:34:10.56

>>950
だよね

ググったら近畿大学理工学部で卒業研究が2つヒットした
該当箇所は2つともコメント含め全く同じだったから元ネタは別にありそう

2021/05/24(月) 02:27:54.53

>>950
それはキャストしたあとにヌルチェックするのが不十分ということにはならんよね

2021/05/24(月) 02:29:52.62

if分は三項演算子で十分と言ってるようなもので結局書き手の好みでしかないよ

2021/05/24(月) 02:32:12.56

コストの差なんて誤差みたいなものだしキャストの前と後どちらでヌルチェックするかにこだわるのは時間の無駄だよ、それよりも将棋のアルゴリズムを考えたが良い

2021/05/24(月) 09:16:45.11

たったこれだけのイディオムで書く書かない考えるまでもないだろ。
if (o == null || getClass() != o.getClass()) return false;
GoogleのAutoなんとかやIDEが勝手に追加してくれる。

2021/05/25(火) 03:40:08.61

>>955
一般的に同じクラスじゃないとequals() を真にしないほうがいいのでしょうか。
いままであまり考えずに insuranceOf() で子クラスも ok にしてました。

2021/05/25(火) 08:14:57.06

method(Object o)
というメソッドを呼び出す時、String型だろうがInteger型だろうが引数に渡すことができますが

method(List<Object> oList)
というメソッドに対してList<String>やList<Integer>を引数に渡す事ができないのはなぜでしょうか？

2021/05/25(火) 08:42:01.42

>>957
仕様で禁止
仮にmethod(List<Object> oList)の中でoList.add("test")ってやってたら、List<Integer>を渡されたら困るでしょ

これができないのと同じこと
List<Object> objList;
List<Integer> intList = new ArrayList<>();
objList = intList; // コンパイルエラー
objList.add("数字じゃない");

2021/05/25(火) 09:30:33.81

>>956
実用上、どっちでもいいんじゃね。
その子クラスでもequals()を結局実装することになるだろうし、
そもそもデータクラスで継承使いたくないのもあるし。

2021/05/30(日) 17:47:48.28

JPAのhibernate.ddl-auto=updateって使ってる？

2021/06/04(金) 19:22:32.43

質問です
var stream = IntStream.range(0, 10).boxed();
このStreamから要素数を指定してグルーピングして
[0,1,2],[3,4,5],[7,8,9]
というStreamを得たいのですがどのようにデータを操作すれば良いですか？
Streamではこういうことできなかったりしますか？

2021/06/04(金) 22:35:57.03

なぜ6が抜けてるのか...ミスだと仮定すると
Collection<List<Integer>> values = IntStream.range(0,10).boxed()
.collect(Collectors.groupingBy(i -> i / 3))
.values();
System.out.println(values);

実行結果
[[0, 1, 2], [3, 4, 5], [6, 7, 8], [9]]

2021/06/04(金) 23:26:44.04

>>962
ありがとうございます！
6はミスなので気にしないで大丈夫です
collectはStreamが終わってしまうんですよね
[0,1,2]...をStreamで逐次に読み出したいんですせっかくのStreamなので
グルーピングの処理を逐次でできるといんですけど

2021/06/04(金) 23:44:45.71

無理なんですかね、.NETのLINQのGroupByもシーケンス全部を読み取るようですし
条件を指定した場合は要素を全部見ないといけないんでしょうけど
先頭から数件ごとにグルーピングする場合は理屈としてはシーケンシャルに
読み取れるはずなのでStreamでやれればと思ったんですけど、難しいですねこれ
いったん諦めます、もしわかったかたおられたら教えて欲しいです
私はRxJavaを試してみます

2021/06/05(土) 02:14:20.34

Iterator使ってみた
https://ideone.com/X97Qfj

2021/06/05(土) 02:32:28.30

>>964 すまんグルーピングじゃなくてただのwindowか...
RxJavaなら
Observable.range(0, 9).window(3).subscribe(....)
Streamだと今思いつかない。

2021/06/05(土) 03:00:46.09

>>965
すごいです！

>>966
ありがとうございます！

2021/06/05(土) 18:40:06.43

Kotlin もよろしく

Kotlinだとこうなる

val values = (1..10).chunked(3)
println(values)

出力
[[1, 2, 3], [4, 5, 6], [7, 8, 9], [10]]

2021/06/05(土) 18:48:27.34

>>968
Kotlinすごいです！

2021/06/05(土) 19:12:38.58

Kotlin使いてえ
来週会社に行ったらみんなJavaを書くのをやめてKotlinしか使ってない世界にならないかなあ
あ、転職すりゃいーのか

2021/06/05(土) 21:27:20.46

>>968
chunkedが返すのは残念ながらList<List<T>>

2021/06/06(日) 04:18:19.03

sequenceに変換してからchunkedを呼べばいいんじゃないの？

2021/06/06(日) 05:26:06.72

>>971
Kotlin の場合は List のまま Java の Stream みたいに使えないか?
List のままでも特に困らないと思うんだが。何か問題ある?

2021/06/06(日) 07:26:35.60

>>973
さあ。
Streamが書き易さのためだけにできたと思っているのなら。

2021/06/06(日) 10:23:11.57

>>973
Kotlin使いなのにまさかの初歩的質問だな
StreamとSequenceはパイプライン処理を抽象化したもので遅延評価される
振る舞いが違うし性能に差が出る
シーケンス図で説明できると早いんだが
1万件のリストを10回ずつmapとfilterして結果の先頭1件目を取り出す場合、リストなら必ず1万件全てに対して処理が走る
ストリームなら最初の1件目がお目当ての品だった場合、ストリームから後続の値が取り出されることすらなく処理が完了する

2021/06/06(日) 16:58:45.74

そういう速さを求めるんだったら
そもそもJavaとかKotlinとか使わないと思う

2021/06/06(日) 18:00:10.88

それってぼくは性能追求してないのでfor文で欲しいデータが見つかってもbreak全然書きませんって言ってるようなもんだ
Javaがよく使われる業務領域では社員数に応じてデータ量は増えるしRDBも絡む
小さなコレクションの基礎的な変形操作にしか活用してないならともかく、データの取り出し元がRDBだとか、繰り返し処理が全体に有意差を生むケースはいくらでも想定できる

2021/06/06(日) 18:12:28.57

>>975
JavaのStreamってKotlinのSequenceと同じなの？

2021/06/06(日) 18:42:58.32

>>978
同じではないよ
役割、使い所はほぼ重複している

2021/06/07(月) 01:52:52.07

>>977
大部分のJavaプログラマはそういう理屈が分かっていないと思う

2021/06/07(月) 03:29:56.60

>>975
なんで唐突に Sequence の話になっているのか？

2021/06/07(月) 10:46:02.62

>>981
Kotlinならこう書けるというソースに対してList型なのが残念という流れだからStreamと併記しているんだよ
流れや文脈が理解できないアスペ的な人かな？

2021/06/08(火) 09:50:05.38

>>979
遅延なのは同じでは？

2021/06/08(火) 10:27:33.98

>>983
遅延なのは同じだよ？（うぜえ

2021/06/18(金) 12:15:21.33

質問です
static finalのフィールドにHashMapをセットして
getしか行わない場合は、マルチスレッドで使用しても安全ですか？

↓こういうふうに、コードはイメージです
class Test {
　private static final HashMap<String, String> map;
　
　public Test() {
　　map = new HashMap<String, String>();
　　map.put("a", "A");
　　map.put("b", "B");
　}
　
　public String get(String key) {
　　return map.get(key);
　}
}

2021/06/18(金) 13:16:32.86

>>985
ダメです
コンストラクタではなくスタティックイニシャライザーで要素を追加してください

2021/06/18(金) 13:59:22.34

>>986
ありがとうございます！
↓これなら良いですか？ getはマルチスレッドでも安全ですか？
class Test {
　private static final HashMap<String, String> map;
　
　static {
　　map = new HashMap<String, String>();
　　map.put("a", "A");
　　map.put("b", "B");
　}
　
　public String get(String key) {
　　return map.get(key);
　}
}

2021/06/18(金) 16:19:11.06

valueがイミュータブルかどうかは無視していいの？
keyがイミュータブルでないってのはありえないだろうけど。

2021/06/18(金) 16:29:51.99

いいだろ
これだとput公開されてないし

2021/06/18(金) 20:53:55.88

>>987
いいね！

2021/06/18(金) 21:48:38.57

>>989
例の通りStringならね。
たとえば、Dateみたいなミュータブルだとどうなのって話。

2021/06/19(土) 00:02:36.19

>>987
たぶん安全だと思う
finalである時点で他スレッドからの即時の可視性も担保されてるはず
まあ思考を放棄してConcurrentHashMapを使ったほうが気が楽というのはある

2021/06/19(土) 00:03:44.86

>>991
もちろん書き換えれば壊れるけど、質問者のレベルを察するに知りたいことはそこじゃないと思う

**987** (ﾜｯﾁｮｲ 7601-req2) · 2021/06/19(土) 02:17:51.58

みなさんありがとうございます！

2021/06/19(土) 14:01:39.40

>>991
それはConcurrentHashMap使っても無理でしょ
そのようなケースでは呼び出し側が読み取りから書き換えまでの範囲を排他するしかない