GlassFish Users Group Japan 勉強会 2019 Springのスライド https://glassfish.doorkeeper.jp/events/89314 #glassfish_jp #quarkus
Javaのサポートについてのまとめ Javaのライセンスやサポート状況について混乱が発生しているように思います。Javaのサポートを各団体がどのように行なっているかをまとめてみます。 知っておいてほしいのは、Javaの実装やサポートはOracle JDKかOpenJDKの二択、ではなくAdoptOpenJDKやAzul Zulu、Corretteなど多くの選択肢があるということです。 ここでサポートはバグやセキュリティに対応したパッチがリリースされることを表しています。 Javaのリリースサイクル これまで、Javaは3年ごとを目標に結局5年くらいかけて次のバージョンを出したりしていましたが、それでJavaはなかなかバージョンアップしなくて古いと言われていました。それが2017年9月、今後は6ヶ月ごとにフィーチャーリリースを行うというリリースモデルに変更されました。Java9が2017年9
※注 当初「2018年にJavaを利用している人は全員理解すべきことを説明してみる」として公開した記事ですが、2019年になっても有用性が変わりませんのでタイトルを改変して公開します。 最新ニュース(2019/4/16) www.orangeitems.com 新元号対応のJava SE Development Kit 8u211から、ライセンスが変わり、無償利用は「開発・個人のみ」に変わっています! >> Javaのこの記事が衝撃的 新野淳一さんのとても分かりやすいJavaの将来についての記事を読みました。 www.publickey1.jp これは、大変なことになります。断定します。 劇的に変更されるJavaのサポートポリシー 世の中にはサーバーサイドがOracle Java SE 8で動いているたくさんのWEBアプリケーションが存在しています。Oracle Java 7が2015年4
これは Java 屋の発想で 再実装された言語である dart を使った、 Java 屋の発想で再構築された React だ。 FlutterがReactインスパイアであることは既に宣言されてる。StatelessWidget と StatefulWidget が分離され、State が書き換わった際はState から下のコンポーネントが再構築される。ライフサイクルメソッドがあるので、仮想DOM的な差分管理もしてるはず。 https://docs.flutter.io/flutter/widgets/State-class.html#dispose Flutter は React.createElement の代わりに Widget を継承して React の render 相当の build を override して ひたすら Wigdet を new する。Reactの非常にJava
Eclipseファウンデーションへ移管されたJava EEの新名称が決まりました。 And the Name Is… | Life at Eclipse "Jakarta EE"です。 "Jakarta EE" or "Enterprise Profile"の決選投票が2/23までありました。7000弱の投票のうち65%が"Jakarta EE"へ票を入れています(私もです)。 なぜJava EEから変えるの?Java EEのままでいいんじゃない? むしろJava EEのままにできないから変えるというのが正しいです。こちらの記事に詳しいです。翻訳者は私です。 www.infoq.com "Java EE"に含まれるJavaという単語はオラクルの登録商標です。そのため、Eclipseファウンデーションへの移管が決定したタイミングで、オラクルから"Java EE"および"javax.x"パッケ
ざっくり言うと リスト構造のデータに対してランダムアクセスはしちゃだめだぞ。お兄さんとの約束だ! 発端 数年前に他部署の支援で作ったJavaのシステムに、ちょっとデカめのデータを突っ込んだらありえないほど遅いので助けてくれ、と連絡が入った。 まぁクエリとかインデックスをちょっと見れば直るっしょ・・・と鼻をほじりながら支援に向かった。 処理内容 遅い部分の処理は以下のようなものであった。 処理対象のデータをListで受け取る。 それをforループで1件ずつ前処理する。 処理結果をオブジェクトに格納し、ORマッパーでDBにINSERTする。 これだけ? そう、これだけだ。並列処理なんて高級なことはもちろんやってない。 インフラ調査 処理中のサーバのようすを調査する。今回のインフラは典型的な3層3サーバ構成。 WEBサーバはなにもかもが余裕。 APサーバではCPUを1つ使い切っている。 14コア
来月にはJava 10が登場し、9月にはJava 11が登場予定。新しいリリースモデルを採用した今後のJava、入手方法やサポート期間はこう変わる(OpenJDKに関する追記あり) 2017年9月に「Java 9」が登場したばかりですが、いまから1カ月後の2018年3月には早くもJavaの新バージョン「Java 10」がリリースされます。そしてその6カ月後の9月にはさらに次の「Java 11」がリリース予定です。 Java 9以後のJavaは、毎年3月と9月の年2回メジャーバージョンアップを行う、タイムベースのリリースモデルを採用することになりました。今年はその最初の年となります。 オラクルによるJDKの提供方法やサポートポリシーも、これから大きく変更されることが明らかになっています。一般公開され無償でダウンロードできたOracle JDKの公開はJava 10が最後となり、サポートは3年
VSCodeで、JavaのHot Code Replacement(ホットコード置換)がサポートされた。ホットコード置換を用いると実行中のアプリケーションのコードを実行したまま動的に修正できるため、トライアンドエラーが容易になる。 アプリケーションのコードを修正した場合、その修正を反映させるためには、コンパイル型の言語であれば再コンパイルする必要があり、インタープリタ型の言語であればアプリケーションの再実行が必要となります。 しかしコードを書き換え、実行し、動作を確認するということを何度も繰り返す開発作業では、いちいち再コンパイルをしたり、再実行する手間はなんとも面倒です。 そこでJavaには、「Hot Code Replacement」(ホットコード置換)と呼ばれる機能が用意されています。これはコードを再コンパイルすることなく変更した内容をJavaVMに転送し、反映できるというものです。
Amberとは Java言語を拡張するプロジェクトです http://openjdk.java.net/projects/amber/ Amberのブランチ records データ保持用のクラスです sealed-types シールドタイプ newesapes line blockのエスケープ対応 patterns パターンマッチの全体的な開発 patterns-deconstruction パターンマッチでのデコンストラクション patterns-stage-1 instanceofのみのパターンマッチ pattern-runtime パターンマッチのランタイム? local-methods ローカルメソッド lambda-leftovers ラムダで_使えるようにする concise-method-declarations メソッド定義の簡略化 enhanced-enums 拡張enu
Visual Studio Code Advent Calendar 2017 の 11日目の記事です。 🙂 今年の自分は Java と PHP と JavaScript と電子工作の年だったような気がするのですが、そんな中、全てにおいて随分お世話になりました VS Code。Microsoft から Arduino 拡張がリリースされたのが一番驚きました。 ということで、今日より 3日間 VS Code について書いていこうと思います。まず最初は Language Support for Java(TM) by Red Hat(vscode-java) から。「フロントエンド技術を導入した Java ウェブアプリケーション開発」です。 この記事では VS Code で Java とフロントエンド系の開発を行うサンプルプロジェクトを準備しました。 簡単な操作で昨今のフロントエンド技術を使
かつてJavaは技術の中心だった 私はSIerでシステム開発のアーキテクトやPMを担当しています。SIではまだまだJavaが主流ですが、文法を理解してコーディングできるだけでは活躍できない時代がすでにきていることを実感します。 私の上司が「技術の渦」という独特の表現を使って説明してくれたのですが、2000年から2006年ぐらいまではJavaを書くということは、いろいろな最新技術の実装を学べる時代でした。アプリケーションサーバー、XML、SOAP、MQ、CORBA、マルチスレッドなど、現代の評価としては芳しくないものも多いですが、そういった技術的チャレンジが多かったため、Javaエンジニアはあえて外に出ることもなく、ITの主要技術を学ぶことができていました。 時代の変化とそれへの追随 ただ、Web2.0やiPhone/Android登場以降、技術の渦はフロントエンドを経てアプリへと移ってきま
オラクルはJava EEの策定をEclipse Foundationへ移行することを発表しました。(参考日本語訳) Eclipse Foundationも歓迎の意を表明しています。 Welcome the Java EE community to the Eclipse Foundation. https://t.co/g19n2orVg8 — Eclipse Foundation (@EclipseFdn) 2017年9月12日 オラクルは先月、もうすぐ策定が終了するJava EE 8の登場を機に、今後のJava EEの策定をオープンソースコミュニティへ移管することを模索していることを明らかにしていました。 この時点ではどのコミュニティに移管するのかは検討中とのことでしたが、その後Java EEの主要なコントリビュータであるRed HatやIBMにも相談したうえで、移管先をEclipse
いきさつJJUG CCCというイベントで、「会場が狭い」という感想があった それに対し、イベント関係者から感想に対する不満や、参加者を見下すような発言があった なので、思うことを書いてみる。 Javaというユーザー層が特殊な言語技術力軽視のSIer的な組織に属する人が圧倒的に多い。 会社の技術はいまだにJava5とかで止まってる。 1年の半分以上がデスマーチ。 仕事以外にプログラミングをしたり、技術についての情報収集する人が少ない。 (PCを家に持たない人もかなりいるのでは?) 彼らの考えるセミナー・勉強会講師が生徒を集めて集合教育を行うイベント。 セミナーで話す講師は報酬(お金)をもらっていて、技術力がない人でも理解できる説明をする。 結論を最初に言え。細かい説明とかはいらない。「今一番売れてるフレームワーク」を教えろ) ここは大きな主催者側とのすれ違いポイントだと思う。 そもそも、JJ
2017年4月から人生初めての新人研修講師を務めさせて頂くことになりました。プログラミング入門がテーマです。 先方は昨年までJavaでカリキュラムを組んでいたんですが、JavaをやめてPythonでやらせてもらえないかと提案し快諾頂きました。プログラミングの入門書を書いたから特に感じることなんですけど、Javaはプログラミングの初学者に向いていない言語だと思います。 クラスありきの言語設計 それがJavaの良いところでもあると思いますが、プログラミング自体が初めての方を対象に考えた場合、はじめの一歩として不適切だと感じます。 Hello Worldが重たすぎる お馴染みのHello Worldです。初めてのプログラミングで以下のコードを見たら、何のことやら分からないでしょう。 public class Test { public static void main(String[] args
元記事: Awesome Java Awesome List in Qiita Awesome Ruby Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium Bean マッピング Bean マッピングを容易にするフレームワーク dOOv - 型安全なドメインモデルの検証とマッピングのための API を提供します. アノテーション, コード生成, および型安全 DSL を使用して, Bean の検証とマッピングを迅速かつ簡単にします. Dozer - アノテーション, API または XML 設定を使用して, あるオブジェクトから別のオブジェクトへデータをコピーするマッパー. JMapper - 高速コードマッピングのためにバイトコード操作を使用. アノテーシ
Java 8 Stream API にテキストを流してみる(生成編)- Qiita Java 8 Stream API にテキストを流してみた(終端操作編)- Qiita Java 8 Stream API にテキストを流してみて(中間操作編)- Qiita 要するにだ Java 8 Stream は実行前も実行後もデータを保持しない。 Streamクラス自体はコレクションではなく、流れてくる個々の要素に対する操作のパイプラインを構成しているだけだ。従って Stream を通して加工された要素をデータとして扱うためには、最終的にまた何らかのデータ構造なり値なりに戻されなければならない。 そのためのメソッド群を「終端操作(Terminal operation)」と呼び、そのほかの「中間操作(Intermediate operation)」と区別する。 中間操作メソッドは要素に適用する関数をパ
JDK 1.8 が出てだいぶ経つので、各位もラムダ式を使っていることだと思う。今回はラムダ式を利用したモジュールで Maven コンパイルを実施する場合の軽い TIPS を紹介する。ご存じな方はご存じだと思うが、毎度 pom.xml に記載用の情報を検索するのも面倒なので以下に記載しておきたい。 ハマるポイントとして、ラムダ式を利用したソースで "mvn compile" 等を実行した場合に以下のエラーが発生する点だ。 D:\opt\workspace\Java8CodingProject>mvn compile [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Java8
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える(その1)。JJUGナイトセミナー 2016年5月、GoogleとOracleがJava APIを巡って争っていた裁判に最初の陪審員による評決がくだりました。結果は、GoogleがJava APIをAndroidに流用したことはフェアユースにあたる、というものです。 この評決にはどのような背景があり、IT業界にどんな影響を与えるものなのか。このことをテーマに2016年7月に行われた日本Javaユーザーグループ主催の「JJUGセミナー」の内容を紹介しましょう。 記事は全部で4本(その1、その2、その3、その4)。いまお読みの記事は「その1」です。 日本マイクロソフトで開催したJJUGナイトセミナー 日本Javaユーザーグループ会長 鈴木雄介氏。 今日の前半では私から、JavaとAndroidとOSS(Ope
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか? どの例外をキャッチし、どの例外を伝搬させればよいだろうか? 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか? 例外をどういう単位でラップさせるのが良いだろうか? 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
IOException の catch に何を書いていいか分かりません><! はじめに 順番が前後しますが、今回は Java の特徴のひとつである例外機構についてです。 今回の範囲 223 ページ 〜 250 ページ 前回はこちら Effective Java 読書会 12 日目 「スレッド・セーフってなによ!!」 - IT戦記 Java の例外 throw 可能なオブジェクト Throwable インタフェースを実装したもの Exception を継承しない Throwable は基本的に使わない チェック例外 メソッドの実装者が「呼び出し元が回復可能」だと考えている例外 ちゃんと「なぜ、例外だったのか」理由が提供されるべき 呼び出し元は try catch で囲むか throws 宣言を書く必要がある Exception を継承していて RuntimeException を継承していな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く