API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。Reinhold氏は、リリースを遅くするのではなく、早めるために、以前JDK7に計画されていた内のあるものは、JDK8まで延ばす、という提案した。この提案が、これはいい考えなのか悪い考えなのかについて、様々な議論を巻き起こした。以前発表された予定表(とにかく、最初から守れそうなものではなかった)がずれる原因となったJDKの遅れを受け入れているので、現在の議論は、現在サポートできているもので、その前にリリースすべきか、すべてが揃うまで待つべきかに、集中している。B」の見積りですが、2011年半ばに、削られたJDK7を、2012年の後半にJDK8をリリースできる見込みです。皮肉にも、氏のブログのタイトルは、「一刻の猶予もない!」であるが、投稿に寄せられたいくつものコメントが言うように、リリースが全く無いより、早く、頻繁にリリースがあったほうがよい。Bの部分は、Java言語にとって有益であることは、疑う余地がない。Phaser)を含む。別のJVMの改善が、JVMレベルであり、JSR292(invokedynamicのサポート)もそのうちである。アプリケーションで)には、最適化に使うことができる。リテラルに対する言語サポートを含んでいるのなら、適切に名前のついたメッセージを見つけるのに、リフレクションを使う必要がなくなり、Javaクラス内でメソッドを使うのが,ずっと簡単になる。クラスは、含まれるが、リテラルのサポートは,無いだろう)。JVM上に代替言語を実装している人たちは、提案された予定変更に興奮している。使えるのが、2012年まで遅れるより,早まるからである。(いずれにしても、ラムダ式などが2012年より早くなることはない。ハンドルは、恐らく、私の開発にとって、JDK7の中で最も重要な変更です。ハンドルは、確かに重要な部分になります。それを長い間リリースできないなら、JRubyのような言語を実装するには、泥んこの中をとぼとぼ歩き続けるしかない、ということです。PermGenスペースが爆発しないように、いつも鋭いコードを生成する戦略を作りながらやるわけです(あるいは、単に余りにたくさんメモリを食わないようにします)。ハンドルがリリースに入るのが,早ければ早いほど、いいのですが。これらは、確かにリリースされません。invokedynamicとの統合を短期間で「ちゃんと」できないなら、ちゃんとできるまで遅らせるべきです。言うのは、つらいですが、JVM上で、クロージャができる言語が他にあります。コードベースを見てください、我々は、それらを物凄く使っています)。Bから抜けてしまうフィーチャをScalaは,どうやって解決しているのか,どうか、私に説明願いたい。開発者以外には、クロージャは,役に立ちません。Jigsawのゴールに取り組むものは,皆無です。代替では、ありませんし、これからも、そうはならないでしょう。他の人達は、もっと早く、そしてリリース回数が、もっと頻繁にされるべきだ,と考えている。6は、長い間使われているが、バージョン付けスキーマが、その間のVM中の重要な変更を隠している。Sun/Oracleは、いつも隠し続けています。自分たちのTCKをちゃんと通しながら、できる限り多くの改善を施しているわけです。19(現在のところ、JDK7からの最新版)になっています。CompressedOopsのような他の項目、CMSの修正、たくさんの小さなVM/ランタイムの修正と改善が含まれています。ナンバーは、幾分任意なものです。スキーマを何回か変更しています。いつも世界の半数の人は、新しいスキーマを嫌います。ある人達は、6u10は、6.1と呼ばれるべきだ,と考えています。ようにバージョン番号を変えることになるでしょう。遅れることの別の利点は、慌ててやるよりも物事がちゃんとやられることである。Lambdaプロジェクトには、競合するゴールがあった。Javaライブラリ(例えば:ラムダ式を利用して、どうやって短い時間で、Collectionクラスを修正するのか)は、短い期間では、問題を起こすことになるだろう。Lambdaプロジェクトにもっと時間を与えれば、JDK7を止めること無しに、これらのことがJDK8と調和されるだろう。そればかりでなく、最新の提案では、完全にJavaでの関数型を排除している(以前,InfoQに載った)。要求がこれまであった。第一になぜそれらが除かれたかの理由が、はっきりしないので(型システムの問題なのか、時間が足りないのか)、それらが再び蘇るのかどうかも、はっきりしない。Jigsawについても同じことが言える。システムの標準であるのに,JigsawがJava言語ライブラリを分割する方法として、車輪の再発明をしようとしている。ライブラリは、本当に2つの違う目的を実行するものである。誰にとっても、大きな利益をもたらすものである。ライブラリの組合せの特別なリリースに依存することがないようになる。大きくなるということは、より内部的な依存性が増すことを意味し、このような依存関係は、すぐにプラットフォームを複雑にするものである。ロープを持てば持つほど、絡み合いやすくなるのです。繰り返しスケジュールがズレるのが,その徴候の一つです。モジュール化は、我々がケーキを持ち,食べることができる唯一のメカニズムです。プラットフォームからできていたら、JSRの実装を別のモジュールとして、簡単に含むことができたでしょう。使いません、じゃあ、なぜ私のプラットフォームにそれが入っているのですか?そして,もしそれを私が使うなら、別バージョンのものが必要です。JSRをモジュール化するのは、小さなアプリケーションのライフを恐らく,複雑にするでしょう。本格的なアプリケーションにとって、外部依存性を処理することは、すでに複雑なライフの一部になっています。これらの依存性を扱うことを全くサポートしないためです。プラットフォームです。定義されたコアパッケージ、と私のデスクトップマシンとサーバにライブラリやアプリケーションを追加するのが、簡単にできる(リモートの)レポジトリから、モジュールを適切に処理できる、メカニズムだけを持っているべきです。