自分が知りえた違いをいくつか列挙しておく
ストリーム
JavaはInputStream(java.io.InputStream)とOutputStream(java.io.OutputStream)というように、入力と出力で二つに分かれている
一方、.NET Framework では、Stream(System.IO.Stream)というように、入出力で一本化している
しかし、
// C# のサンプルコード
DeflateStream compressionStream = ne
w DeflateStream(compressedFileStream, CompressionMode.Compress));
みたいにすると、出力系(write)はよいが、入力(read)しようとするとエラーになるので、必ず入出力できると思っていると痛い目にあう
ストリームの終了
javaは「-1」
.NET Frameworkは「0」。(readByte()メソッドのみ「-1」)
ストリーム(CopyTo)
.NET Framework4以降の CopyTo(distStream)メソッドは便利
フィルタストリーム
Javaにはフィルタストリームという概念のクラス(java.io.FilterInputStreamとjava.io.FilterOutputStream)があるので、これを継承して作る
.NET Framework にはそういうものはなく、Streamを継承して作る
メモリストリーム
Javaはjava.io.ByteArrayInputStreamとjava.io.ByteArrayOutputStream
.NET FrameworkはSystem.IO.MemoryStream
Java/.NET Framework共に、データがちょろちょろとリアルタイムに発生するような場面では使いづらい → read() が終了してしまう。
メモリストリーム(ちょろちょろ対応)
Java はjava.io.PipedInputStreamとjava.io.PipedOutputStreamを使えばいい
.NET Frameworkにはこのようなクラスを知らない
あえて言えば、匿名パイプのクラス(System.IO.Pipes.AnonymousPipeClientStreamとSystem.IO.Pipes.AnonymousPipeServerStream)か
暗号/ハッシュなど(Java)
Javaは細かい
- 暗号
- javax.crypto.CipherInputStreamとjavax.crypto.CipherOutputStream
- それらの実体となるjavax.crypto.Cipher
- ハッシュ
- java.security.DigestInputStreamとjava.security.DigestOutputStream
- それらの実体となるjava.security.MessageDigest
- チェックサム
- java.util.zip.CheckedInputStreamとjava.util.zip.CheckedOutputStream
- それらの実体となるjava.util.zip.Checksum
- MAC
- 実体となるjavax.crypto.Mac
- ストリームはない。・・・という事で作ってみた(MacInputStream/MacOutputStream)
暗号/ハッシュなど(.NET Framework)
統一的に扱っている
ベースとなるクラス
上記のクラスに割り当てるSystem.Security.Cryptography.ICryptoTransformインターフェイスとして
- 暗号
- System.Security.Cryptography.SymmetricAlgorithmのCreateEncryptor/CreateDecryptor メソッド
- ハッシュ
- ICryptoTransform を継承したSystem.Security.Cryptography.HashAlgorithm
HMACは HashAlgorithm 下に
がある。
圧縮
Java/.NET Framework共にリアルタイムに圧縮する機能がなかったが、Java7より[java.util.zip.Deflater#SYNC_FLUSH] (http://docs.oracle.com/javase/jp/8/docs/api/java/util/zip/Deflater.html)が新設されて、リアルタイムなzlib圧縮が可能になった
.NET Framework の場合は、zlib.NET.dllを使えばいいと思うよ。
C#/.NET Frameworkで圧縮を同期的(リアルタイム)に行う方法
SSL
Javaはjava.net.Socketを継承したjavax.net.ssl.SSLSocket
.NET FrameworkはSystem.IO.Streamを継承したSystem.Net.Security.SslStream
.NET FrameworkがStreamを継承しているのに対して、JavaはInputStream/OutputStreamに分岐しているから!? Socketを継承している
SSL オプション(Java)
Javaは多彩
- JavaVM としてサポートされているプロトコル/暗号スイート
- getSupportedProtocols()
- getSupportedCipherSuites()
- インスタンスで有効なものを設定/取得
- getEnabledProtocols()
- getEnabledCipherSuites()
- setEnabledProtocols(String[] protocols)
- setEnabledCipherSuites(String[] suites)
SSL オプション(.NET Framework)
.NET Framework はプロトコル制御のみ!?
Reader/Writer
Java/.NET Framework共に内部文字コードUTF16で統一している
Javaは基本的に実装ごとに用意している
AudioFileReader、FileReader、FilterReader、InputStreamReader、LineNumberReader、PipedReader、PushbackReader、Reader、XMLStreamReader....多すぎ
.NET Frameworkは、System.IO.StreamReaderとSystem.IO.StreamWriterに統一している感じ
ReaderのReadToEnd()
System.IO.StreamReader.ReadToEnd()は便利。
VisualBASIC6.0(Scripting.FileSystemObject)のファイル操作の ReadAll() に近い。とても便利。
マルチキャストUDP
.NET Framework/Java 共に、マルチキャストはUDPとして実装されている
JavaはUDPの実体であるjava.net.DatagramSocketを継承したjava.net.MulticastSocket
.NET FrameworkはUDPの実体であるSystem.Net.Sockets.UdpClientそのもの
サウンド
JavaではStreamを継承したjavax.sound.sampled.AudioInputStreamなので、録音は簡単にできる。
出力(スピーカーへの音声再生)は、Stream ではないが、Streamを継承させるラッパーは簡単に作れるでしょうね
.NET Frameworkは Managed DirectX(MDX) か、3rd Party の SlimDX を使うしかないが結構コーディングは大変かも。
Web(HttpClient)
Javaはjava.net.URLConnectionを継承したjava.net.HttpURLConnection「http専用」とその子供のjavax.net.ssl.HttpsURLConnection「https用」
.NET FrameworkはSystem.Net.WebRequestを継承したSystem.Net.HttpWebRequest「http/https兼用」
Androidはorg.apache.http.client.HttpClientクラス
型の種類
Javaはint,longなど基本的なもの(必要十分なものだけ)
.NET Frameworkは Int32,UInt32,,,など多彩
byte型
Javaは-128～127 (JRuby/Jythonと相互変換する際には注意が必要)
.NET Frameworkは 0～255
個人的には、バイト型に負数とか意味分からん
Staticメソッド
Javaはインスタンス化したオブジェクトの中にもstaticなメソッドが置ける → thisで呼べる
.NET Framework は thisでは呼べない
スレッド
Javaはクラス自体をjava.lang.Threadクラス(java.lang.Runnableインターフェイス)を継承して実装する
→ スレッドはクラス単位と言える
.NET Frameworkは、System.Threading.Threadにメソッドを登録する
→ スレッドはメソッド単位と言える
ロック処理
Javaのロックは「synchronized」
.NET Framework のロックはいろいろ(Windowsの進化と共に...)
Base64
JDK8より java.util.Base64
.NET Framework はいろんなところにBase64
URLエンコード
JavaのURLエンコード(java.net.URLEncoderとjava.net.URLDecoder)は対象が文字列
→ 使えない
文字列の比較
Javaの文字列比較はequals()メソッド
switch文
Javaでは文字列で switch()できない。→ Java8で解消!?
Zlibのリアルタイム圧縮
C#/.NET Frameworkで圧縮を同期的(リアルタイム)に行う方法
XML の外部参照
Java は javax.xml.parsers.DocumentBuilder#setEntityResolver()メソッド
.NET Framework は System.Xml.XmlDocument#XmlResolver プロパティ
XML の外部参照の NULL の挙動
上記のメソッドとプロパティの違いだけでなく、NULL を指定した際の挙動も異なる。
Java は既定のオブジェクトが採用される(つまり、メソッドを呼び出さないでXMLを解析するのと同じ)。
.NET Framework は NULL オブジェクト(つまり、外部参照しない/外部参照を禁止)。
XML の外部参照のオブジェクト
上記の外部参照のリゾルバを指定するオブジェクトは、
Java の場合は org.xml.sax.EntityResolver インターフェイス
.NET Framework の場合は System.Xml.XmlResolver 抽象クラス
XML の外部参照のオブジェクトの唯一実装が必要なクラス
上記の外部参照のリゾルバを指定するオブジェクトに唯一実装する必要があるのが、**「外部参照を示す URIのコンテンツを返すメソッド」**というのは自明だろう。
XML の外部参照のオブジェクトの唯一実装が必要なクラス(Java)
Java の場合は org.xml.sax.InputSource.InputSource resolveEntity(String publicId,String systemId) メソッド
第二引数が String 型だけど外部参照を示す URI が来て、org.xml.sax.InputSource.InputSource クラスが返る。
XML の外部参照のオブジェクトの唯一実装が必要なクラス(.NET Framework)
.NET Framework の場合は object GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn) メソッドだけ。
第一引数に System.Uri クラスで外部参照を示す URI が来て、System.IO.Stream クラスを返すだけ。
返してほしい型/クラスを示す第三引数があるけど、現実は System.IO.Stream クラス しか与えないようなので、やっぱり結局System.IO.Stream クラスを返すだけ。
XML の外部参照のオブジェクトが返す InputSource クラスとは
上記の .NET FrameWork の場合は System.IO.Stream クラスを返すだけなので、すっきりしているが、Java の場合のorg.xml.sax.InputSource.InputSource クラスとは何かというと、
java.io.InputStream クラスと java.io.Reader クラス (と文字コード)をまとめた感じと表現すると分かりやすいと思う。
定番の 3rd party ライブラリ
Java の場合は、Apache-Commonsに大抵は何かある
.NET Frameworkは...知らない
定番の 3rd party ライブラリ(.NET Frameworkのハッシュ)
Classless.Hasherは便利だった
定番の 3rd party ライブラリ(.NET Frameworkの乱数)
麗の小屋 C#乱数ライブラリは便利だった
定番の 3rd party ライブラリ(.NET Framework/Javaの暗号)
The Legion of the Bouncy CastleはJava/.NET Framework共に定番の暗号ライブラリかもしれない