時折、バイトを int に変換するときに & 0xFF が必要になりますが、私はそれを問題とは考えていません。
なぜだめですか？「ビットごとの AND を 0xFF に適用する」ことは、実際にコードが表現しようとしているものの一部ですか? そうでない場合、なぜそれを書かなければならないのですか？実際、バイトをある場所から別の場所にコピーするだけでなく、バイトでやりたいことのほとんどは、マスクが必要になることがわかりました。私は自分のコードを無造作にしたいと思っています。符号なしバイトの欠如はこれを妨げます:(
さらに、常に負でない値を返すか、負でない値のみを受け入れるAPI を検討してください。unsigned 型を使用すると、検証を必要とせずに明確に表現できます。個人的には、.NET でunsigned 型が使用されていないのは残念だと思います。String.LengthICollection.Count
Java に署名されていない型がないことは致命的な欠陥ですか? 明らかに違います。迷惑ですか？絶対。
あなたが引用したコメントは頭に釘を打ちます：
Java に符号なしデータ型がないことも、Java の妨げになっています。はい、回避できますが、理想的ではなく、基になるデータを正しく反映していないコードを使用することになります。
符号なし 16 ビット整数を必要とする別のシステムと相互運用していて、数値 65535 を表現したいとします。「データは単なるビットなので、ここでは問題は見られません」と主張しますが、合格する必要があります- 1 は 65535が問題であることを意味します。データの表現とその根底にある意味との間のインピーダンスの不一致は、コードの書き込み、読み取り、およびテスト時に余分なスピードバンプをもたらします。
代わりに、符号なし数値と符号付き数値の間の演算とそれらの間の変換を考慮する必要がない方が簡単だと思います。
これらの操作を考慮する必要があるのは、2 つの異なる型 (1 つは符号付き、もう 1 つは符号なし) の値を自然に処理している場合だけです。その時点で、あなたは絶対にその違いを指摘してもらいたいと思っています. 当然のことながら符号なしの値を表すために符号付きの型が使用されているため、違いを考慮する必要がありますが、そうすべきであるという事実はあなたから隠されています。検討：
// This should be considered unsigned - so a value of -1 is "really" 65535
short length = /* some value */;
// This is really signed
short foo = /* some value */;
boolean result = foo < length;
fooが 100 で、-1であるとしlengthます。論理的な結果は何ですか？の値は65535 をlength 表すため、論理的fooにはそれより小さくなります。しかし、おそらく上記のコードを使用すると、間違った結果が得られるでしょう。
もちろん、ここで異なる型を表す必要さえありません。どちらも自然に符号なしの値である可能性があり、負の数が正の数よりも論理的に大きい符号付きの値として表されます。同じエラーが適用され、言語に署名されていない型がある場合は問題になりません。
Joshua Bloch とのインタビュー(Google キャッシュ。現在は java.sun.com から削除されていると思われます)もお読みください。
いい質問ですね... Java プラットフォームで最も奇妙な点は、バイト型が署名されていることです。これについての説明は聞いたことがありません。これは非常に直感に反しており、あらゆる種類のエラーを引き起こします。