こんにちは、server-side kotlin や terraform を書くことが多い、エンジニアリングGの矢崎(id:Saiya)です。 タイムゾーンや日時の扱いについての話題がホットな昨今ですが、 そういった日時の扱いについて例えば以下のようなお話を受けることが少なからずありました: とりあえず日時は UTC からの時差情報付きで扱えばいいんでしょ？ DB に保存するときもタイムゾーン情報付きで入れておけばいいんでしょ？ こういったお話を振られた際に、思うところを一言でサッと説明できずもやもやする事もあり、 また web サービスにおいて日時・タイムゾーン・オフセットをどう扱うべきか？納得の行く説明をあまり見つけられなかったため、 筆者なりに考えをまとめてみました。 国家的祭典のために急にサマータイムが導入されるといった話に限らず、 クラウドサービスが UTC+0 の日時になってい
今回のエントリから、Apache Tomcat を題材としたコードリーディングを始めます。 Tomcat の全体像の理解と、起動やリクエスト処理などで何が行われているかを 大雑把に把握することを目的とします。 まずはTomcat自体の説明と、コードリーディングを行う上であると便利なものをご紹介します。 Apache Tomcat - Wikipedia Apache Tomcat (アパッチ トムキャット) は、Java Servlet や JavaServer Pages (JSP) を実行するためのサーブレットコンテナ（サーブレットエンジン）である。Apache License, Version 2.0を採用したオープンソースソフトウェアであり、商用利用も多い。Java Servlet 3.0、JavaServer Pages 2.2対応。バージョン 7.0 は JDK 6 以降が必要
こんにちは！ヘンリーでソフトウェアエンジニアをしている @agatan です。 今日は小ネタで、サーバーサイド Java / Kotlin エコシステムで意外と使われている ThreadLocal と、それを Coroutine と安全に組み合わせる方法について紹介します！ TL; DR ThreadContextElementを使おう！ ThreadLocal とは java.lang.ThreadLocal<T> は、その名の通り、スレッドローカルな（= スレッドごとに独立した値を持つ）変数を定義するための機構です。 ある Thread で値を書き換えたとしても、他の Thread から見た ThreadLocal 変数の中身は書き換わらない、という性質があります。 import kotlin.concurrent.thread val tls: ThreadLocal<Int> =
Java仕様の決定に関わるエグゼクティブコミッティに「日本Javaユーザーグループ」の選出が確定。立候補理由や今後の活動を聞いた Javaはその仕様策定の過程で、Javaに関係する企業やJUG（Java User Group）と呼ばれるコミュニティなどの組織、個人開発者などが多数参加し議論が行われるJCP（Java Community Process）と呼ばれるプロセスがあります。 Javaが長い間、発展と進化を遂げてきた理由に、このオープン性があります。 このJCPの中で、特に仕様策定の推進や決定の役割を担うのがExecutive Committee（エグゼクティブコミッティ／執行委員。以下、JCP EC）です。 そして今年、2023年のJCP ECの選挙に日本Javaユーザーグループ（以下JJUG）が立候補し、先月（11月）に発表された選挙結果によって、JJUGがJCP ECに選出され
世界 30 億の Java エンジニア向けに、Java 言語仕様・JVM仕様のバージョンごとの差分を見れるページを作りました。 The Java Language Specification diffs The Java Virtual Machine Specification diffs ぜひご利用ください！ なにこれ？ Java の各バージョンごとの言語仕様・JVM仕様はこちらのページで公開されています。 Java Language and Virtual Machine Specifications ただ、バージョンごとの変更点がありませんでした1。 そこで、各ページからテキストを抜き出して2、GitHub 上で差分が見れるようにしました。 更新について 細かい誤字脱字の変更とかを除いた差分が作れるとより良いのですが、そうすると今後の更新に手間がかかってしまいまそうでした。 それよ
Red Hat で Solution Architect として OpenJDK を担当している伊藤ちひろ（@chiroito）です。 この記事は、Red Hat Developerのブログ記事、Get started with JDK Flight Recorder in OpenJDK 8u | Red Hat Developer の翻訳記事です。 OpenJDK 8u 262 releaseには、いくつかのセキュリティ関連のパッチと、新しい追加機能であるJDK Flight Recorder(JFR)が含まれています。この記事では、OpenJDKの開発者向けに、JDK Mission Controlや関連ユーティリティーを使ったJDK Flight Recorderの使い方を紹介します。また、コンテナJFRとして知られるProject Hamburgについても簡単に紹介します。 JD
こんにちは、SREの戸田です。本日は社内で開催したJVM勉強会（運用編）の一部を公開します。 JVM、使っていますか？弊社ではサーバサイドKotlinが活躍しているので、もちろん日常的にJVMが稼働しています。このためサービス運用の一貫で必要になる知識や関連ツールなどをSREないしプロダクトチームに共有することを目的として、この勉強会を開催しました。 図1 勉強会はGoogle Meetでオンライン開催しました パフォーマンス・チューニング サービスを開発していると、この処理をもっと高速化したい！ランニングコストを抑えてユーザ体験の向上に投資したい！というというシーンには多く遭遇しますよね。こうしたユーザが増えてサービスに負荷がかかるようになったことで生じた課題に対して迅速に打ち手が取れることは、とても重要です。 しかし焦ってはいけません。「このコードはめっちゃループしてるし遅そう！」「あ
How to Compute Without Looking: A Sneak Peek into Secure Multi-Party Computation This article shows how you can compute a function across multiple parties that do not trust each other without forcing them to share their individual inputs. This technique can be used to split secrets among parties, perform logical operations, or count votes in a way that ensures data privacy is preserved.
運営元のロゴ Copyright © 2007-2025 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
このエントリーは Java Advent Calendar の9日目のエントリーです。 qiita.com Virtual ThraedはJava 19でPreview (JEP 425)、Java 20でSecond Preview (JEP 436)となり、うまくいけば次のLTSであるJava 21で導入予定です。 パフォーマンスを考える時に、一般的にはスループットと応答性の2つがあります。スループットは単位時間あたりにどのくらいリクエストをさばけるか、応答性は処理のリクエストから結果が帰るまでの時間です。Virtual Threadのこの2者のうち、スループットを向上させるために導入されます。 では、なぜ今になってVirtual Threadが導入されるのかということを、歴史を振り返りながら考えてみるのがこのエントリーです。 いにしえの時代 - Java 1.0からJ2SE 1.4
はじめに 先日、JakartaOne Live Japan 2022というイベントで登壇させていただく機会を頂きました。 QuarkusやHelidonのような新しめのEEフレームワークがこれまでのPayaraやWebLogicとどう違うのか？ CloudRunのようなサーバレス環境でMicroProfileのどの機能が効果的に働くのか？ という点を最近のWeb開発周りのトレンドと絡めながら話ました。上記のようにアーカイブ動画も公開されていますが、せっかくなのでQuarkusがサーバレス環境で実行に最適化されるまでの周辺事情等をまとめたいと思います。Javaだけに留まらず最近の環境事情の整理にも役立つかと思います。 TL;DR Quarkus/Helidonは軽量で高速な新しいEEフレームワーク コンテナや、サーバレス、クラウドネイティブなど最新のトレンドに基づいた設計 GCPのCloud
社内ミートアップでLTの時間をもらったので、ここに書いた内容を3分で喋ろうとしたんだけど、どうしても3分をちょっと超えてしまうので無理を言って4分もらって喋ってきた(運営のみなさんありがとうございます)。ぐったり。明日から普通のエンジニアに戻ります。 dev.to 実感を大切にしてみた こういうことに気をつけてLTしてみた： ブログの記事に書いてるコードを見せるんじゃなくて、実際のIDE内のソースコードを見せること そのときにIDEAのプレゼンテーションモードで見せること 実際にアプリを動かした状態でcurlで叩いて動いてるのを見せること Gatlingを実際にgradleで実行すること そこでBlockingAppのスレッドが増えるところをVisualVMで実際に見せること その方が聞いてて「へー。本当に動くんだ」とか「さわってみようかな」とか思ってもらえるかなーと思って。ってことで以下
この記事はブロッキングやノンブロッキンクとは何か、Servlet3.0の Async Servletや Servlet3.1の NonblockingI/Oとは何か、を理解することが目的です。 検証バージョン> java -version java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) > ver Microsoft Windows [Version 10.0.17134.165] ブロッキングI/OI/Oをする際(read,write)に、処理がブロックされる。例えばサーバがソケットをreadしたら、リクエストが届くまでスレッドをブロックして待つ。 @
2021年12月10日、Javaベースのログ出力ライブラリ「Apache Log4j」の2.x系バージョン（以降はLog4j2と記載）で確認された深刻な脆弱性を修正したバージョンが公開されました。セキュリティ関係組織では過去話題になったHeartbleedやShellshockと同レベルの脆弱性とも評価しています。ここでは関連する情報をまとめます。 １．何が起きたの？ Javaベースのログ出力ライブラリLog4j2で深刻な脆弱性（CVE-2021-44228）を修正したバージョンが公開された。その後も修正が不完全であったことなどを理由に2件の脆弱性が修正された。 広く利用されているライブラリであるため影響を受ける対象が多く存在するとみられ、攻撃が容易であることから2014年のHeartbleed、Shellshock以来の危険性があるとみる向きもあり、The Apache Software
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
