Microsoft、「Java 25」の「Microsoft Build of OpenJDK」ビルドをリリース／少なくとも5年間、2030年9月までサポート
段階的に理解する O/R マッピング - Qiita
はじめに O/R マッピングとは O/R マッピングとは、一言で言えば、オブジェクト指向プログラミング言語においてリレーショナルデータベースのレコードを通常のオブジェクトとして操作する方法である。より詳細な定義を述べるより、実際のコードを見たほうがわかりやすいだろう。以下に、低レベルの JDBC API の利用例と、高レベルの O/R マッピングフレームワークの代表格である JPA の利用例を挙げる。 public List<Issue> findByProjectId(long projectId) { String query = "select id, title, description from issue where project_id = ?"; try (PreparedStatement ps = connection.prepareStatement(query))
mybatisで値オブジェクト（Value Object）を扱う場合のポイント - shimapapa.io
前置き 現場で mybatis を使い始めたのですが、値オブジェクト（Value Object）とマッピングさせる際に少しハマったので整理しました。 環境 Spirng Boot mybatis h2 DataBase SELECT の結果をオブジェクト内の Value Object にマッピングさせる 以下のようなUserNameという Value Object クラスがあったとします。 package com.example.demo.domain.model; public class UserName { private final String value; public UserName(String value) { this.value = value; } public String getValue() { return this.value; } } Userクラスが
Javaの現状：世界で最も人気のあるプログラミング言語の一つであるJavaの動向とデータ
The State of Java: Trends And Data For One of the World’s Most Popular Programming Languagesの意訳記事です。 現代のソフトウェア産業は広大で、プログラミング言語の選択肢には事欠かきません。しかし、Javaエコシステムのような単一の技術スタックであっても、その市場について有益な結論を出すのは難しいことがあります。Javaは信じられないほどの成功を収めており、ほぼすべての主要な産業や経済部門で利用されていますが、このことがJavaエコシステムの状態について一つの断定的な視点を持つことを困難にしている部分もあります。 しかし、だからといって、世界の状況を評価できないわけではありません。 毎日、何千万ものJava仮想マシン（JVM）がNew Relicとデータを共有しています。このレポートを作成するにあたり
チームで取り組む！JavaでNullと真正面から向き合う - Qiita
2009年のカンファレンスでNull参照を発明したことについて謝罪している。 それは10億ドルにも相当する私の誤りだ。 Null安全でない言語を使っている開発者がいつも悩まされている憎き問題です。 計算機科学者である アントニー・ホーア | wikipedia が上記のような発言をしたとおり、言語に織り込まれた技術的負債といっても過言ではありません。 現代の新規開発においては null安全でない言語は、もはやレガシー言語だ | Qiita 記事のようにNull安全でない言語自体を回避するという考え方もありでしょう。 しかしながら、様々な理由でNull安全でない言語を選択しなければいけない場面は尚存在しています。 そこで今回はJavaにおけるNullと向き合う際の手法について考えていきます。 読み進める上での注意点 対策案には「オススメ度」をつけていますが経験に基づく個人的な感想です チーム
モダンなJava開発ガイド (2018年版)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2018年現在でもJava開発をしていると、Antすら使っていないEclipseプロジェクトにそこそこの頻度で出くわします。Eclipseの自動コンパイルが通ればOKであり、ビルドはExcel手順書をもとに手動で行われ、依存関係ライブラリはもちろんlibフォルダに各種jarファイルが放り込んであります。Eclipse上以外ではどう動かせば分かる人がいないため、コマンドラインからビルドなどを行うことは叶わず、CI化なんて夢のまた夢です。 そんなJava開発から脱却したい人向けのJava開発のモダン化ガイドです。 基本的にJava 8以降で
Javaのサポートはこう変わる！ 強化されたDocker対応
前回は、主にJava 10の機能面の変更について説明しましたが、今回はJava 8までの流れと大きく変わった新しいサポートを中心に紹介します。新しいサポート方針に関しては、2017年9月に発表されていましたが、Java 10のリリースとともにJava 9のサポート終了を知り、大きく関心を寄せた方もいるのではないでしょうか。また、Java 10でのDockerへの対応強化についても併せて紹介します。単にDockerへの変更点という意味ではなく、Dockerを利用することは開発時もしくは運用時におけるJavaのバージョンへの依存度の低減につながる対応ではないかと思っています。 編集部より 本稿の一部に表現が不足している箇所がありました。お詫びして訂正いたします。（2018/07/13 13:30） Javaのメジャーアップデートサイクル、サポートサイクルについて、追記いたしました。 Oracl
あまり知られていないと思われる Java のインスタンスイニシャライザの紹介 - satosystemsの日記
スタティックイニシャライザというのは Java をやってる人なら何度も使ったことがあると思う。 Java を 10 年以上やっていて「インスタンスイニシャライザ」というものがあることを先日知った。 public class Test { int i; { // このブロックがインスタンスイニシャライザ System.out.println("1:" + i); i = Math.max(1, 2); System.out.println("2:" + i); } public Test() { } public Test(int i) { this.i = i; } } このコードをコンパイルして逆コンパイルすると、以下のようなコードになる。 public class Test { int i; public Test() { System.out.println("1:" + this.
無償のコードエディタVSCode、実行中のJavaアプリのコードを動的に書き換えて修正できる「Hot Code Replacement」（ホットコード置換）を実現
VSCodeで、JavaのHot Code Replacement（ホットコード置換）がサポートされた。ホットコード置換を用いると実行中のアプリケーションのコードを実行したまま動的に修正できるため、トライアンドエラーが容易になる。 アプリケーションのコードを修正した場合、その修正を反映させるためには、コンパイル型の言語であれば再コンパイルする必要があり、インタープリタ型の言語であればアプリケーションの再実行が必要となります。 しかしコードを書き換え、実行し、動作を確認するということを何度も繰り返す開発作業では、いちいち再コンパイルをしたり、再実行する手間はなんとも面倒です。 そこでJavaには、「Hot Code Replacement」（ホットコード置換）と呼ばれる機能が用意されています。これはコードを再コンパイルすることなく変更した内容をJavaVMに転送し、反映できるというものです。
ラムダ式・Stream APIの理解のポイントは「型」 - 行きあたりばったりエンジニアの日記
はじめに Java SE 8がリリースされて、そろそろ1年が経とうとしています。早いものです。 それはすなわち、Java SE 7のサポート切れが間近に迫っているということでもあります。 そこで今回は、改めてJava SE 8の理解のポイントを解説しようと思います。 ラムダ式・Stream APIの2点が、Java SE 8の目玉となる新機能です。 こんなコードが出てきます。 List<Emp> source = Arrays.asList( new Emp(101, "Nishida", Dept.ADMIN, 500000), new Emp(102, "Nohira", Dept.SALES, 285000), // 以下省略 ); // ラムダ式＆Stream API！ // EmpのListから、Deptが「SALES」の要素のみ抽出し、名前のみのListに集約する List<S
関数型インターフェイスが多すぎる理由を調べてみた - 技術開発日記
Java8について調べると、標準で用意されている関数型インターフェイス関数の多さにびっくりする。 Supplier、Consumer、Predicate、Function、UnaryOperator、BinaryOperator、etc.. 全部で40以上はある。 正直はじめはこれ全部覚えるのかと、かなり憂鬱だったが、おおまかに下記の4つの使い方が理解できれば特に問題ないと思っている。(他のはそれの派生にすぎないため) ・ Supplier ・ Consumer ・ Predicate ・ Function ただ、なんでこんなに多いんだろうと思う人もいると思う。 少なくて、自分は思った。 例えば下記のコードを見てみる。 public static void main(String[] args) { // 文字数を返却するFunctionを定義 Function<String, Integ
あっと驚かせるJavaプログラミング(をやめよう） - Qiita
はじめに 驚き最小の原則（法則）という言葉があります。 Wikipediaの記事を引用すると http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87 ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 要するに、使うときに「おやっ？」という驚きが少ないほうが良いプログラムであるといえます[1]。 [1]: どっちが驚きが少ないか迷う場面もかなり多いですが・・・ この記事では敢えて驚きの多いプログラムの書き方を紹介します。驚きの多いプログラムを読むとどんな気分になるか、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Xeal Gaming – XealGaming – Your UK Universe For All Things Gaming!