At the end of July 2012, Groovy 2.0 was released with support for static type checking and some performance improvements through the use of JDK7 invokedynamic and type inference as a result of type information now available through static typing. I was interested in seeing some estimate as to how significant the performance improvements in Groovy 2.0 have turned out and how Groovy 2.0 would now co
public class Server extends VerticleBase { public Future<?> start() { return vertx.createHttpServer() .requestHandler(req -> req.response() .putHeader("content-type", "text/plain") .end("Hello from Vert.x!") ) .listen(8080); } } class Server : VerticleBase() { override fun start(): Future<*> { return vertx.createHttpServer() .requestHandler { req -> req.response() .putHeader("content-type", "text/
『好きなプログラミング言語選手権』選挙投票結果 | そこに100個くらいプログラミング言語があるじゃろ？
遅いですが、Java Developer Workshopに参加しましたので報告。セッションの資料がこちらで公開されています。 最初の、Nandini RamaniさんによるJavaFXを中心とした基調講演に続き、前半ではオラクルの寺田さん、佐藤さんから「Javaの今と今後」をコンパクトに整理された形で知ることができました。 基調講演でのJavaFXでのデモは、さりげなく(?)iPadやAndroid上でJavaFXを動かしていたのですが*1これって良く考えると(考えなくても)凄いことですよね。つまりJ2SEがiOSとAndroidで動いているわけです。Androidについては、Googleとの紛争を解決させて、ライセンス契約とかも調整してもらって、うまいこと普及して欲しいものです。JavaFXでモバイルデバイスとデスクトップで共通に動くアプリが作れるようになれば、画期的なことなじゃないで
こちらの@yusukeyさんの記事を参考にMac OSXにOpenJDK7をインストールしてGroovyを実行するところまで試してみたのでメモしておきます。 1.まずはOpenJDK7をダウンロード Mac OSX用のバイナリが以下から手に入るのでダウンロードしてきます。 http://code.google.com/p/openjdk-osx-build/downloads/list ひとまずこれを書いてる時点の最新バージョンである OpenJDK-OSX-1.7-universal-20110729.dmg をダウンロードしてきました。 2.インストール OpenJDK-OSX-1.7-universal-20110729.dmg をダブルクリック デュークをクリック 続ける（どんどん進む） インストール完了 3.インストール確認 open /Applications/Utilitie
There are less than 100 of them worldwide. They include some of the biggest names in Java: Neal Gafter, Brian Goetz, Gavin King, Rod Johnson, Doug Lea, and James Gosling. They are the Java Champions. Recently, he title of "Java Champion" was awarded to Andres Almiray—a major leader in the Groovy community who is also a regular contributor to DZone. For further reference, these are the requisite
近頃 Play framework という Web アプリケーションフレームワークにハマっておりまして、調べれば調べるほど「本物かもしれない」という想いが強まってきたので、今後、主に備忘の観点から play! に関するエントリをぽつぽつとポストしていきたいと思います。 play! とは 身も蓋もない言い方をすれば Java 版 Ruby on Rails です。概要はフランス訛りの英語がくすぐったい以下の動画をどうぞ。 本当に rails そっくりです。rails 以降のゴミフレームワークに騙され続けて来た経験から相当に疑り深く調査しているのですが、今のところ隙が見当たりません。 概要 とりあえず初回のエントリはオフィシャルトップに記載されている概要を眺めて終わりたいと思います。それぞれの特徴の詳細は後日ひとつひとつポストしていきます。 Fix the bug and hit reload
What is YouDebug? Here is the problem; your program fails at a customer's site with an exception, but you can't (or don't want to) reproduce the problem on your computer, because it's too time consuming. If only you could attach the debugger and collect a few information, you can rapidly proceed on fixing the problem. But running a debugger at a customer's site is practically impossible; if the us
バグ修正はプログラマの仕事の一つですが、このうちのかなりの時間は問題を再現することに費やされます。 症状からバグの全容が推察できる時もあるのですが、多くの場合には、手元で問題を再現し、更なるデータを集めることによって始めてバグが理解されるからです。しかし、環境に依存する問題などは再現が難しい場合もあります。どうしたらよいでしょうか。 ロギングというのがよく行われる解決・予防策ですが、「デバッガを走らせて変数xの値を教えてくれればいいのに！」と思った事があるのは私だけではないと思います。ロギングと異なり、デバッガは予めプログラムに障害発生を予期するコードを埋め込んでおく必要はありません。また、呼び出し元のローカル変数をアクセスしたり、任意の式を評価したり、あるいは変数の値を変更することもできてしまいます。当たり前ですが、障害分析ツールとしてはデバッガはずっと強力だからです。 ではなぜユーザー
Welcome to the wiki for the 2013 JVM Language Summit, taking place July 29-31, 2013, at the Oracle Santa Clara Campus. Links JVM Language Summit main page Email contacts: Brian Goetz and John Rose Archived wiki pages: 2008, 2009, 2010, 2011, 2012 Logistics page for travel tips and requests To gain write access, see instructions below. Self-registration In order to upload slides or create and edit
Almost to years ago I’ve invented and then wrote joint compiler for Groovy and Java. The idea was pretty simple – we do compilation in 3 steps 1) Generate Java stubs from Groovy sources 2) Compile all Java code with generated stubs 3) Compile Groovy code with already compiled Java classes First implementation was done as part of IntelliJ and later another one was written to contribute in Groovy co
とある事情があって、ＪＳＰのカスタムタグを調べたりしてたのですが、その複雑なことにはあきれました。歴史的経緯がらみの複雑なクラス継承関係から始まって、afterBodyだのBodyContextだのライフサイクルイベントだのエンプティアクションだのさまざまなリターン定数とそれに応じた動作、TLD(タグディスクリプタ)、それをさらにJarで固めて、難しい概念のオンパレード。誰が使うんだこんなの。 Grailsにも含まれるJSPのGroovy版「GSP」は、もうこっちはあほみたいに簡単です。 「HogeTagLib.groovy」のようにクラス名が接尾子「TagLib」で終わるGroovyファイルを指定ディレクトリ(grais-app/tablib配下)に置いておけば、そのプロパティとしてのクロージャがタグ名になります。基本的にそんだけです。 http://grails.org/doc/1.0
JSR 223: Scripting for the Java Platform 現在、Javaプラットフォームではスクリプト言語のサポートが急速に進められている。同時に、Java VM上で動作するさまざまなスクリプト言語の実装が登場しており、JavaプラットフォームはすでにJava言語という枠を飛び越え、マルチ言語環境に進化しようとしている。本連載第31回で紹介したBeanShellも、Javaベースのスクリプト言語のひとつだ。 今回取り上げるのは、そのようなさまざまなスクリプト言語とJavaを結びつける役割を果たす「JSR 223: Scripting for the Java Platform」だ。ご存知のように同APIはJava SE 6よりJavaの標準クラスライブラリとして統合されている。JSR 223ではJavaプログラム内で各種スクリプトを実行する、およびスクリプト側からJ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く