タグ付けされた質問 「java」

以前は、@DeprecatedAPIバージョンにアノテーションを追加する標準的な方法を使用していましたが、今後のバージョンでは削除されます。 現在、ライブラリのメジャーバージョンを準備しています。多くのAPIパーツが削除され、名前が変更されています。 既存のユーザーが簡単に移行できるようにするには、新しいライブラリバージョンを古いバージョンと並べて使用できると便利な場合があります。 メリット バージョン間の動的切り替えを実装できます 新しいバージョンでバグが見つかった場合、アプリケーションは前のバージョンにフォールバックできます（ベータ段階で役立ちます） これを行うために、私は単純に新しいパッケージに新しいライブラリのバージョンを移動することができcom.mycompany.libraryへcom.mycompany.library.v2 これは一般的な方法ですか、それともこのようなJavaライブラリの並列使用について他の推奨事項がありますか？ バックグラウンド： ライブラリはシンプルなドキュメントコンバーターです。そのため、convert（in、out）メソッドのほかに、多くの構成プロパティといくつかのイベントハンドラーがあります。サイドバイサイドの使用法を提供する場合、コンシューマーはそれらを動的にインスタンス化して構成できます。 if (useVersion2) { com.mycompany.library.v2.Converter c = new com.mycompany.library.v2.Converter(); // configure and run c.setOption(...); c.convert(in, out); } else { com.mycompany.library.Converter c = new com.mycompany.library.Converter(); // configure and run c.setOption(...); c.convert(in, out); } （質問は/programming/37192945/から移動しました）

8 java  api-design  libraries  versioning 

ホテルの部屋の予約を扱う非常にシンプルなアプリケーションを書いています。ある段階で問題が発生しました。 注文のキューを処理しています。注文ごとに、受付係の1人は、クライアントの戦略に従って部屋（1つまたはまったくなし）を選択する必要があります。それが私がJavaを使うことにした理由Optionalです。問題は、希望する日に空き部屋がない場合は注文をキャンセルする必要があることですが、利用可能な部屋があり、それらのどれもが受付の戦略に適合しない場合は、注文をキューに戻す必要があります。 部屋を選択することは間違いなく受付の義務である必要があります。その問題にクリーンな方法で対処するための最良の方法は何だと思いますか？Optional日付に部屋がない場合、空を返す代わりに例外をスローする必要がありますか？残念ながら、例外は通常、コードフローを制御するための適切なソリューションではありません。 コードフラグメント： Optional<Room> selectedRoom = receptionist.chooseRoom(rooms, order.getQuestionnaire()); boolean decision = selectedRoom .map(room -> receptionist.askClient(order.getClient(), room, order.getQuestionnaire())) .orElse(false); if (shouldProcessAgain(order, selectedRoom.isPresent(), decision)) { orders.add(order); }

8 java  object-oriented  coding-style 

オープンクローズの原則を実際にどのように適用できるかについて、少し混乱しています。時間の経過とともにビジネスの要件は変化します。Open-Closedの原則に従って、既存のクラスを変更する代わりにクラスを拡張する必要があります。クラスを延長するたびに、要件を満たすのは現実的ではないように思えます。列車予約システムの例を挙げましょう。 列車予約システムでは、チケットオブジェクトがあります。通常のチケット、割引チケットなど、さまざまなタイプのチケットが存在する可能性があります。チケットは抽象クラスで、RegularTicketとConcessionTicketsは具象クラスです。すべてのチケットには共通のPrintTicketメソッドがあるため、基本抽象クラスであるチケットで記述されます。これが数か月間うまくいったとしましょう。ここで、チケットのフォーマットを変更するように要求する新しい要件が発生します。印刷されたチケットにいくつかのフィールドが追加されるか、形式が変更される場合があります。この要件を満たすために、次のオプションがあります チケット抽象クラスのPrintTicket（）メソッドを変更します。しかし、これは開閉原理に違反します。 子クラスのPrintTicket（）メソッドをオーバーライドしますが、これは印刷ロジックを複製します。これは、DRY（自分を繰り返さないでください）の原則に違反しています。 だから質問は オープン/クローズの原則に違反せずに、上記のビジネス要件を満たすにはどうすればよいですか。 クラスが変更のために閉じられることになっているとき？クラスが変更のために閉鎖されていると見なすための基準は何ですか？それは、クラスの初期実装後ですか、それとも本番環境での最初のデプロイメント後か、それとも別の場合があります。

8 java  c#  design-patterns  open-close 

SoftwareとConcurrency Revolution（htmlバージョン）という名前の並行性に関する研究論文を読んでいたとき。私は次の行に出くわしました： 残念ながら、ロックは機能しますが、最新のソフトウェア開発にとって深刻な問題を引き起こします。ロックの基本的な問題は、ロックが構成可能でないことです。正しいロックベースのコードを2つ取り、それらを組み合わせて、結果がまだ正しいことを知ることはできません。現代のソフトウェア開発は、ライブラリをより大きなプログラムに構成する機能に依存しているため、ロックベースのコンポーネントを、その実装を調査せずに構築することは困難です。 私は、Javaがどのように構成可能な同時実行性を保証するか、あるいはこのシナリオを生成する方法があるかさえ考えていました。 また、1つ以上のライブラリのデータをどのように同期させることができますか？プログラマーは自分のプログラムからそれを行うことができますか、それとも物事を同期させるのはライブラリ次第です。 Javaでない場合、ロックベースの同時実行を使用し、構成可能な同時実行を保証する他の言語はありますか？ 以下も同じ論文から引用したものです。 同期メソッドには少なくとも3つの大きな問題があります。1つは、他のオブジェクト（Javaのベクターや.NETのSyncHashTableなど）の仮想関数を呼び出すメソッドを持つ型には適していません。ロックを保持したままサードパーティのコードを呼び出すと、デッドロックが発生する可能性があるためです。第2に、同期されたメソッドは、すべてのオブジェクトインスタンスのロックを取得および解放することにより、多くのロックを実行する可能性があります。第3に、プログラムがオブジェクトまたは異なるオブジェクトに対して複数のメソッドを呼び出すときに原子性を維持しないため、同期化されたメソッドはロックをほとんど実行できません。後者の簡単な例として、銀行振込を考えてみましょう。account1.Credit（amount）; account2.Debit（amount）... 注：論文は2005年9月に発行されました

8 java  programming-languages  concurrency  locks 

これは、Javaアプリケーションでの2つの分散コンポーネントの一般的なシーケンスです。 1 A sends request to B 2 B starts some job J in parallel thread 3 B returns response to A 4 A accepts response 5 Job finishes after some time 6 Job sends information to A 7 A receives response from a Job and updates これは、すべてが機能すると仮定した場合の理想的なシナリオです。もちろん、実生活は失敗に満ちています。たとえば、最悪のケースの1つは、#6単にネットワークが原因で失敗した場合です。ジョブは正しく実行されましたが、ジョブAについて何も知りません。 このシステムのエラーを管理する方法についての軽量なアプローチを探しています。多くのコンポーネントがあるため、エラー処理のためにそれらをすべてクラスター化しても意味がありません。次に、同じ理由で各コンポーネントに再度インストールされる分散メモリ/リポジトリの使用を取りやめました。 私の考えは、Bに1つの絶対状態を持ち、Aに永続状態を決して持たないという方向に向かっていAます。これは、次のことを意味します。 …

8 java  distributed-computing 

アーロノートの質問への回答に応じて： すべての静的メソッドを使用することはできませんか？ 静的メソッドに使用されるメモリは少なくありませんか？各オブジェクトインスタンスは、非静的メンバー関数の独自の実行可能バージョンを持ち歩いているように見えます。 OOの設計が不十分であっても、静的メソッドの呼び出しにどのくらいのオーバーヘッドが関係していても、将来の頭痛の種であっても、実行時に使用するメモリが少なくないのではないでしょうか。 次に例を示します。 ゼロで初期化されたオブジェクトのベクトルを作成します。各オブジェクトには、1つのデータ（9つのdoubleで構成される三角形）が含まれています。各オブジェクトは、.stlファイルから読み取られたデータから順に読み込まれます。必要な静的メソッドは1つだけです。適切なOO設計では、データを直接処理するメソッドを各オブジェクトに配布する必要があります。標準のOOソリューションは次のとおりです。 foreach(obj in vec) { obj.readFromFile(fileName); } 各objはreadFromFile、データとともにのコンパイル済みコードを保持します！ この場合、パフォーマンスよりもメモリの方が問題であり、制約されたシステムには大量のデータがあります。 ソリューション： 名前空間メソッド（C ++には最適ですが、Javaでは不可能） objのクラスの1つの静的メソッド。実行可能コードは、実行時に1か所に保持されます。メソッドを呼び出すための小さなオーバーヘッドがあります。 objの派生元の親クラスreadFromFile。プライベートメソッドが含まれます。コールとsuper.callPrivateMethod()その呼び出しreadFromFile。乱雑ですが、各オブジェクトのメモリオーバーヘッドが多少あります。 readFromFileobjのスコープ外に実装するため、vecのクラスまたは呼び出し元のクラスに実装します。私の意見では、これはデータのカプセル化を壊します。 大量のデータの場合、三角形ごとに1つの明示的なオブジェクトを使用するのは最善の方法ではないことに気づきました。これは単なる例です。

8 java  object-oriented  c++  static-methods 

REST APIの設計方法に関するいくつかのチュートリアルに従ってきましたが、まだいくつかの大きな疑問符があります。これらのチュートリアルはすべて、比較的単純な階層のリソースを示しています。これらのチュートリアルで使用されている原則が、より複雑な階層にどのように適用されるかを知りたいのです。さらに、彼らは非常に高い/建築レベルにとどまります。永続層は言うまでもなく、関連するコードはほとんど表示されません。Gavin Kingが言ったように、私は特にデータベースのロード/パフォーマンスについて心配しています： 開発のすべての段階でデータベースに注意を払えば、労力を節約できます アプリケーションがのトレーニングを提供するとしますCompanies。Companies持っDepartmentsていOfficesます。Departments持っていEmployeesます。Employees持っているSkillsとCoursesし、特定のLevel特定のスキルのは、いくつかのコースのために署名することができるように要求されています。階層は次のとおりですが、 -Companies -Departments -Employees -PersonalInformation -Address -Skills (quasi-static data) -Levels (quasi-static data) -Courses -Address -Offices -Address パスは次のようになります。 companies/1/departments/1/employees/1/courses/1 companies/1/offices/1/employees/1/courses/1 リソースを取得する したがって、会社を返すときに、階層全体を返すことはできませんcompanies/1/departments/1/employees/1/courses/1+ companies/1/offices/../。部門または展開された部門へのリンクのリストを返す可能性があり、このレベルでも同じ決定を行う必要があります。部門の従業員または展開された従業員へのリンクのリストを返しますか？それは部門や従業員などの数に依存します。 質問1：私の考えは正しいですか。「階層をどこで切るか」は、私がしなければならない典型的なエンジニアリング上の決定ですか ここで、尋ねられたときGET companies/idに、部署のコレクションへのリンクのリストと展開されたオフィス情報を返すことにします。私の会社には多くのオフィスがないので、テーブルOfficesと一緒に参加するAddressesことは大したことではありません。応答の例： GET /companies/1 200 OK { "_links":{ "self" : { "href":"http://trainingprovider.com:8080/companies/1" }, "offices": [ { "href": "http://trainingprovider.com:8080/companies/1/offices/1"}, { "href": "http://trainingprovider.com:8080/companies/1/offices/2"}, { "href": …

8 java  database  rest  performance  hibernate 

私のプロジェクトIntentExamplesには、サービスに対応するこのフィルターがあります。 <intent-filter> <action android:name="biz.rpcodes.apps.intentexamples.START_SERVICE" /> </intent-filter> 別のプロジェクトUseExampleServiceには、次のようなものがあります。 Intent i = new Intent("biz.rpcodes.apps.intentexamples.START_SERVICE"); startService(i); ...この答えによって導かれる：https : //stackoverflow.com/a/16439551/5181778 私の質問は、複数のプロジェクトにわたってこれらのインテントフィルター文字列をどのように管理すればよいですか？私が今持っている最善の解決策は、Serviceプロジェクトから他のプロジェクトにコピーアンドペーストするクラスを作成することです。 class ExampleServiceIntents { public static final String ExampleServiceIntents.START_SERVICE = "biz.rpcodes.apps.intentexamples.START_SERVICE"; ... Serviceクラス自体をインポートすることもできますが、 new Intent(this, ExampleService.class)Serviceクラスを独自のプロジェクトに保持したいと考えています。

8 java  project-management  android 

私は最近、Java Webアプリケーションプロジェクトに夢中になり、このタイプの形式に従う多くのクラスに遭遇しました。 public class MyThingy { private final int p1; private final String p2; … public MyThingy (int p1, String p2, …) { this.p1 = p1; this.p2 = p2; … } public static void doSomething(int p1, String p2, …) throws Throwable { final MyThingy myThingy = new MyThingy(p1, p2, …); …

8 java  coding-style 

たくさんのモジュールがあります。これらのモジュールを、完全で重複しないさまざまなカテゴリに分類できます。例えば、3つのように表すことができるIDを持つカテゴリ、Animal、Vegetable、およびMineral。さらに、これらのカテゴリをサブカテゴリに分類します。サブカテゴリも、明確で完全であり、重複しません。例えば、のように表すことができるIDS Mammal、Reptile、Legume、Root、Rock、Gem。最後に、これらのカテゴリの下に、モジュール自体が存在し、例えばCat、Dog、Iguana、Bean、Quartz、Emerald、など これが私の一般的な使用例です： すべてのモジュールでさまざまなメソッドを呼び出す必要があります。 すべてのモジュールのすべてのデータの現在の状態のフラットスナップショットを取得する必要があります。 特定のカテゴリ（サブカテゴリではない）のすべてのモジュールでさまざまなメソッドを呼び出す必要があります。 既知のIDに基づいて、特定のモジュールでさまざまなメソッドを呼び出す必要があります。 これは、「何かをする」または「自分についてのデータを教えて」のいずれかです。 特定のカテゴリ（サブカテゴリではない）のすべてのモジュールに関する集約データを保存する必要があります。 このデータをどのように保存すればよいですか？ 他のいくつかの関連する事実： カテゴリは実行時に確立されます そのため、最下位レベルのモジュールは共通のインターフェースを共有します。 いったん設定されると、それらはその特定の実行で変更されません-それらは設定ファイルのデータに基づいています。 これが私が現在していることです： を含むクラスがありますMap<Category, CategoryDataStructure>。このクラスは、要件＃2で使用するためのデータの個別のCollection<Module> ビューも保持します。 CategoryDataStructureを介して、メソッドコールをチェーンに送信するチェーンされた委譲メソッドがありますSubCategoryDataStructure。 CategoryDataStructure 要件＃5で使用される集計データも格納します。 それは機能しますが、正直なところかなり扱いにくいです。全体はステートフル/ミュータブルであり、変更が困難です。新しい動作を追加したい場合は、多くの場所に追加する必要があります。現在、データ構造自体にも多くのビジネスロジックがあります。委任方法。また、親データ構造は、特定のモジュールと必要に応じてその親データ構造、および必要に応じてその親のデータ構造を作成するために、多くのビジネスロジックを実行する必要があります。 どういうわけか、データ管理ロジックをデータ構造自体から切り離そうとしていますが、ネストが複雑なためです。ここに私が検討してきた他のいくつかのオプションがあります： シンプルなを作成し、Map<Category, Map<Subcategory, Module>>すべてのコードを配置して、その状態を別のクラスに保持します。これを行う際の私の懸念は要件＃1と＃2です。同じデータを表す2つの異なるデータ構造があるので、ビューの一貫性を保つのは困難です。 すべてをフラットなデータ構造で実行し、特定のカテゴリまたはサブカテゴリを探す場合は、構造全体をループします。

8 java  design  object-oriented-design  data-structures 

私が取り組んでいるプロジェクトの依存関係の一部として、いくつかのコアサービスを使用しています。私たちが大きな変更を加えることができないこれらのサービスは、大きな混乱です。呼び出すメソッドに応じて、パラメーター（および戻り値）を別のエンコーディング、ロケール、タイムゾーンに変換する必要があります。 これらのパラメーターは独自のコードの複数の場所で生成されるため、これらの変換は複数の場所で実行されます。私たちがそれらを私たちの側に渡す前に、それらを生成するときがあります。コアサービスでメソッドを呼び出す直前。混乱がコード全体に広がっているので、それを分離するためのレイヤーを導入したいと思います。 私の質問は、そのための最良のアプローチは何ですか。最初は、使用する必要がある各サービス/メソッドに対応するサービス/メソッドを作成することを考えました。これらのメソッドは、単に変換を実行し、コアサービスに委任し、戻り値の変換を実行します。しかし、これはどういうわけか扱いにくいようです。 その後、アノテーションを使用することを考えましたが、使用方法は完全にはわかりません。そして、私が理解しているように、理想的には、呼び出されたメソッドに注釈を付ける必要があります。たとえば、パラメーターを@converToUtcで注釈し、注釈の実装で変換を行うことができます。これは正しいです？もちろん、これは私たちのコードではなく、現在私たち以外のプロジェクトでこれらのメソッドを使用しているコードを壊すので、これは難しいことです。 この状況に最適なアプローチは何ですか？

8 java  clean-code  layers 

専用インターフェースは、ドメイン固有のタイプ階層でオプション機能を公開するための良い方法のようです。ただし、これらはデコレータおよび複合パターンの使用を妨げます。これは、この種の階層でも一般的です。 特に、おそらくこれらのインターフェイスの可能な組み合わせごとにデコレータ/コンポジットを実装する必要はないでしょう。そのため、多くの場合、すべてのオプションのインターフェイスを実装し、型チェックを使用して呼び出しを選択的に転送します。これにより、インターフェイスを分離する目的が損なわれます。 Javaコレクションフレームワークが使用する別の方法は、すべての操作を基本型に含め、それらをダミーの実装で埋めることです。Java 8のデフォルトメソッドは、この使用をさらに容易にします。 ある意味で、これは、データベースの世界では、null許容列の議論のように感じられます。より実用的な後者のアプローチに対して強い議論はありますか？

8 java  design-patterns  interfaces 

nullに割り当てられた変数と割り当てられていない変数のメモリの違いは何ですか？ 使用方法に違いがあることは知っていますが、メモリの違いは何ですか？

8 java 

Java Systemクラスには、さまざまなデータメンバーとそこに存在するのに最適なメソッドが含まれています。例えば： System.in (variable) System.err (variable) System.out (variable) System.exit(int) System.gc() System.getSecurityManager() など、しかし、私がそこにいることを理解していない方法があります： System.arraycopy(Object, int, Object, int int) 1つの配列を別の配列にコピーすると、Arraysクラスに属しているように感じます。ドキュメントから以下： このクラスには、配列を操作するためのさまざまなメソッド（ソートや検索など）が含まれています。このクラスには、配列をリストとして表示できる静的ファクトリーも含まれています。 配列を操作する方法は、この結論を私に指摘するものです。ある配列を別の配列にコピーすることは、確かに配列操作ですよね？ 私の質問はそう：なぜあるarraycopy()でSystem？ 初期のJava Systemクラス実装の遺物ですか？このメソッドは非推奨としてマークされていないため、少し迷っています。さらに、JavaのcamelCase標準に準拠していないため、初期のライブラリ設計の遺物であるという考えに立ち返ります。

8 java  design 

メッセージングにActiveMQを使用するJavaシステムがあります。また、システムは1秒間に約400から600のトランザクションを処理し、すべてがスムーズに実行されていても問題はありません。システムは、これらのトランザクションを外部システムに送信する必要もあります。 外部システムが長時間（たとえば1〜2時間）ダウンしている場合、私たちが行うことは、キューの停止中に外部システムに正常に送信されなかった失敗したメッセージ（再試行キューと呼ばれるもの）をドロップすることです。 。 これらのメッセージをタイムリーに処理して、外部システムに回復する十分な時間を与える必要があります。 私たちはいくつかのアプローチを試みましたが、どれも完全に機能するようには見えません。それらのほとんどは、処理するメッセージの数が少ない場合に機能します。 アプローチ＃1： JMSヘッダーにタイムスタンプを設定するActiveMQ遅延を使用しました（詳細については、こちらをご覧ください：http : //activemq.apache.org/delay-and-schedule-message-delivery.html）。キューには数百または数千のメッセージがあります。 50万件以上のメッセージがあると、メッセージが失われることがわかりました。 たとえば、2万通のメッセージでもメッセージが消えたことがわかります。 メッセージが1時間に最大12回試行されるように、遅延を5分に設定しました。外部システムが1時間ダウンしたとき、すべての20kメッセージが少なくとも12回再試行されると予想しました。 5分ごとに消費すると、次のことがわかりました。 試行1：20kメッセージ試行2：20kメッセージ 試行7：19987メッセージ試行10：19960メッセージ試行12：19957メッセージ 時々、すべての2万通のメッセージが処理されましたが、テスト結果に一貫性がありませんでした。 アプローチ＃2： ActiveMQの再配信ポリシーを使用しました。接続ファクトリレベルでポリシーを設定し、セッションを処理し、外部システムがダウンしているときに例外をスローするため、ブローカーは再配信ポリシーの設定に基づいてメッセージを再配信し続けます。このアプローチも、停止がより長く続く場合にはうまく機能せず、ノンブロッキングのコンシューマーを用意する必要はありません。ディスパッチキューレベル自体で機能し、着信トランザクションが多い場合はキューに負担をかけます。 アプローチ＃3： X分ごとに起動するQuartzスケジューラーを使用して接続を作成し、コンシューマーが再試行キューからメッセージを取得してさらに処理を試み、外部システムがまだダウンしている場合は、失敗したメッセージをキューの後ろに置きます。このアプローチには多くの問題があり、接続や消費者などを管理する必要がありました。 たとえば、キュ​​ーにメッセージが2つある場合、メッセージの数よりも多くのコンシューマーがあると、メッセージがコンシューマーによってピックアップされ、同じコンシューマーがメッセージを再試行にドロップします（外部システムはまだダウンしています）、別のコンシューマーがそれをピックアップしているため、コンシューマーとブローカーの間でメッセージが行き来します。 アプローチ＃4： 失敗したメッセージのDBへの保存を試み、QスケジューラーをX分ごとに実行して、DBからメッセージを取得しました。 これは最適化されていないだけでなく、複数のノードで実行されているDBコンシューマとDBの間の多くのトランザクションチェックが含まれます。 私の環境は、Java、JBoss、ActiveMQ 5.9、MySQL 5.6およびSpring 3.2です。 再試行テンプレート（Springから）やJava 7/8での非同期再試行パターンなど、他のいくつかのアプローチを実行しました この問題についての私の見解は、ほとんどのソリューションは最小の負荷がかかっているときに機能し、停止が長く続くか、メッセージの量が本当に多いときに壊れるように見えるということです。 失敗したメッセージを保存して転送できる場所を探しています。400 TPSシステムの場合、1時間で144万のメッセージが届く可能性があります。 外部システムがダウンしている場合は、これらの144万のメッセージをどのように処理するかによって、メッセージやパフォーマンスを失うことなく、各メッセージが再試行される機会が均等になります。 私が持っている環境の範囲内で解決策を探しています。

8 java