タグ

ブックマーク / nagise.hatenablog.jp (71)

  • Project Valhalla 2023 - プログラマーの脳みそ

    2023/03/30 にやったJava仕様勉強会の動画が公開されました。当日はJavaのマスコットDuke風の服で臨みました(どうでもいい裏情報) www.youtube.com セッション資料もアップロードしたので参考にしてください。 Project Valhalla 2023 中間報告 いずれも 2023年3月時点での情報です。JEPもドラフト版だったりするので、将来的に変更が入る可能性が高いことをお断りしておきます。稿では勉強会のセッション内容に加えて、セッション時点で追従できていなかった変更点や、勉強会での指摘を踏まえてフォローアップした内容を含みます。 もしもValhalla世界でJava入門したら ここでは、Valhalla導入後のJava世界だと入門者視点でどのように変わるのかというアプローチをしています。まず、Javaのデータ型は大きくふたつに分類できて、Identity

    Project Valhalla 2023 - プログラマーの脳みそ
  • なぜ自動テストの導入は失敗するのか? - プログラマーの脳みそ

    開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど? まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか? というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ

    なぜ自動テストの導入は失敗するのか? - プログラマーの脳みそ
  • 西暦1年は閏年か? - プログラマーの脳みそ

    閏年(うるうどし)の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる?」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。当にそうだろうか? そう単純な話なのだろうか? プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月(太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ)をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法(ちじゅんほう)は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年(つまり2月

    西暦1年は閏年か? - プログラマーの脳みそ
  • Spring boot で作るAPIと React のビルドを共存させたい - プログラマーの脳みそ

    Spring boot では Webシステムをmain起動のスタンドアロンのJavaプログラムのように起動して試せる点が便利である。ところでこうしたサーバーサイドのWeb APIを作るようなケースで、Reactのようなコンパイルを伴うWebクライアントと連携して動作するようなものを開発するとき、どのようなプロジェクトのディレクトリ構成でどのようなビルド、どのような実行をすると便利にやれるのだろうか? IDEの有償プラグインがこうした開発を統合してくれるのかもしれないが(試用して回ったわけではないのでよくわからない)ここではギョームで普通に用いられているEclpise IDE と Visual Studio Codeの組み合わせで考えてみたい。(稿ではIDEは主題ではないので、任意のIDEで検討してもらいたい) Spring の フォルダ SpringのQuick Start に従い、デモ

    Spring boot で作るAPIと React のビルドを共存させたい - プログラマーの脳みそ
  • Javaのクラス名の形式まとめ - プログラマーの脳みそ

    Javaのクラス名の表現方法で 「全部同じじゃないですか」 「ちがいますよーーっ」 「これだからしろうとはダメだ!もっとよく見ろ!」 をやっている🤔— なぎせ ゆうき (@nagise) April 14, 2020 Java言語を扱っていると何通りかのクラス名の表記法を見ることがある nagise.sample.Hoge.Piyo nagise.sample.Hoge$Piyo nagise/sample/Hoge$Piyo [Lnagise.sample.Hoge.Piyo これらの違いは何なのか。 Javaのクラス名関連の専門用語を調べ直してみた。 用語 日語 概要 Identifier 識別子 識別に用いるもの全般を指した抽象度の高い表現 Class Name クラス名 一般に言うクラス名。比較的曖昧な表現。文脈によってはInterfaceも含む。ネストしたクラス、内部クラスの

    Javaのクラス名の形式まとめ - プログラマーの脳みそ
  • Javaのリスク考察 2018年版 - プログラマーの脳みそ

    Java10以降、Java SEのリリースサイクルを6カ月単位とすることが発表されてしばらく経ち、また、予告通りJava11からいよいよJavaのサポート体制も変更となった。 稿ではJavaを使い続けるリスク、あるいはほかの言語ランタイムを使い続けるリスクについて検討してみたい。プログラム言語は用途に応じて様々なものが使い分けられている。特に稿では選択肢が多く、またJavaのシェアも高いサーバーサイドのWebシステムという戦場で検討してみたい。 「Javaリスク」という単語、語呂が良い— なぎせ ゆうき (@nagise) 2018年10月11日 pic.twitter.com/tBGvupxtJ4— rf (@rf0444) 2018年10月11日 ランタイムの有償化リスク 無償で提供されていたプログラム言語のランタイムが、突如有償化するリスクをまず考えてみよう。この点で、Java

    Javaのリスク考察 2018年版 - プログラマーの脳みそ
  • ジェネリクスと配列 - プログラマーの脳みそ

    Javaのジェネリクスは一般に配列と混ぜてはいけないとされるが、混ぜて用いた場合に何が問題となるのか。 歴史的な問題 Javaが1995年に登場した当時、Javaに配列はあったがジェネリクスはなかった。 ジェネリクスを含む型システムの理論的な整備は、1990年代から2000年代にかけてのJavaのバージョンアップの時期に並行して行われていた。これは1995年当初のJavaになぜより良いジェネリクスを搭載した形でリリースされなかったのか?ということにひとつの答えを示すだろう。つまり、1995年当時にはジェネリクス(Java5に搭載されたような変性を含むもの)は未来の技術であって、まだ理論的に固まっていないものであった、というわけだ。 Java言語仕様にも記述されているが Historically, wildcards are a direct descendant of the work b

    ジェネリクスと配列 - プログラマーの脳みそ
  • Java Generics Hell - new T() - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 24日目。 前回(22日目) イレイジャ 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 今回はJavaのジェネリクスでは型変数を用いてnew T()できないけど特に問題ないという話。 コンストラクタの形 コンストラクタは、その内部でthisが使えるしインスタンスフィールドへのアクセスもインスタンスメソッドへのアクセスも出来る。そこからするとインスタンススコープのメソッドのように見えるが、インスタンスに所属しているわけではない。 インスタンスメソッドを呼び出すにはインスタンスを指定するか、自分のインスタンスのメソッド呼び出しでthis.を省略できる、というシチュエーションでなくてはならない。逆に言えば通常のclassのnewはインスタンスなしで呼び出せるわけで、所属としてはclassのstaticに相当する。

    Java Generics Hell - new T() - プログラマーの脳みそ
  • Java Generics Hell - イレイジャ - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 22日目。 前回(20日目) ブリッジメソッド 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 メソッドのオーバーロード Javaのジェネリクスのイレイジャについて語るには、まずメソッドのオーバーロードについて語らねばなるまい。 メソッドのオーバーロードとは、同名で引数の型違いのメソッドのことである。 public class Hoge { public void foo() {} public void foo(String s) {} } Javaではなぜ同名のメソッドを宣言することが出来るのであろうか?コンパイラが、あるいはJavaのランタイムであるJavaVMが、メソッドを特定するときに 属するクラスの完全修飾名 メソッド名 引数の型の並び によってどのメソッドを呼ぶか特定しているのである。 これはリ

    Java Generics Hell - イレイジャ - プログラマーの脳みそ
  • Java Generics Hell - ブリッジメソッド - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 20日目。 前回(19日目) 内部クラスと型変数のスコープ 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 共変戻り値 Java5以降ではメソッドをオーバーライドするときに、戻り値をより具体的な型としてオーバーライドすることが許されている。 public interface Parent { Number getValue(); } このjava.lang.Number型を返すgetValue()メソッドをChild型でオーバーライドするときにNumberの子であるInteger型にすることができる。 public class Child implements Parent { public Integer getValue() { return 0; } } これが共変戻り値だ。 ジェネリクスを用いている場

    Java Generics Hell - ブリッジメソッド - プログラマーの脳みそ
  • Java Generics Hell - 内部クラスと型変数のスコープ - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 19日目。 前回(18日目) ジェネリックな例外 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 Javaでは1ファイルにトップレベルのpublicなclassはひとつしか置けないが、入れ子になったクラスなどを用意することができる。種類がいくつかあるので後に整理するが、内部クラスの場合、外側のインスタンススコープの型変数が内部クラスの内側でも有効となる。 今回はそのあたりを整理してみよう。Javaのクラス宣言の種類については拙稿 Javaのクラス宣言5種+αで以前に取り上げているので参考にされたい。 static 内部クラスの話の前に、そもそも論としてクラスのインスタンススコープの型変数は、staticなメソッドや、フィールドでは用いることは出来ない。なぜなら、インスタンスをスコープとしているからだ。(トート

    Java Generics Hell - 内部クラスと型変数のスコープ - プログラマーの脳みそ
  • Java Generics Hell - ジェネリックな例外 - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 18日目。 前回(16日目) 型変数のバインド 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 throws E Java のジェネリクスの型変数は例外のthrows宣言でも用いることができる。型変数の宣言時にthrow可能な型であることを型変数の境界で示す必要がある。 public <E extends Exception> void hoge() throws E {} 上記はメソッドスコープの型変数 E を extends Exception としてみた。メソッドスコープの型変数だとthrowsに型変数を用いる意味があまりないが、型システムの挙動を見る分にはコード量が少なくて済むので都合が良い。 バインドの仕方でthrowされうる例外が変わる、例外が変わるのでcatchするべき例外も変わる。 // IO

    Java Generics Hell - ジェネリックな例外 - プログラマーの脳みそ
  • Java Generics Hell - 型変数のバインド - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 16日目。 前回(15日目) ワイルドカード落穂ひろい 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 メソッドスコープの型変数 メソッドスコープの型変数へのバインドについては以前も書いたが再掲しておこう。 使用する場合は、通常はバインド型が推論されるのでそのまま呼び出せば済む。 Set<String> set = Collections.singleton("hoge"); 型変数にバインドする型を明示する場合はメソッドの手前に山括弧で指定する。 Set<String> set = Collections.<String>singleton("hoge"); メソッドスコープの型変数については明示的にバインドしなくても概ね型が推論される点は知っておくと良い。これはジェネリクスが導入されたJava5当初からあ

    Java Generics Hell - 型変数のバインド - プログラマーの脳みそ
  • Java Generics Hell - 反変ワイルドカード - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 14日目。 前回(13日目) 共変ワイルドカード 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 反変ワイルドカード さて、前回は共変ワイルドカードについてだった。今回は反変ワイルドカードについてである。 反変ワイルドカードは? superを用いて以下のように記述する。 List<A> listA = new ArrayList<A>(); List<? super B> listSuB = listA; // 代入可能 このlistSuBは次のような性質を持っている。 listSuB は B型を格納することが出来る listSuB から取り出した型はObject型となる 前回のList<? extends A>型は、戻り値がA型であることが保証された。代わりに引数でA型オブジェクトを渡すことができなくなった

    Java Generics Hell - 反変ワイルドカード - プログラマーの脳みそ
  • Java Generics Hell - ワイルドカード落穂ひろい - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 15日目。 前回(14日目) http://d.hatena.ne.jp/Nagise/20171214/1513260215=反変ワイルドカード 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 共変ワイルドカードと反変ワイルドカードについて書いたので、残りの話題を拾っておこう。 Unbounded Wildcard 共変でも反変でもないただのワイルドカードとして<?>を見たことがあるのではないだろうか。 言語仕様上はUnbounded Wildcardと表現される。適当に訳すと無制限ワイルドカード、だろうか。 何が無制限かというと代入が無制限に行える。 List<?> list; list = new ArrayList<String>(); list = new ArrayList<Integer>();

    Java Generics Hell - ワイルドカード落穂ひろい - プログラマーの脳みそ
  • Java Generics Hell - 共変ワイルドカード - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 13日目。 前回(11日目) 型変数の境界 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 変性 パラメタライズドタイプについては以前に書いたが、ワイルドカードについては後回しということにしていた。 <>の内部については非変性であるということは何度か述べてきたが、特定の制限下で共変性、あるいは反変性をもたせることは出来るだろうか? 共変性 パラメタライズドタイプが共変である場合、何が問題になるのだったか再確認しよう。以下ではclass Aを親とし、class Bが子供という関係とする。パラメタライズドタイプを共変とするとき? extends を用いて以下のように記述する。 List<B> listB = new ArrayList<B>(); List<? exnteds A> listExA = listB

    Java Generics Hell - 共変ワイルドカード - プログラマーの脳みそ
  • Java Generics Hell - 型変数の境界 - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 11日目。 前回(8日目) インスタンススコープのジェネリクス 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 週末サボりました。すいません。 型変数の境界 ここまでは話を簡単にするために型変数の境界については触れずにきた。 しかし、型変数の境界についてはそこまで難しい話ではない。その型変数が何かを継承していることを制約としてつけることができる、というだけである。 public class Hoge<T extends Piyo> { } ここで、TはPiyo型かもしくは、Piyo型を継承した何かでなくてはならない。この時、class Hogeの中で型変数T型の変数はPiyoを継承していることが保証されるので、Piyoに定義されるメソッドを呼び出すことができる。これを型変数の境界という。なお、指定できるのはe

    Java Generics Hell - 型変数の境界 - プログラマーの脳みそ
  • Java Generics Hell メソッドスコープのジェネリクス - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 7日目。 前回(6日目)ジェネリクスの構文 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 前回、構文の話をしていたが、そのなかでメソッドスコープのジェネリクスをいったんおいていた。 今回はそのあたりを取り上げる。 ジェネリクスとスコープ 前回のおさらいとして、Javaのジェネリクスには2つのスコープがある話をしていた。 メソッドの範囲で有効な型変数 クラスのインスタンスの範囲で有効な型変数 まずジェネリクスのそもそも論になるが、ある処理の塊に型変数という「型」を表す変数を導入し、処理の塊をいろんな型で扱えるようにしよう、ということになる。ここで「処理の塊」としてJavaのジェネリクスでは「メソッド」か「インスタンス」か、ということになる。 メソッドスコープの型変数は インスタンス・メソッド static メ

    Java Generics Hell メソッドスコープのジェネリクス - プログラマーの脳みそ
  • Java Generics Hell - インスタンススコープのジェネリクス - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 8日目。 前回(7日目) メソッドスコープのジェネリクス 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 ようやくクラスの型変数の話にたどり着いた。なかなか話題が多くて大変なのである……。 インスタンススコープ ここのところしつこくJavaのジェネリクスの型変数には2種類のスコープがあることを挙げてきた。 メソッドの範囲で有効な型変数 クラスのインスタンスの範囲で有効な型変数 前回、メソッドスコープのジェネリクスについて取り上げた。入門書などではあまり触れられていない構文かもしれないが、機能的にはメソッドスコープのほうが単純だと思うので先にメソッドスコープを取り上げた次第である。 メソッドスコープではメソッドの IN / OUT つまり、引数と戻り値を型変数を用いて関連性を示すことができるということを書いた。

    Java Generics Hell - インスタンススコープのジェネリクス - プログラマーの脳みそ
  • Java Generics Hell - ジェネリクスの構文 - プログラマーの脳みそ

    Java Generics Hell アドベントカレンダー 6日目。 前回(5日目) パラメタライズドタイプ 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 ここまで話の簡単のためにいろいろ端折って書いてきているのだが、徐々に詳細を書かねばなるまい。同時に取り漏らしも回収して行かなければならない。 スコープ Javaのジェネリクスの型変数には2種類のスコープがある。 メソッドの範囲で有効な型変数 クラスのインスタンスの範囲で有効な型変数 List<String>といった例でバインドされているのは後者のクラスのインスタンスを範囲としたもの。よく目にするのがこちらだろう。 前者のメソッドの範囲の型変数は入門書ではあまり取り上げられていないかもしれない。しかし、話としてはメソッドスコープの方が単純なのできっちりやるならメソッドスコープから導入したほうがわかりやすいのではない

    Java Generics Hell - ジェネリクスの構文 - プログラマーの脳みそ