【java】jdk8も出るし、何か作ってみるか【lambda】
■ このスレッドは過去ログ倉庫に格納されています
Javaの書き方が気にくわないから
俺はJavaそんなに好きになれない JDK8 RC版でラムダ書くの面白かったよ。
少し前にリフレクションでnew()するオーバーヘッドを消すために
javassistで書き換えてるフレームワークがよくあったけど、
これからはファクトリーメソッドをラムダで書かせるだろうね。 とりあえず初めの方はバグが多いんだろうな
しかし新機能や改良点には期待してる JPA, Hibernate, その他もろもろにおいて、Entity Bean class は
トップレベルであることが必須だった。
これはリフレクション.newInstance()における制約があったからで、
これからは1ファイル内に何個も定義できるようになる方向に変化していくはず。 日本だとJBoss EAP8が出てから1年後くらいじゃないと業務で使えないな >>9についてだが、MVCフレームワークとかも同じだな
Controller(Action)はpublic classである必要があったが〜(以下略 職場では、つい先月、やっとJDK7を使えるようになったんだが。 たぶん一番恩恵を受けるのはAndroidのイベントリスナーだと思う
googleのAPI対応も早いだろうし 嵐の前の静けさ ←イマココ
嵐の中の静けさ
嵐の後の静けさ PermGenは名前が変わっただけで直ってないんだろ。java9に期待。 ちょうど日付操作したいからJava8を試すかと思ったらまだ来てないとは
Joda-Timeでも試すか このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所 >>20
Joda-Timeでなく、敢えてJDK8の日時クラスを使う理由が見いだせない。
設計者の変なこだわりで使いにくくなってると思うんだが。 気のせいか起動が早くなってない?
電源入れた後の初回起動のイライラ感があんまりない JDT/Eclipseの正式対応が5月くらいになるのか WinとLinuxは入れ替えても良いけどMacだとめんどくさいお
全部のプラットフォームつかってるからなおさらめんどくさいお >>27
4.3.2 JDTのJava8対応は、すでに正式版(GA)。 >>25
Linux版だけど起動は確かに速くなってるな どっかからJava8にしないでくださいってメールがきたぞw 嬉しくてチンチンたちまくりレイプ事件が多くなるのを心配してるんだよ >>31
例えばこれだね www.gaitame.com/info.html
> 現在、「Java8」では『外貨ネクストネオ』のリッチアプリ版が起動しないこと、Webブラウザ版のチャートが表示されないことを確認しておりますので、アップデートをしないようお願いいたします。 >>34
今回そんな互換性なくなるような変更点あったっけ?
セキュリティ関連でデフォルトが変わった奴とかのせいか? lambda?
オッサンにはぜんぜん理解できん(T_T)
あんなんで書かれた日にゃメンテナンス性が著しく低下しそう それはさすがに理解してくれよ。
最初は匿名クラスのシンタックスシュガーぐらいのもんだと思ってりゃいいんだよ。
匿名クラス禁止とか言い出すようなら、転職するしかない… http://news.mynavi.jp/special/2014/java8/
この辺の例にある、
list.sort(new Comparator<String>(){
@Override
public int compare(String s1, String s2){
return s1.length() - s2.length();
}
});
が、
list.sort((s1, s2) -> s1.length() - s2.length());
こう書けるのはすごく便利そう。というか下の見た後だと上は冗長過ぎ。
複雑なラムダ式はよう判らんが、こういうレベルのはどんどん普及してほしい。
むしろこれすら理解できない老害は氏ね。 何か作ってみるかと思ったらインストールできない
調べたらXPはサポート外かよゴミ言語だな XPがゴミだとふざくんなよ
いまだにXPでネットやってる >>41 がゴミ >>44
酷いつーか、来週からどうすんだ?
割とマジで迷惑だろ>>XP残留組 えっ・・・Java8はWindows XP で動かんの?
プラットフォームに依存しない、ってのがJavaの最大の"ウリ"ではなかったのか >>46
終わったプラットフォームとか生まれる前から死んでるプラットフォームでは動かないよ EclipseはLuna4.4待ちなのかと思ったら
JDT自体はGA来てたのな 使った感じeclipseのjdtアドオンはまだ不安定だよ Once write, debug everywhener >>37
どこが難しいのかさっぱり。。。
むしろ7より前でコーディングする気が失せた
今の職場は当然のように7だけどね
あとAndroidとかGAE対応はどうなんだろうね
ここあたりすっげー遅いイメージしかないんだが、Google先生 Month while, the dog everyone. HTML idだとまずいことに気づいた
独自属性java:keyにして、出力時には消えるようにしよう >>61
なんか読めなかった
後でPCで見ておくよ >>61
感想なんて書かれないのが普通なんだからアクセスログでほくそ笑んでれば良いじゃんよ。 一部修正した。html idで全部やってたことを独自属性java:xxxに変更。
これによってhtmlからjavaのスケルトンソースを生成するツールも作れる Qiitaで書き散らそうかと覗いてみたけどそういう雰囲気じゃなかった サーブレットのdoGET, doPost... に値するところは
メソッドのオーバーライドでも大して変わらんね
少し前のフレームワークではアノテーションでやっていた
httpパラメータからのコンバータやバリデータをラムダでやると効果的かもしれん
wicketのそれが近いと思う Lambdaでやらせるなら表示の絞り込みとかの方がよくね?(SQLで得た一覧をmemcachedに蓄えたりした奴のフィルターとかソートね) Model側で別の層になるなそれ。
少し前にEntity Rulerという名前で
RDBライブラリ(O/Rマッパー)作ろうとしていたのだが
アイデアがフラフラしたあげくに頓挫しちゃったんだよね >>68
で言われているようなことをする場合、普通はSQL内でやるもんだよね。
whereとかjoin書かないで全部拾ってきて、java側でフィルターすると
ネットワークIOがボトルネックになるからさ。
HSQLかH2に限定すれば、ストアド(具体的にはユーザー定義関数)を
javaで書けるから何でもストアド化するって手もあるんだけど、
(そうするとネットワークIOの問題は解決する)
RDBに関する全般的な知識がないから、おれにはちょっと荷が重い さて、Webライブラリの話に戻るんだけど、
cakePHPとかだとバリデータがModelの処理とされているように、
web(http/html)と直接関係ないものは全てModelとして扱う。
(コンバータ、バリデータ etc...)
そして本ライブラリはMVCのVとCのみを扱うため、
HTTPクエリ/パラメータからのコンバータなどは作らない。
従ってあとはクッキーとセッションあたりをどうするべきか考えれば
とりあえず完成、version1.0をリリースできるな。 おいJava8めっちゃ高速になってないか
GCの性能もめっちゃ良くなってるようなきがするんだが
みんなどう? みんなまだ様子見くらいしかしてないんじゃないの?
JRE7とJRE8でパフォーマンス計測したなら教えてよ あと、Nashornクソ遅い
巷ではRhinoより速いと言われてるらしいが >>76
Rhino-1.7R5
Node.jsのサブセットみたいなものを自作して使用中なんだが
使い方が悪いのかしらんがNashornは超遅い おとなしくnode.js使えよ
V8パワーを実感できるぞ 自作言語をjavascriptに変換して実行とか面白いかもな
javassist使ったほうがいいかもしれんが >>78
JSだけで完結するならそうなんだけど、
Java資産を流用せにゃあかんという要求がありまして UncheckedIOException 見て
Javaはそろそろ限界だと感じた ソースのプロトタイプ生成ツールの試作品ができた
具体的には.htmlから.javaを生成するツール
入力(html)
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns:java="http://hoeppe.the-ninja.jp/" java:page="Tutorial4">
<body>
<div>Item List</div>
<div java:canvas="list">
<div java:group="fragment">
<div>Item</div>
<div java:key="index"></div>
<div java:key="name"></div>
</div>
</div>
</body>
</html> 出力(java)
package org.ruler.markup.tool.export;
import org.ruler.markup.api.Page;
import org.ruler.markup.api.Canvas;
import org.ruler.markup.api.Group;
@Mount(path="/default.html")
@Source(file="tutorial4.java")
public class tutorial4 extends Page {
@Source
Group fragment = new Group();
@Source
Canvas list = (node) -> {
};
@Override
public void action(Http http) {
http.GET = (event) -> {
event.setCode(Code.OK_200);
event.setType(Type.html);
event.draw(this);
};
};
} とりあえずjavadocとjar本体をアップしたぜ
チュートリアルだけ試せます tomcatプラグイン紛らわしいね。使わないほうが良さそう javaさようなら。
見捨てられたXPユーザより。 >>88
頼むからネットに繋ぐのはやめてもらえないか? UIラップだけに切り出した方がいいんじゃないかねぇ それは可能だし、Viewのみにすると規模が縮小して俺も楽なんだけど、
どちらにせよSpringMVCとかJersey、JSF2といった
今主流のControllerと連携はできないんだよね Controller周辺は拡張ライブラリで自由に選べるようにして置けば汎用性高いのが出来ると思う
コンテナまで実装は無駄が多すぎる
IDや特殊IDでマッピング出来てピュアなhtmlで作れるのはそれなりに需要高いと思う 参照実装つくるならstruts1だろうね
単なるライブラリとして完全に分離された状態で連携できる
(サーブレットAPIのRequestとResponseを直接使えるから)
SpringMVC、Jersey、Playだとフレームワーク毎に対応したもの作るの大変 前言撤回w よく調査したら、独自Viewを持つJSF2以外は簡単に連携できそう
とりあえず自作コンテナ or Jersey(EE標準)で利用可能な方向に修正しようと思う
SpringMVCやPlayでもそのまま動かせると思うが、触れないで置く
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.ruler.markup.api.Page;
import org.ruler.markup.api.Source;
import org.ruler.markup.api.Canvas;
@Source(file="/xml/template.xml")
@Path("/hello")
public class HelloWorld extends Page {
@GET
@Produces(MediaType.TEXT_HTML)
public String sayHello(){
String html = super.draw();
return html;
}
@Source
Canvas canvas = (node) -> {
node.setAttr("style", "color:FFFFFF;");
node.addText("Hello World");
};
} そのさい、多少APIを変更するのは避けられない
Responseを乗っ取れないようなので
いったん丸ごと一つの文字列にしなければならなくなる
無駄に大きい文字列結合は結構コストになる
それでもDI、コンバータ、バリデータが全部流用できるのが大きいが JAX-RS v2.0 を試そうとApache CXFを試したが、hello worldも実行できず断念
Glassfish(Jersey)やJBoss(JBoss Rest Easy)はtomcatで使いたいので断念
JAX-RS v1.1 しか使えないが、jarも少なくてコンパクトなApache Winkで調査中〜 >>53
よくわかんねーや、仕様を日本語で書いてくれ。 javadocとかhtml書くのも大変なのよ
javadocは日本語と英語を併記しようとして失敗した
チュートリアルも日本語がおかしいかもしれない
もしくは、もっと全体的な概要のことだろうか? >>103
そうだよ、ぱっとみてなにやってんの?てなかんじ その指摘はたぶん半分正しい。
XML(REST, AJAX)だとDOMは遅くない
HTMLだとDOMは遅い。
なぜならHTMLはほとんどが静的なデータの塊であって、
動的でない部分をDOMで保有していると、直列な文字列へと変換する無駄が生じる。
チュートリアル1では、全てをDOMで操作しているので、たしかに処理に無駄がある。
従ってチュートリアル1は最も自由度の高いAPIであるが、HTMLではなくXML(REST, AJAX)向きだ。 これを踏まえたうえで、チュートリアル02, 03を見てほしい。
Canvasというクラスがでてくる。Canvasに指定されたノードは、動的な領域である。
逆説的に言えば、それ以外の領域は静的であるということ。
実は、内部で静的な領域を最適化している。
Node.classにはjavadocに載っていないが、onReady()というメソッドがあって、
あらかじめ直列化された(変わりに変更不能になった)文字列へと最適化している 具体的に書くと、Nodeは通常以下のデータを持っている
String タグ
HashMap<String, String> 属性
List<Node> 子ノード
コレを連結して < + タグ + 属性="属性値" + > </ + タグ + >を生成する。
静的な領域として登録されたNodeは、次のように固定される
String 開始タグ <div class="xxx" onclick="xxx">
String 終了タグ </div>
List<Node> 子ノード
従ってDOMは自動的に、最適な形式で最適化されるのだ ちなみに、このonReady()というメソッドはサーバー起動時に行われる
初期化の中で実行され、アプリ開発者には触れないようにパッケージアクセスになっている そんなわけで、計測していないが、JSPでタグライブラリ使うよりは
むしろ早いんじゃないかと思う。
JSPだとBeanUtilsとかでリフレクション使うが、
こちらはまったくリフレクションと無縁だし。 そーいえば、バグを修正してからソースアップしてなかったや 質問してた人は分かってくれたのだろーか?
ま、いっかー♪ このフレームワークは、JSPを代替するものである。他はあってもオマケなのさ
SpringMVCといったモダンなフレームワークやJSP/Servletをそもそもほとんど知らないと
さすがに厳しいだろうね .どうでもいいけど^2、大きくでたね、恥ずかしい。 どうでもいいなら最初から質問しないこと
そして>>105のような知ったかをかまさないことだな JAX-RS(Jerseyとか)に対応したかったが、
あれJAXB専用だという結論に達した
EE標準で他になんか無かったっけ テンプレート指定でpojoぶち込んで変換する程度なのになぜそんな難しい事だと思うんだろう・・・
ちゃんと考えたらオプショナルなライブラリとして切り出せるよ JAX-RSはInputStreamでリクエストを処理できるから何使ったっていいやろ @Templateはglassfish独自だったような。
もう一度JAX-RSの勉強してみる。 できれば、glassfishに依存しない、jbossでも可能な純粋なJAX-RSが望ましい
それでプレーンテキストではなく、xml/htmlやjsonを
次のような形式で返すのはダメだった気がするけど、俺の気のせいか?
まあ試してみるか!
public class POJO {
@GET
@Path("/aaa")
@Produces("text/html") // @Produces("text/plain")
public String hello(){
return "<? XML宣言 ?><html><body>fuck you</body></html>";
}
} あと良く見たら、HttpServletResponseのOutputStreamで出力みたいな方法があるね
どうやって使うのか分からないけど、上記の方法(>>126)がダメだったらこっちを調べる 今やってみたら普通にできた。俺は一体なにを勘違いしてたのだろう・・・。
今後の方針。
>>99の形式のAPIで作りなおす。
Apache Winkライブラリ実装によるJAX-RX1.1環境でテスト。
JBoss(JBoss Rest Easy)・GlassFish(Jersy)・Apache CXFでそのまま動くと思う。 まあそういうなって。とりあえず動く段階までできたよ
最適化の余地があるのと、ファイルパスのミスなどに対して
親切にエラーメッセージを吐かなかったり、内部実装は雑だが、
とりあえず前回のチュートリアル4(繰り返し出力)までできるようになった
http://hoeppe.the-ninja.jp/java_markup_ruler/html/tutorial/tutorial4.html 出力結果とリソースとなるhtmlは>>130のチュートリアルと同一のもので、
今回のバージョンでは次のようなコードになる
package test;
import java.util.HashSet;
import java.util.Set;
import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;
@ApplicationPath("/rest")
public class HelloApplication extends Application {
public HelloApplication(){
}
@Override
public Set<Class<?>> getClasses() {
Set<Class<?>> set = new HashSet<Class<?>>();
set.add(HelloWorld.class);
return set;
}
} package test;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.ruler.markup.api.*;
@Source(file="/WEB-INF/html/tutorial4.html")
@Path("/hello")
public class HelloWorld extends Page {
@GET @Produces(MediaType.TEXT_HTML)
public String hello(){
String markup = super.draw();
return markup;
}
@Source
Group fragment = new Group();
@Source
Canvas list = (node) -> {
String[] names = {"A", "B", "C", "D", "E"};
for(int i=0; i<5; i++){
Node copy = new Node(fragment);
copy.in(node);
Node name = copy.key("name");
name.text(names[i]);
Node index = copy.key("index");
index.text("index("+i+")");
}
};
} HTMLでドキュメント書くのめんどくさい
今月末にEclipse4.4がリリースされる前には、こっちも仕上げたい ホームページに2.0のjar, javadoc、環境設定をアップしたぞ 何するフレームワークなの?
サイト見てみたけど、そもそもプロジェクトの大目的も書いて無ければ
設計思想も不明。誰に対して何を発信してるのかさっぱりわからん。
伝えるべき思想を失ったプロダクトは、やがて自身が失われていくだけ。 だからそういうのをhtmlで用意するのも手間がかかるんだって
見て分かる人は分かるし、分からない人は待つか、何か考えてちょうだい >待つか、何か考えて
いや、もうすでにメジャーな解決手段が山ほどあるわけで。
先入観も予備知識もなく、いちJava開発者としてあなたのプロジェクトの
サイトを見た時に、なにがしたいのか、なんのために情報発信しているのかが
さっぱり理解できなかっただけ。
このスレ見たって、だれもダウンロードもしてなけりゃ使ってもいなさそうだし。
個人的な趣味や研究としてやるぶんには全然いいと思うけど、だったら
2chじゃなくてそれこそQiitaなりForkwellなりGitHubあたりで発信したほうがいいと思う。 >個人的な趣味や研究としてやるぶんには全然いいと思うけど、
>QiitaなりForkwellなりGitHubあたりで発信したほうがいいと思う。
その辺くわしくないの。ツールの使い方覚えるのも面倒くさいしさ
スレ違いという話だったら、ここ俺が建てたところだし、他に話題もないようだからいいでしょ マ板が、2ch自体もすごく過疎ってるのは分かっている
それでも有用な案を出してくれる人が全くいないわけでもないんだよね >なにがしたいのか?
考えてみたら特にないんだよね。なんとなく作ってきたものを改めて自己定義してみる
自分はもともとwicketの信者で、プレーンなHTMLでデザインするというのが構想の根幹にあったのだけど、
新バージョン(2.0)では、方向性を変えてテンプレートエンジンに収まった感じかな
velocityとかsmartyと競合するわけなんだけど、違いは.vmファイルとか、独自スクリプトがないところ
2.0シリーズはテンプレートエンジンのみで他のフレームワークと組み合わせて使い、
1.0シリーズはオレオレコンテナー付きでたぶんパフォーマンスも少し良い チュートリアルを足した
あと2つ足したら、ショッピングカートとか
解説本によくあるサンプルアプリを作りたいところだ
他のtodoリストとしては、ver2.1において
wicket:removeやjsp:includeにあたるものがほしいかな
それと、htmlに埋め込む属性がjava:canvas="xxx"のように、
属性の名前空間が"java:"なんだけど、なんとなく"view:"に変えようと思う どうせ誰もダウンロードしてないしな
こっそり互換性のない変更しとくか プレーンなHTMLで書けるテンプレートエンジンは、Thymeleafってのが既にアルヨ
http://www.thymeleaf.org/ それは全く参考にならない
ホームページのデザインがカッコイイのは認めよう OGNL系のテンプレートエンジン、テンプレートにスクリプト埋め込むエンジンは根本的に失敗してるんだな Javaもc#のマネしてlinq機能採用すればいいのに
λも中途半端で使いづらい xml,json,csvあたりは必要としていないし、RDBには力不足、
KVSではよく分からんけどlinqは汎用ではなく何か専用にならないと使えない >>149
λとかQuery関係はjvmで動くLispのClojureとか使うと楽なんだけどそういうのは無しな方向なんだろうなぁと思うとちょっとかなしい 俺が一番ほしいのは右辺型推論の進化かな
jdk7で次のように書けるようになったけど
ArrayList<String> array = new ArrayList<>();
左辺と同一の型の場合、このくらい略せてもいいよね。
ArrayList<String> array = new();
ラムダができても以前のイベントリスナーみたいなのは今後もあるわけだし、
無名クラスが楽になるんだわ。
Listener listener = new(){
@Override void onA(Event e){}
@Override void onB(Event e){}
}; とりあえずJigsawの実用化に全力を出せばそれでいい 忘れてたけど先月にEclipseの新しいやつでてたね >>155
LunaからJDK8に対応したね
Streamはstream()オブジェクトを作ってからフィルタを通す感じで、最初に
オブジェクトを作る必要がある以外は正直LINQと同じだと思った
ただクエリ形式がなくメソッド形式のみという違いはあるが
ラムダ式で使う事を前提にしてるんだからそれでいいと思うけど
ジェネリック型(総称型)もC#が入れてからJDK5で入れたもんな JAVAでオンラインゲーム作れる?ブラウザゲームの >>155
前のやつでもJDK8プラグインあったけど
何かインテリセンスがちょこちょこバグって初期化させられたり酷かった
コレで安心 >>160
汎用的にはなんて呼ぶの?
Abbrebiation? >>161
自動補完でいいんじゃね?
Eclipse的にはコンテンツアシストだけど >>162
おお、日本語で考えること放棄してた、ありがと λ式勉強するのに良い本ある?
検索したらこんなのみつかったけど、どうかな?
Java8ではじめる「ラムダ式」
清水 美樹
http://www.amazon.co.jp/dp/4777518418/
Java 8 Lambdas: Pragmatic Functional Programming
http://www.amazon.co.jp/dp/B00J3B3J3C/ >>164
プログラムの根本からやるなら「計算論 計算可能性とラムダ計算 」とか「プログラム意味論」とかの方が良いよ。
jdk8のラムダ式を理解したいってだけだと後で困ると思う(jdkが消える未来とか嫌だけど) C++とかC#にもラムダ式あるけど言語毎に覚えれば済む話じゃん
学者になって言語そのものを開発したいわけでなければね 構文やらをおぼえるんじゃなくて
機能的な限界と回避方法・設計アプローチを把握することが重要なのは理解出来てるよな 内容のない掛け声だな。アーキテクト様()ですか?
標準APIや大手OSS、GoogleのAndroidフレームワークとかが示す設計に従うだけだろ
アプリケーション層なんて別に昔のやり方でも十分なのよ その「設計に従う」ってことができない奴が多くてな… 結局、ラムダを連発するようなものは何も思いつかなかったぜ 散々いわれてるかもしれないけど
ラムダ式、マルチスレッドの勉強するときに凄い便利だね
本文にスレッドの内容直接書いてる感じで
うさんくさいprivate class...{public void run()...って長ったらしく書く必要もないし (;´Д`)ノθヴイィィィン
javaもいいけどさ、Groovyどうよ。
ラムダ風も昔からサポートしてるし、
並列処理GParsも備える。
javaコードからの動的スクリプト対応強化されてるし、もっとgroovyユーザー増えてほしいわ。
なんか日本は食いつき悪いよねこの言語。 厳密さがJavaのいいとこなのに
それ取ったらただの使いにくい言語やん そうだな
Scalaも完全にオワコン化しているしな だってJavaで同じもの書けるんだもん。
「Javaのライブラリを呼び出せます!」っていかにも利点のように言うけど、
Javaを常に意識しながら、GroovyなりScalaの文法で書け、ってことじゃん。
すでにPythonやRubyの文法を知ってる人がJythonやJRuby使うのはわかるけど…。 floatの二次元配列を作ったけど、1次元目は行の管理用で、floatである必要ないんですが、
これってムダですかね?
でもArrayListだと値の再設定とか面倒だし・・・・ >>185
昔みたいに1バイト減らすのにあれこれする必要もなかろう
どーんといっとけ >>185
フロートって使う意味あるの?
ダブルじゃダメなん? 「Java EE以外の仕事に取り組むように指示が出た(中略)
Java EEチームへの資本投下がすでに終了している(中略)
収益的な意味があるという意見に加え、今後どちらにも転がる可能性がある(中略)
Java EEはエンタープライズ向けシステムなどで使われている」
Oracle、Java EEから手を引く可能性も | マイナビニュース
http://news.mynavi.jp/news/2016/07/04/261/ 「2016年7月に開催されるJavaOneにおいて詳細を公開する計画でいる。
Oracleが次期Java EEに関してどういった方向性を示すのかは今年の9月に公開」
Java EEは死んでいない、これからも進化する - Oracle | マイナビニュース
http://news.mynavi.jp/news/2016/07/11/145/ 「2017年7月には待望のJava SE 9がリリースされるほか、Java EE 8も年内にリリースを予定(中略)
Project Jigsaw、jshellなどの新機能が追加される。一番の目玉はやはりProject Jigsaw(中略)
不要なAPIを含めないことでランタイムの軽量化、セキュリティの向上(中略)
APIは、module-info.javaファイル内にrequires文で指定する。また、
exports文により自作のパッケージをどこまで公開するかを指定(中略)
jlinkコマンドを使えば、必要なAPIのみを含めたカスタムJREを作成することもできる(中略)
Javadocは、HTML5に対応する。また、ついに検索機能が導入される(中略)
複数のバージョンに対応するjarファイルを作成できる(中略)
one plus three backというポリシー(中略)
JDK 9では6、7、8、9までがコンパイル可能」
アプリ開発の新しい潮流に向けて進化するJava SE 9/Java EE 8の概要【デブサミ2017】 (1/2):CodeZine(コードジン)
http://codezine.jp/article/detail/10061
2017/04/07 14:00 Java SE 9 の次は Java SE X かね 「Jigsawの導入で開発者が気をつけるべきことは?(中略)
ライブラリへのアクセス制限が厳しくなる(中略)
リフレクションを使ってアクセスしようとした時、例外がthrowされる(中略)
最小限のモジュール・システムとして入れることになりました。そうして入れてしまえば、
機能を追加するのは後からできます(中略)
Jigsawにより大規模システムをより作りやすくなる(中略)
既存のクラスパスがほぼ使えなくなるので、初めは
クラスパスとモジュールの併用や使い分けが必要となり、そこでコンフリクトが起きる(中略)
現状はセントラル・リポジトリもない(中略)
モジュール関連の例外がthrowされたとしても、
それをハンドリングするためのオプションが用意されている」
「Java SE 9」がいよいよ7月リリース。櫻庭祐一氏と吉田真也氏に注目ポイント、移行時の留意点を聞いた
- builder by ZDNet Japan
https://builder.japan.zdnet.com/sp_oracle/35099496/?ref=rss
2017-04-12 16:40:00 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
L7LVQ ■ このスレッドは過去ログ倉庫に格納されています