この場合には、ファイナライザを使用する必要があります。いるアプリケーションのすべての側面に関して、パフォーマンスが大幅に低下します。Sunでは、ファイナライザを使用しないことを推奨しています。これは許容されるトレードオフではありません。この要件は仕様から削除されていますが、何箇所かこの表現が残っている場合があります。JDBCチュートリアルの場合も同様です。トリアルは参考になり便利ですが、正式なドキュメントではありません。何年間も更新されていません。4.0仕様では、自動クローズは一切必要ありません。Statemnent、およびConnectionのすべてにおいて、クライアント側とサーバー側の両方のリソースが採用されます。オープンされている限り、関連するリソースが割り当てられます。このリソースが解放されるのは、オブジェクトがクローズされたときのみです。Statementがクローズされます。Statementをクローズすると、関連するすべてのResultSetがクローズされます。Connectionを終了する場合は、ConnectionをクローズするだけですべてのStatementとResultSetがクローズされます。これは許容できるプログラミング手法です。適切な手法は、最終ブロックでStatementとResultSetを明示的にクローズすることです。することにより、アプリケーションが要件の変更に適合するように修正された際に堅牢度が増し、リソース・リークが発生する可能性も低くなります。現在の状況について教えてください。このセクションでは、単純なデータ型について説明します。マッピングされていました。場合と同様に日付と時刻の両方の情報が含まれているため、この処理にはある一定の意味がありました。刻情報が含まれていないため、java.sql.Dateに明確なマッピングを行うことには多少の問題がありました。マッピングすることに関して問題はありませんでした。9.2では、RDBMSにTIMESTAMPのサポートが追加されました。違いは、TIMESTAMPにはナノ秒が含まれていますが、DATEには含まれていないということです。マッピングされています。時刻情報を含めるためにDATE値を利用していた場合は、問題が発生します。9.2以降10.2までのドライバでは、この問題に対処するために次のいくつかの方法が用意されています。表において、DATEの代わりにTIMESTAMPを使用するよう変更する。まれなケースと考えられますが、最適な解決策です。なくTIMESTAMPとして定義するよう変更する。ういうもので、いつ使用すればよいですか。