20211124のJavaに関する記事は5件です。

Javaコンパイル・実行時の文字化け対策(windows10)

初めに Javaの勉強を始めてみました。VS Codeを使っているのですが、デフォルトで開くターミナルがpower shellであることに気付かずネットで調べたコマンドが動かないよおおお???となっていました。(コマンドプロンプトとpower shellで動くコマンドが微妙に違うため) もっと言うと意地を張らずにJavaはShift-JISで書いたほうがいいと思いますが、気になってしまったので少し調べてみました。 文字化け対策(windows) windowsのコマンドプロンプトでJavaを実行すると文字化けした。 これはJavaファイルをUTF-8で作成したが、コマンドプロンプト(windows)が使用している文字コードはshift-jisであることが原因。 UTF-8を画面に出力するためには以下のコマンドを実行すればよい。 (65001はUTF-8を表す) chcp 65001 shift-jisに変更するときは以下のようにする。 chcp 932 コンパイルと実行 コンパイル・実行コマンドのの基本 javacコマンドでコンパイルできる コンパイルするとclassファイルができる javac Hello.java コンパイル後、クラス名(ファイル名ではない)を指定してjavaコマンドを実行すると、Javaプログラムを実行できる。 java Hello パッケージ名を付けた場合は、パッケージ名を指定してルートディレクトリでコマンドを実行する。 chapter04\Sample1.java package chapter04; public class Sample1 { public static void main(String[] args) { System.out.println(1 + 2); } } java chapter04.Sample1 shift-jis以外で記載されたファイルを実行する ここでは~.javaをUTF-8で保存した場合を考える。 コンパイル、実行にはそれぞれオプションで文字コードを指定する必要がある。 コンパイル javac -encoding utf-8 .\chapter06\Sample.java UTF-8の文字コードを使用して実行(ただしコマンドプロンプトでは実行できるが、powershellではこのオプションの記述では動かない) java -Dfile.encoding=utf-8 chapter06.Sample そもそもwindowsではコマンドプロンプト、power shell問わず基本的にJavaはShift-JISとして出力されるらしいので、chcp 932を実行してShift-JISを表示できるようにした後java Sampleとオプション指定なしで実行すればいいらしい。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

JAVAのWebサーバーにTLS1.3を適用する方法

古いWebサーバーはTLS1.0を使っていますが、TLS通信の安全性を上がるため、 TLS1.3にアップデートしようと思います。 1.暗号化スイートとは SSL(Secure Sockets Layer)とTLS(Transport Layer Security)は、いずれもインターネット上でデータを暗号化して送受信する仕組み(プロトコル)です。個人情報やクレジットカード情報などの重要なデータを暗号化して、サーバ~PC間での通信を安全に行なうことができます。 2.今のTLSバージョンを確認してみて えぇぇ!TLS1.3までアップデートしてなっかたのに、 なぜTLS1.3になっているでしょうか? 3.TLS1.3に変わる原因は? ネットから調べたんですが、 TLS 1.0および1.1は、安全とは見なされなくなったTLSプロトコルのバージョンであり、 より安全で最新のバージョン(TLS 1.2および1.3)に取って代わられています。 これらのバージョンは、デフォルトで無効になっています。 参照URL: https://www.oracle.com/java/technologies/javase/11all-relnotes.html#JDK-8202343 4.結論 JDK11.0.11以降、TLS 1.0 and 1.1が既に無効になるので、 WebサーバーでSSLの初期化設定(SSLContext)を修正しなくても、 TLS1.3になっています。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日本における転職活動についてのユーザーインタビューに外国人ITエンジニア大募集中!

[日本語] ※English Below Jellyfishについて 東京に拠点を置くJellyfishは、技術系の人材紹介会社です。私たちのモットーは、"Expand Your Horizon "であり、海外のIT人材が日本で夢のある仕事を見つけられるようサポートしています。 会社概要 Jellyfishは、オムニチャネル・マーケティング手法を採用戦略に応用し、柔軟性をビジネスの中核に据えています。これまでの求職者の声を聞くと、転職活動の方法やプラットフォームが多様化しており、適切なタイミングで適切な仕事を持つエージェントにアプローチすることが難しくなっています。 これは海外のITエンジニアだけでなく、日本のエンジニアにも当てはまります。タッチポイントを明確に理解し、ITエンジニアがタイムリーに良い仕事を見つけられるようにするために、皆さんの洞察力、経験、提案をもっと知りたいと思っています。 インタビュー内容 ・インタビューは、日本語、英語、韓国語、中国語、ベトナム語のいずれかの言語で行われます。 ・面接時間は45分~1時間、時間帯は9:00~19:00(平日のみ)です。 ・日本在住の外国人ITエンジニアで、日本での勤務経験が2年以上ある方を対象としています。 面接の流れ 企画書の提出を受けて、こちらからご連絡いたします。なお、ボリュームの関係上、お寄せいただいたすべてのご提案にお応えできない場合がありますので、あらかじめご了承ください。 報酬額 Amazon Card 3,000円 ご興味のある方は、以下の情報を添えてh-thu@jellyfish-g.co.jpまでにご応募ください。 ・氏名 ・年齢 ・現在の居住地(日本または海外) ・最終学歴 ・日本語レベル ・職務経験 ・日本での実務経験 ・転職経験の有無 ・現在のポジション ・開発言語 その他、ご不明な点がございましたら、お気軽にお問い合わせください。チャットを楽しみにしています。 [ENGLISH] About us Located in Tokyo, Japan, Jellyfish is a tech recruiting agency. Our motto is "Expand Your Horizon", supporting foreign IT talents to find their dream jobs in Japan. Overview Applying the omnichannel marketing method to our recruiting strategy, Jellyfish embeds flexibility at the core of its business. As we have heard the voice from our previous candidates about how diverse the methods/platforms they are using to find new jobs, it’s difficult to reach out to agencies with the right job at the right time. This does not apply only to foreign IT engineers, but also to Japanese engineers. In order to clearly understand the touchpoint and help IT engineers find a good job timely, we would be appreciated to know more about your insights, experiences, and suggestions. Interview details ・The interview is available in one of the following languages Japanese, English, Korean, Chinese, Vietnamese ・The interview should last 45 minutes to 1 hour within the timeframe of 9:00 ~ 19:00 (JST) (weekdays only) ・We are looking for foreign IT engineers living in Japan, having worked in the country for at least 2 years. Interview flow We will contact you once we have received your proposal submission. Please understand that due to volume, we might not be able to respond to all proposals submitted. Compensation rate Amazon Gift Card 3,000 yen Should you be interested, please submit your proposal to h-thu@jellyfish-g.co.jp with the following information ・Name ・Age ・Current location (Japan or Overseas) ・Final education ・Japanese level ・Work Experience ・Work experience in Japan ・Number of times you have changed jobs ・Current Position ・Development language Should you have any other questions, please feel free to contact us. Looking forward to our chat!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

演算子いろいろ

論理積 && x && y :左辺も右辺もtrueの場合にtrue(左辺 かつ 右辺) 論理和 || x || y :左辺か右辺のどちらかがtrueの場合にtrue(左辺 または 右辺) 論理否定 ! !x  :xがtrueの場合にfalse、xがfalseの場合にtrue
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Javaの乱数生成器について速度面から調査してみる

Java17にjava.util.randomパッケージが追加されたので改めて乱数生成器について調査してみることにしました。 ちなみに本記事では特にどの乱数生成器がよいというような検証はしません。(用途によって向き不向きがあるはずなので) ベンチマーク環境 OS Windows10Pro WSL1 Ubuntu20.04LTS CPU Core i7-10700 (8core 16thread) Memory 32GB Java OpenJDK17 Apache Maven 3.8.3 コード 調査したアルゴリズムについて 各アルゴリズムについてシングルスレッドの場合とマルチスレッドの場合でテストしています。 マルチスレッドは4スレッドとし、実行したPCのCPUコア数内に収めています。 ※Java16までを使う場合の参考としてApache Commons RNGの各アルゴリズムのテストも入っていますが、本記事では割愛。 ※参考用にjava.util.Randomを含めているものの、品質が悪いため実環境では使用しません。 シングルスレッド java.util.Random java.security.SecureRandom (NativePRNGNonBlocking) java.util.concurrent.ThreadLocalRandom java.util.random.RandomGenerator (L64X128MixRandom) java.util.random.RandomGenerator (Xoroshiro128PlusPlus) マルチスレッド java.util.Random java.security.SecureRandom (NativePRNGNonBlocking) java.util.concurrent.ThreadLocalRandom java.util.random.RandomGenerator (L64X128MixRandom) ThreadLocal java.util.random.RandomGenerator (Xoroshiro128PlusPlus) ThreadLocal マルチスレッドで後ろにThreadLocalとついているものはRandomGeneratorがスレッドセーフではないため、スレッド毎にインスタンスを作成するようにしています。 結果 シングルスレッド Benchmark Mode Cnt Score Error Units RandomBenchmarkSingleThread.jdkRandom(1) thrpt 5 131639688.221 ± 832868.840 ops/s RandomBenchmarkSingleThread.secureRandom(2) thrpt 5 2656059.305 ± 14842.602 ops/s RandomBenchmarkSingleThread.threadLocalRandom(3) thrpt 5 501922756.671 ± 2784109.670 ops/s RandomBenchmarkSingleThread.jdk17L64X128MixRandom(4) thrpt 5 331029209.781 ± 3377450.451 ops/s RandomBenchmarkSingleThread.jdk17Xoroshiro128ppRandom(5) thrpt 5 439135306.643 ± 4206646.624 ops/s マルチスレッド Benchmark Mode Cnt Score Error Units RandomBenchmarkMultiThread.jdkRandom(1) thrpt 5 15938216.638 ± 1536272.415 ops/s RandomBenchmarkMultiThread.secureRandom(2) thrpt 5 1835105.725 ± 10398.678 ops/s RandomBenchmarkMultiThread.threadLocalRandom(3) thrpt 5 1915947749.858 ± 96167030.714 ops/s RandomBenchmarkMultiThread.threadLocalJdk17L64X128MixRandom(4) thrpt 5 714011780.505 ± 25031734.867 ops/s RandomBenchmarkMultiThread.threadLocalJdk17Xoroshiro128ppRandom(5) thrpt 5 1035939838.978 ± 77871089.459 ops/s 考察 RandomやSecureRandomはスレッドセーフではあるものの内部で同期化されているのでマルチスレッドで性能が悪化しています。 また、Java17で追加された乱数生成器はスレッドセーフではないためThreadLocalでラップして実験しましたが、4スレッド時に2倍強程度の性能なのでそこまで性能が伸びませんでした。(マルチスレッドで性能が伸びないのはThreadLocalの性能のせいかもしれません) 性能面では以前から存在しているThreadLocalRandomが最も高速でかつマルチスレッド時にほぼスレッド数に比例した性能が出ていることがわかります。 個人的には、暗号やセッションキーの生成等ではSecureRandom。それ以外は通常ThreadLocalRandom。長い周期が必要な場合(ThreadLocalRandomは2の64乗周期でそれほど長くない)に適宜アルゴリズムを選んで使うといったところでしょうか。 ちなみにJava17で利用できるアルゴリズムや周期等の情報はJavadocのjava.util.randomパッケージに載っています。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む