[mustang] 次世代Javaの動向 3 [dolphin]

前スレ
次世代Javaの動向　２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/

前々スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/

2006年秋にMustang Java SE 6がリリース予定
（現在ベータ２）

Mustangで追加される主なパッケージ（β2より）
java.text.spi
java.util.spi

追加される主なクラス
[java.awt]
Component.BaselineResizeBehavior
Desktop.Action
Desktop
Dialog.ModalExclusionType
Dialog.ModalityType
SplashScreen
SystemTray
TrayIcon.MessageType
TrayIcon

[java.awt.font]
LayoutPath

[java.io]
Console
IOError

[java.lang.instrument]
ClassLoaderConfigurationError

[java.lang.management]
LockInfo
MonitorInfo

以下続く

[java.net]
CookieManager
CookiePolicy
CookieStore
HttpCookie
IDN
InterfaceAddress

[java.security]
Policy.Parameters
PolicySpi
URIParameter

[java.text]
Normalizer.Form
Normalizer

[java.util]
AbstractMap.SimpleEntry
AbstractMap.SimpleImmutableEntry
ArrayDeque
Deque
NavigableMap
NavigableSet
ResourceBundle.Control
Service
ServiceConfigurationError

続く

[java.util.concurrent]
BlockingDeque
ConcurrentNavigableMap
ConcurrentSkipListMap
ConcurrentSkipListSet
LinkedBlockingDeque
RunnableFuture
RunnableScheduledFuture

[java.util.concurrent.locks]
AbstractOwnableSynchronizer
AbstractQueuedLongSynchronizer.ConditionObject
AbstractQueuedLongSynchronizer

[javax.net.ssl]
SSLParameters

[javax.security.auth.login ]
Configuration.Parameters
ConfigurationSpi

続く

[javax.swing ]
DefaultRowSorter.ModelWrapper
DefaultRowSorter
DropMode
JList.DropLocation
JTable.DropLocation
JTree.DropLocation
LayoutStyle.ComponentPlacement
LayoutStyle
RowFilter.ComparisonType
RowFilter.Entry
RowFilter
RowSorter.SortKey
RowSorter
SortOrder
SwingWorker.StateValue
SwingWorker
TransferHandler.DropLocation
TransferHandler.TransferInfo

[javax.swing.event ]
RowSorterEvent.Type
RowSorterEvent
RowSorterListener

[javax.swing.table]
TableRowSorter
TableStringConverter

[javax.swing.text ]
JTextComponent.DropLocation

以上新しいクラスでした

MustangとかDolphinとかの呼称は廃止されただろ>>1
おそらくSunの連中もどっちが6だか7だか間違うんだよ

>>2
spiってなんすか？就職試験ですか？

>>3
クッキー機能が強化されるのか

>>7
廃止された？　ソースは？

既存クラスへの追加：

String にメソッド.isEmpty()が追加。

java.io.Fileは大幅に変更。toURLはdeprecatedになった
chmod系のメソッドとディスクスペース系のメソッドが多数追加されてるね

>>11
isEmpty()か
今まで
str.equals("")を使って他のを
かわりにそれで済ませることができるって意味？

それとも
str.equals("")
だけでなく
str.equals(" ")
や
str.equals("　　　　　　　　　　　　　　　") //(一応半角文字のつもり)
も含まれる？

>>11
dfやduコマンドが使えるって化

>>11
mkdir()のかわりmkdirs()で
mkdir -p /usr/local/a/b/g/a/a/a/a/a/a

っていう長い複数にネストされたディレクトリも一発で
確実に作れるのかな？

>>11
chmodのファイルシステムに依存する部分の分離とか、どうやっているのか凄く興味深いぞ

JDBCもバージョンが上がって大きくプログラミング方法が変わる模様

Design and performance improvements with JDBC 4.0
http://www.javaworld.com/javaworld/jw-05-2006/jw-0501-jdbc.html

>>12
"".equals(str);
と書くだろ。

isEmptyはstring長がゼロのときにtrue、よって最初のやつだけに使えるね。
後は" ".trim().isEmpty();
とかすればよいでしょ。

JDBCは結局ドライバー待ちだしなぁ

>>13
getFreeSpace, getTotalSpace, getUsableSpace

が使えます。

>>10
http://journal.mycom.co.jp/news/2006/08/16/343.html

あれ、snapshotのjavadoc見ると結構違う。。。
あとでまとめてみよ

>>2に追加してJDK 6 新パッケージ（rc-b98より）

javax.activation - activation framework
javax.annotation - 新しいannotation
javax.annotation.processing - apt？
javax.jws - web 用のannotation?
javax.jws.soap - soap用のannotation
javax.lang.model (subpackageは省略)　よくわからん
javax.script - 文字通り
javax.tools - compilerとか
javax.xml.bind　(subpackageは省略) - JAXB
javax.xml.crypto　(subpackageは省略) - XML signature
javax.xml.soap - 文字通り
javax.xml.stream　(subpackage 省略)　stax?
javax.xml.transform.stax - 文字とおり
javax.xml.ws　(subpackage 省略) - JAX-WS

>>15
大した事はしてない。
例えば setExecutable も setReadable も、
Windows だと NTFS でも FAT でも何もしないはず。

戻り値の仕様は…… なんだこりゃ？ って感じはするけど。
っつか、new File("no such file").setExecutable(true); は
IOException 吐いて死んで欲しいよーな気がするが。

>>17
> >>12
> "".equals(str);
> と書くだろ。

それは個人の書き方の問題では？
どっちみち、isEmpty()がでるならそれすらも気にしなくて済むなら、
ええもんだよね。

>>20
JDKという名前はまだ残ってるのか
もうすでに、Java SE 6, Java SE 7と呼ぶのかと思ったぞ

>>22
JAFがJavaに標準で組み込まれるようになったのか？

これで、Java Mail APIを使うときに
いちいちactivation.jarを入れる手間を省けるのか

>>24
リテラルを前に持ってきた方がイーンダヨ。

>>24
strがnullの場合の話。

>>28
nullである可能性がある場合の話、だな。
比較が一回で済むという。

前スレだけど
>>970
>ストラウとラップは演算子のオーバーロードを
>誤った使い方をするとろくなことがないぞってことを言ってるんだよ。

その誤った使い方を具体的に示してよ。C++よく知らんし。
それとも偉い人がそういったから否定しているだけ？もしそうなら議論やめるよ。

>>28
なるほど

>>30
どっかに書いてなかった？
偉い人が言ったからではなく、
副作用ってことで。
複数の会社で演算子の定義が異なると
ソフトウェアを統合したときに衝突が起きるって奴

複数の会社でなくても、複数の人間が書いた場合にも起こるな。
そもそも規約がしっかりしてりゃ、こんな事にはならんのだが。

規約だけじゃまもりきれんよ。
妄信してるバカには。
だから、人間ではなく言語によって統制できるのはかなりいいことだ。

>>30

お前と俺が同じプロジェクトに入っていたとして、
俺があるクラスAhoで+=をオーバーライドするとする。

public void += Object obj{
this.何かのフィールド.何かのメソッド(obj);
}

これが書いているときは非常に便利だとすると俺はこれを多用したコードを書く。

{
Aho aho = new Aho();
aho+=(3);
aho+=(4);
int baka = 0;
baka += aho.getId();
}

こんなコードのメンテやだろ。同じ+=でも複数の意味を持っているのはやはり読みにくい。

>>29
それがいいとは限らないと思うんだけどなあ
確かに"".equals(strl)でstrがnullのときにfalseを返すことはAPI仕様で保証されてるけど
(正確にはObject#equalsの引数がnullのときにfalseを返すこと)
strがnullであるのが想定外である場合にNullPointerExceptionを握りつぶしてしまうという
危険性がある

>>35 なんか言いたい事がわかった気がする。
1つのクラスでは便利でも、他のクラスと相対的に見てみると、
両者で同じ演算子をつかっても、その意味（効果)が違うとメンテは大変だしね。

>>36
どこか他でNPE投げるからいいんじゃない？
どこかでstr使うんでしょ？

null を確認するために使うメソッドでもないしさ。

>>36がどういう状況を想定しているのか分からないが、そんなときはisEmptyが活用できるわけだ。
読みやすいといえば、読みやすいか。

>>38
strはその後使われるとは限らない
単にチェックのためだけに使われる場合もある

> null を確認するために使うメソッドでもないしさ。

nullチェックと文字列の比較を同時に行うためのイディオムとして"".equals(str)
を使うのは問題だという話なのだが。つまり、
if(str != null || str.equals("")){
　doSomething();
}
の代わりに
if("".equals(str)){
　doSomething();
}
で済ませちゃうという状況を想定している

>>39
いい加減に見苦しいな
ただ分ければいいだけだろうが

>>39
てか次世代スレでそんなバグだらけのコード書いてはずかしくない？

>>39
自分を擁護するためにコードでっち上げました、って感じがする

こういうのって、普通スルーでしょ？

>>39
かわいそうに。でも　if(str != null || str.equals(""))　って意味があるか考えたほうがいい。

ぜんぜん関係ないが、top 25 のRFEで"struct" のサポートというのがあるが、
c#とかで見た事あるけど、詳しい人4行くらいで解説してほしいな。Javaとの相性を含めて。

C++のclassとstructの違いは、デフォルトの可視性のみ。
C#のstructはスタック領域に確保される、値型となり、
classはヒープ領域に確保される参照型になる。
簡単にはこんなもの

String action = request.getParameter("action");

if("edit".equals(action)) {
　　　　doEditAction();
}

昔サーブレットを利用したＷＥＢアプリ開発を行っている時、
このようなコード書いたものなんだが。。。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4648386

このRFE, Jarに別のJarを含めてもちゃんと動くようにってヤツだけど、これはdolphinでやってもらいたいな。

たまにlog4jをバラして自分のjarに組み込んだりしてるので、

>>44
top 25 のRFEで"struct" のサポートの内容は何を指しているのか知らないが、
以下、思ったことを適当に述べてみる。

structの利点：スタックに必ず割り付けられることが保障される。
structの欠点：継承できない。

エスケープ解析の導入で
オブジェクトをスタックに割り付けてもらえるようになったため、
structを使う利点は消えた。
従って、C++やC#で言うところのstructは不要。

>>46
それは問題ない。
>>39は両方バグありであまりにひどすぎ。

>>48
だから、C++のstructはC#のstructとは全く別物だってば。
C#のstructはC++では、
class Hoge {};
struct Piyo {};
Hoge hoge;
Piyo piyo;
こんな感じで、C#のclassはC++では
class Hoge {};
struct Piyo {};
Hoge* hoge = new Hoge;
Piyo* piyo = new Piyo;
こんな感じ。

RFEではCのStructのことを指している様子。

言語仕様にするかは別として、IO速くなるならとっとと組こんでもらいたいもんだ。

>>44
そこの Evaluation に
> @Struct interface CK_SLOT_INFO {
> 　@PaddedString(' ', "utf8", 64) String getSlotDescription();
> 　@PaddedString(' ', "utf8", 32) String getManufacturerID();
> 　@Unsigned(32) int getFlags();
> 　CK_VERSION getHardwareVersion();
> 　CK_VERSION getFirmwareVersion();
> }
みたいな 例示コードが載ってるよん。
内部的には java.nio.Buffer 使うとか？

スタックに割り付けられるオブジェクトが欲しいとか、
値型が欲しいとかなら別の RFE に vote しろって書いてあるね。

この RFE のスタンスが良くわからん。
struct 書いて、fread で読み込めれば便利、
（エンディアンやらエンコーディングを考慮しなければ）
ってのを実現するとかみたいなスタンスなんかな？

structは型（値型)の定義・宣言でしょ。
確保した変数がスタックフレームと一緒に消滅してくれるとかは、
Cで滅多に使わないけどキーワード auto のことでしょ？
一緒にしてないかな。

>>53
Sun の人は、そーゆー struct を議論するつもりはないみたいね。件の RFE では。
4820062 に vote した連中がどーゆーつもりかは知らんが。

> structは型（値型)の定義・宣言でしょ。
そーゆーのは 4213096 とかでやれって事らしい。

今度はstruct?
またC#からパクるんですか

>>55
完成度はJavaのほうが上になるから、安心しろw

>>49
doSomething() の仕様を確認せずにバグありというお前の姿勢はあまりにもひどすぎ。

>>57
ちゃんとコード読んでみたほうがいいよ。書いた本人の意図と条件式の内容
が食い違ってる。

struct言語仕様に導入する必要ないじゃん。
もっと賢い仕組みになるわけだし。

エスケープ解析の具体的なやり方解説ｷﾎﾞｰﾝ。

>>50
正直、完全に忘れていた。
struct は 後方互換性のためだけにC++に残された無用のキーワードだったなorz

>>52
構造体を値渡しする時に、どのメンバがどのビットに対応しているか記述するものだな。

確かに、その機能があればネットワークプログラミングで
パケット内容をパースする時に非常に便利。

struct packet* p = (struct packet*)buf;
printf("%d, %d", p->id, p->tick);

上のコードのように、単なるビット列に構造体でキャストして
ビットに意味づけをするようなコードを簡単に記述可能にしたいのだろう。

39だが、すまん。&&なのを||で書いてた。すぐに気づかんかったのは
確かにアホだった。反省している

>>61
俺に恥を書かせるお前の態度はあまりにも酷すぎ（泣

>>62
すまんかった。マジでうっかりしてた
馬鹿にされても仕方無いくらいアホなミスだ

>>44
structか。下手に使うと重たくなるって@ITのC#の記事に書いてあったが、
どうなんだ？

値型扱いじゃあないってことか？

>>47
FatJarやOneJarの立場がなくなるっていうのか？

>>52
なんだ、アノテーションでinterfaceを縛り付けるだけか。
よかったよかった。C#のstructみたいなわけわかんないのでなくて

>>52
インタフェースだけじゃどうにもならん気がするが支援APIは？

>>65
便利そうだねfatjarとかって。
どっちかっていうとオプソのライブラリーとかで使って欲しいんだけどね。

あれを落として、これを落としてって大した手間じゃないけど精神的にうざい

maven使えば楽なんだろうけど

>>68
EclipseにFatJarプラグインがあるぞ。
あれは楽。

Mavenにもプラグインがあったような気がする。
俺の場合は、Mavenでプロジェクト作ってライブラリ落として
Eclipseに反映させてプログラムができあがったら
Eclipse側でサクッとFatJarプラグインでまとめちゃうけどね。

>>67
知らん。追加情報募集中って感じかね。あるなら、だけど。
>>52 は単に Evaluation に書いてあることをひっぱってきただけだし。
Dolphin に入れるか検討中とも書いてあるから、暫く待ってれば情報が出てくるかも。

支援API に関して良いアイデアがあるんなら件の RFE にコメントするなりしてみれば？

>>67
http://javolution.org/api/javolution/io/Struct.html を参考にするとかしないとか。
>>52 とは結構違うような気もするけど。

>>70
インタフェースでやるのは愚の骨頂だと思うな
インタフェースで宣言したメソッドの順番には何の強制力もない
structてのはstructureなわけだから構造を強制できないと意味がない
だから必要なら新文法の導入も止むなしかと思うね

JSR 305: Annotations for Software Defect Detection
がJSR Reviewに登場。

@NonNullとか@NIsとかについての仕様

annotation関係多いね。個人的にはいい方向だと思うが

>>69
オレのよう無知な人間がいっぱいいるからな。
標準化の意味もあると思うよ。

逆にfatjar使うデメリットってあんだろうか？
Tomcatで使うぶんには問題ないが、普通のクラスローダーだったら色々問題がでそうな気がするが。。。

JavolutionはJava側でＳtructにセットした値が、DirectBufferとして
確保されたメモリ領域にきちんとアライメントも合わせてセットされるので、
JNI側でそのままメモリ領域を構造体としてネイティブライブラリに
渡せる。
JNI書いてる時は重宝する。

>>72
> インタフェースで宣言したメソッドの順番には何の強制力もない
それは class でやっても全く同じ事だと思うけど、
Javolution では、それでやってるわけだし。

>>71
概念的にインスタンス変数の定義順ってどうなのってのはあるけどな
struct予約語を導入してラップすれば問題ないか

>>76
違うんじゃないか
インタフェースはメソッドだけどクラスはインスタンス変数だろ
ただクラスでも定義順にそこまでの思想的強制力があるのかっていう
一種の気持ち悪さはあるな
struct予約語の導入がすっきりすると思うけど

>>77
たぶん >>52 方面では予約語は追加されんと思うぞ。

Category が java:classes_nio になってるし。

>>79
nioとして検討されてるのか
確かになさそうだね

>>78
> struct予約語の導入がすっきりすると思うけど
そーゆー意見は Sun の連中に聞こえる場所で言った方が良いと思うぞ。

このスレに居る連中に言ったところで何が変わるわけでも無し。

主張を正確に伝えるまでの英語力ないしな
まあ誰か同じようなこと考えるだろ

>>35
+=演算子が、適切にオーバーライドされているなら、その例でなんの問題もないと思うけどな。
例えば集合を表すSetというクラスがあって、
Set set1 = new Set();
Set set2 = new Set();
set1 += set2; // 和集合
と書けるのはとっても自然だと思う。

>同じ+=でも複数の意味を持っているのはやはり読みにくい。
読みにくいのは、スクリプト言語のように型がない言語の場合だけじゃないか？
C++やJavaのように型がある言語なら、演算子がオーバーライドされていても問題なく理解できる。

>>83ちゃんと仕事してる？

>>74
いまのところFatJarのデメリットはなさそう。

と、思ったが、固めるのに時間がかかるというデメリットがあった。
Jakarta Commonsのライブラリ使いまくっていると凄いことになる。
10以上もあるファイルを全部解凍してから圧縮し直すから。
1GHz、メモリ512MBのマシンでも1分くらいかかった。
圧縮されているCommonsのJarファイルのそれぞれのサイズにもよるけど。
テストするのに手間がかかるというオチがある。

Tomcatで、Jarにしたままでちゃんと動くかテストしろと上司が五月蠅いから。
さもなきゃclassのままにして、WEB-INF/classesにServletと一緒に放り込めだからな。
バカ上司と付き合うのはやってられないと思った。もうそこの会社は辞めたが。

>>77
漏れは予約語にするんだったら>>52のサンプルコードのように
@Structアノテーション
だけで解決して欲しい派

C/C++/C#のstructと一緒だ！と勘違いする奴がいるから。

>>83
コンパイラは理解できるだろうよ
じゃあ、結構大きめなクラスライブラリが有った場合とかドウスンノ？って事
全て一人で出来る程度の仕事してる連中には理解できない世界ってのが有るんだよ

jar にせずに WEB-INF/classes に置いた方が起動が早い場合が多々ある。

>>83
まだ伝わってないようだな。
別に演算子オーバーロードすべてを否定しているわけじゃない。
現行のjavaだってStringで使ってるわけだし。
ユーザーが定義できるってのが嫌。

Collectionsの+=はあまり誤解がなさそうなので良いと思うが、
それよりはnew ArrayList<String>(String... strs)の方が欲しいな。

>>85
なるほど。さんきゅ。
全部バラしてんだったら確かに重い処理だわな。

>>88
そうかもね。

ちょっとそれるが、何でjavaはバイナリーファイルがクラス単位なんだろうか。
inner classでも自動的に新しいバイナリーファイルが作られるじゃん。
すごい無駄だと昔から思ってんだけど。

同じパッケージに属するクラスで良いので、
１つのファイルに複数のpublicクラスを記述できるようにしてほしい。

クラスファイルレベルでは、互換性の問題も発生しないだろうし

>>90そう考え始めるのは、Javaに向いてなかったと言う事でしょう

>>91
static inner classで良くない？
バイナリーは結局いっぱいできて汚いけど。

>>92
そうなん？C#に移行するか。。。
inner class の$が入ったバイナリーは明らかに不必要かと思うんだけど。

>>94
各言語で、それぞれに目指しているところが微妙に違うのでしょう。
やっぱりC#に移行してもMS案件・Windows用で特定用途向けのツールばっかりになってしまうのでしょう。

>>90
俺は逆に一つのファイルに複数のクラスを書くのが昔から許せなくて、
もうJava以外の言語にはあんまり戻りたくない。
「あのクラスはどのファイルの中で定義してあった？」
なんて探し回るのは不毛だ。

>>96

ソースじゃなくてバイナリーの事をいってんだよ。
.classのほうね。.javaに対して.classがいっぱいできるじゃん。

>>90
そりゃあんた、Javaはクラス単位でプログラムのロードをするからでしょ。
内部クラスがあったって、もし実行時に使用されないなら、ロードしない。
そのためにファイルが別れてる。

ところでFatJarって全Jarを展開して一つにまとめるんだったら、
実行ファイル用jarとして、warみたいに複数のjarをjarファイルに
格納する標準フォーマットを決めればいいだけなんじゃないかと
思うんだが。

確かFatJarって展開して1つにまとめるものと違った気がするんだが…。
バイナリに手を加えるのがライセンスで禁止されてるものとかもあるから、
クラスローダーに手を入れてあるってどこかで読んだ気がするんだが。

まぁ、勘違いかもしれんから気になる奴は自分で調べてくれ。

>>98

別にファイル分かれてる必要ないじゃん。
ファイルの中で必要な部分だけロードできる仕組みがあればよいだけ

jarだってファイルは一つだぜ、中を見て必要なクラスをロードしてるんだろ

>>99

そもそも議論の発端は　>>47　だ
これね　
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4648386

>>100

それone-jarってやつじゃない？

6.0の一般公開ﾏﾀﾞｰ(ry

b99まだー？
bいくつまで行くんだろ？

>>83
おい、オーバーライドか？　オーバーロードの間違いだろう。

演算子のオーバーロードだけはやめとけ。
どうしても使いたければ、外部のXML言語やJakarta Velocityなどで
サポートする形のほうが安全だぞ。

>>88
初回起動だけとか、だったりしたらねえ。

つか、Servletの場合は、WARが主流なんだけどね。
WARを置くと勝手に回答されてそのなかにJARが
入ってはいるけれども。
Appletに直接使わせる場合は、JARのほうが速いしねえ。

そもそも、速くなるケースがある、といっても実用性を
考えるとそういうのはあてにならんよ。

>>91
そんなちっちゃな要求、メリットを感じないな。

そういうちっちゃな夢はC#でも使ってなさいって感じなんだが。

>>96
そうそう、
オブジェクト指向設計の原則　「分割統治せよ」
ってのがあるからね。

詳しくは『アジャイルソフトウェア開発の奥義』
にて

>>97
classが沢山できてもJarで固めればいいさ。

>>103
OneJarはFatJarから派生したやつではないかな？

>>109
その本は見てないけど、別にファイルとクラスの問題じゃないだろ。
IDE使ってればそんな事はどうーでもいい。

むしろ新しい事を始めるときはstatic inner classを好んで使うよ。
ソースを書く時点でファイルを意識しなければならないのは苦痛だよ。
そんなのオブジェクト指向とは何も関係ない。

>>112
IDEつかってもどうでもよかないよ。

そもそもIDEが壊れたときどうするんだと。
セットアップにも時間がかかるし。

スルー？

>>112
インナークラスから始めるという発想が
どうもみすぼらしい。

ファイルを意識だって？　それこそIDEをつかっていれば
意識しなくて済むだろう。
Eclipseのように新しいクラスを作りたければ、
[新規]-[クラス]で自動的にファイルができてclass宣言も
記述されるので有れば苦痛でないだろう。分割もリファクタリングで済む。
にもかかわらずいちいちpartialを使う？
それこそそんなことはどうーでもいい。

お前はおそらくpackageの仕様をC#のnamespaceの
ように変えて欲しいというクチだろ。

AspectJでどにか済ませろ。

>>115
staticのinner classは便利だ。
eclipseの糞うざいウィザードがないからね。
三つ四つさくさくクラスを作れる。
やっぱいらないかー、とか思ったらコメントアウト。
やっぱ必要だ、とか思ったらコメントをはずせば復活。
めちゃ楽。

C#は知らない。
partial? 何を指してんだ？

クラスごとにファイルをわけた場合のデメリットは
複数のソースを比較しながらコードを書くのがめんどくさい
という点につきる気がする。

116 のいう
> eclipseの糞うざいウィザードがないからね。
はウィザードが立ち上がらない設定にすればいいからどうでもいいとして
emacs みたいにいくつものペインに分割して
それぞれのソースが表示できればいいんでない？
Eclipse プラグインにあったかは知らないが 。

>複数のソースを比較しながらコードを書く
どんな状況だ？

＞ウィザードが立ち上がらない設定にすればいい
そうしたらクラスを簡単に作成、変更できるのかい？
簡易なプロトタイプ的なモノを書きたいとき、って状況だぜ。

以下のような感じで、めっちゃ楽。
プロトタイプだからInterfaceでの定義もよく変わる、一つのファイルだからメニューからリファクター、とか選ばずとも手で素早く修正できる。
仕様に耐えられそうだったら、一人前のクラスとしてリファクターすればよい。
こんなんでいちいち新しいクラスを箇々に作るのは時間のむだ。

public class Base{

static interface IntA{//省略
}

public static class TestA implements IntA{
//省略
}

public static class TestB{
／／省略
}
}

>emacs みたいにいくつものペインに分割して
>それぞれのソースが表示できればいいんでない？
eclipse使った事ある？フリーだよ。

>>118
> >複数のソースを比較しながらコードを書く
> どんな状況だ？

比較というか複数のソースを横断的に(タブ切り替えでなく同時に見ながら)
コードを書きたいことは普通にあるだろ。
そういう状況がないというのであればそっちの方が信じられない。

>>120
お前こそ emacs 使ったことあるのか？

>>121
SQLのスキーマとかクラスダイアグラムだったら分かる。Javadocもあるだろう。
ソースを見ながら？どんなコード書いてるんだ？


emacsは使わないが、eclipseので複数のペインで表示させるのと大きく違うのかよ？

あれJavaの人だよね？いまさらCの話でしたー、とか勘弁してよ

>>121
もしかしてEclipseでJavaエディタの部分を上下2分割できるの知らないの？
試しにソースのタグをエディタ内でドラッグさせてごらん

>>106
オーバーロードじゃなくて、オーバーライドであってるよね。
と思ったけど、型がある言語ならオーバーロードもできるのか。
>演算子のオーバーロードだけはやめとけ。
>どうしても使いたければ、外部のXML言語やJakarta Velocityなどで
>サポートする形のほうが安全だぞ。
このへん意味不明

>>87
>じゃあ、結構大きめなクラスライブラリが有った場合とかドウスンノ？って事
大きかろうが別に関係ないよ。演算子の定義もメソッドの定義も別にかわらないから。
add(arg)のかわりに+(arg)を、sub(arg)のかわりに-(arg)を定義して、
obj1.add(obj2)のかわりにobj1+obj2を使うだけ。
これで「混乱する」とか「わかりにくい」とかいうやつは、演算子でなくてメソッドを使っても同じだろ。

もしかして、intやcharの演算子も再定義することを考えているのかなあ。それは禁止すべきだけど。primitive typeにはメソッドが定義できないのと同じように。

>>89
>ユーザーが定義できるってのが嫌。
だから、なぜ？「混乱するから」という理由なら、上に書いたように、混乱はしないから。

>>88
> jar にせずに WEB-INF/classes に置いた方が起動が早い場合が多々ある。

クラスローダーがclassファイル探すためのI/Oの回数がJARだと1回、バラだと
classファイルの数だけ発生するはずだが。
起動時に全部ロードするわけではないから早く感じるのかもしれんが、トータルで考えると
JARの方が早いんじゃね？

>>126
んなわけない
バラだって1回で探せる
なんのためにパッケージ名があるか考えよう
Jarは展開ロスもあるしその分遅いだろ

>>125
> オーバーロードじゃなくて、オーバーライドであってるよね。
普通は operator overload、演算子の多重定義だな。
演算子の上書きって言われると、primitive型の演算子が再定義できるようになりそうな……

>>125
演算子オーバーロードが欲しいなら Bug ID: 4905919 に vote よろしく。

>>125
> >>87
> >じゃあ、結構大きめなクラスライブラリが有った場合とかドウスンノ？って事
> 大きかろうが別に関係ないよ。演算子の定義もメソッドの定義も別にかわらないから。
> add(arg)のかわりに+(arg)を、sub(arg)のかわりに-(arg)を定義して、
> obj1.add(obj2)のかわりにobj1+obj2を使うだけ。
> これで「混乱する」とか「わかりにくい」とかいうやつは、演算子でなくてメソッドを使っても同じだろ。

いや、一見それだけなら問題なさそうに見えるが、それをBigDecimal, BigIntegerで定義すると、

> もしかして、intやcharの演算子も再定義することを考えているのかなあ。

のように欲張る奴が出てくる。さらに、Numberクラスを継承したらどんなクラスであっても
演算子を再定義できるようにすべきだと主張する輩も出てくる。
中途半端に制限するのはおかしいと言いだしてな。
そして四則演算関係だけじゃ足りないとか言いだしてくるぞ。
MathContextコンストラクタの引数に指定するprecisionも演算子で設定できるようにすべきだと
言いだす奴がでてくるかもしれない。

するととたんにC++やC#の二の舞となるわけだ。

あとはストラウストラップが指摘した問題だな。

>>127
初回だけ展開して
２回目以降は展開しないという仕組みには
なってないのかね？

演算子オーバーロードは、技術的には>>125が言っているように本質的にはメソッド呼び出しと変わらない
問題なのは、+,-などの演算子は通常のメソッドに比べてより強い制約を満たすことが期待されているにも関わらず
(例えば、+なら可換であるとか)、その制約を満たさないような形で演算子をオーバーロードする奴がC++で多発したこと。
要は「メソッド名(演算子名)はそれが行うことを表す名前をつけましょう」というだけのお話。
演算子オーバーロードそれ自体が悪いわけじゃなく、演算子オーバーロードの正しい使い方についてあまり啓蒙されなかった
のが真の原因

http://d.hatena.ne.jp/mb2sync/searchdiary?word=%2a%5bBoost%2eXpressive%5d
C++ の spirit フレームワークや、正規表現の Xpressive ライブラリなんかは極端としても

「 y = x.add( a );」

という書式があったときに、 add メソッドが、+= の役割なのか、+ の役割を示すのか
一瞬迷うことがあるから、限定された演算子オーバーロードでいいのであって欲しいとは思う。

便利でもないのに、見た目だけ追求しているように聞こえるけど、
そんなに欲しいのかね・・・・
その熱意が伝わってないじゃないか？

>>133
その+が+=の様に実装するデコ助と仕事する羽目になったらどうする？

>>135
それはいくらなんでも論外
そんなことする奴は、普通のメソッドであっても変な名前をつけて足引っ張るだけだろう
一応言っておくと、俺は演算子オーバーロードについてはあってもいいけど
別にそれほど切実に欲しいというわけじゃない派

>>116
partialはまさに、おまいが求めている長〜いひとつのクラスを
複数のファイルに分割する機能だ。
partialキーワードを使ってどうにかするって記憶がある。

おれはJavaソースファイルにあるクラス宣言の分割よりも
>>124のようにEclipseを使って
一つのJavaソースファイルで複数のエディタを分割起動
できるほうがいい。

>>89
> Collectionsの+=はあまり誤解がなさそうなので良いと思うが、
> それよりはnew ArrayList<String>(String... strs)の方が欲しいな。

とりあえず、asList()で解決だ。
つかね、そういうの作りたければArrayListを継承すればいいんじゃないか？

>>89
> Collectionsの+=はあまり誤解がなさそうなので良いと思うが、

CollectionsクラスじゃなくてCollectionインタフェースだろ。
ってつっこみはいいとして

これはどうもね。
不変クラスであるStringの+=が好まれていない件を思い出す。
可変クラスのメソッドStringBuilder#append(String)のほうが高速だし。
そういう実装になったら本末転倒。
まさか、と現存のMutable(可変)なCollectionに加えて
Immutable(不変)なCollectionをつくるわけじゃあるまい。

そもそも、MutableなCollectionに対して

str = str.concat("追加文字列"); // str += "追加文字列"とほぼ同義だが(ry
なんてするの馬鹿馬鹿しい。
sb.append("追加文字列");
のほうがいいし、

この二つのメソッドを演算子オーバーロードした場合、どう区別つけるんだ？

>>103
だから、OneJarはFatJarから派生した。
しかし、あれライセンスが面倒だった気がする。
だから漏れはFatJarを使ってる。

>>117
> > eclipseの糞うざいウィザードがないからね。
> はウィザードが立ち上がらない設定にすればいいからどうでもいいとして
> emacs みたいにいくつものペインに分割して
> それぞれのソースが表示できればいいんでない？
> Eclipse プラグインにあったかは知らないが 。

今はプラグインがなくてもすでにEclipseにそれが実装されている

>>118
> 複数のソースを比較しながらコードを書く
> どんな状況だ？

おれは思うに、彼には非常に効率の悪い
複数のいわゆるスパゲティコードを読む羽目に
なっているんだと思うよ。
設計がしっかりしていれば、
そんなまどろっこしいことしなくて済むのにねえ。

>>119
> 以下のような感じで、めっちゃ楽。

何に対して以上のような形といってるのかわからん。
一つ上のレスは関係なさそうだし。

> プロトタイプだからInterfaceでの定義もよく変わる、一つのファイルだからメニューからリファクター、とか選ばずとも手で素早く修正できる。
> 仕様に耐えられそうだったら、一人前のクラスとしてリファクターすればよい。
> こんなんでいちいち新しいクラスを箇々に作るのは時間のむだ。
> public class Base{
> static interface IntA{//省略
> }
> public static class TestA implements IntA{
> //省略
> }
> public static class TestB{
> ／／省略
> }
> }

>>121
> >>118
> > >複数のソースを比較しながらコードを書く
> > どんな状況だ？
> 比較というか複数のソースを横断的に(タブ切り替えでなく同時に見ながら)
> コードを書きたいことは普通にあるだろ。
> そういう状況がないというのであればそっちの方が信じられない。

お前が未だに30年前のコーディングスタイルに
填っているプロジェクトの考え方に依存していることが信じられないよ。

>>124
まさにそれだ

>>127
それをやって
どれくらいのパフォーマンスが期待されるんだ？
マシンスペックが高けりゃ雀の涙程度だったら、
意味無さ過ぎ。

>>127
それに一旦展開したらローカルに保存されるだろ。
Tomcatにしてもworkあたりにさ

>>133
部分的に俺の言いたいことと一致する。
しかしやっぱり危険なものだな。

たとえばある奴が行列クラスを作ったとき、
ある奴は転置を意味する演算子に'をつかう。
他のある奴が作った行列クラスでは'ではなく`を使ってたりする。

それだけでなく、こういうケースも
ある奴は、*を行列型どうしの乗算としてオーバーロードする。
だが、ほかのある奴は*を行ベクトル、列ベクトルどうしの内積としてオーバーロードする。
ほかのある奴は、ふたつの行列の個々の要素どうしを掛け合わせた行列型を返すようにオーバーロードする。

そんな演算子がごっちゃになったコードにまみれたら・・・・

大変なこった。

>>136
だったら、ばっさり切り捨てた方がいいな。

竹島って島は大したことがない島だから
日韓の争いを避けるために爆破しちまったほうがええやって感じにな。

>>150
スレ違いを承知で言うがな、おまえそれで領海がどれだけ減るか解って言ってるんだろうな？

>>147
さあなw
少なくともパフォーマンスが少し改善されるってことは
頭の片隅に入れておいていいんじゃないか

竹島は日本固有の領土

竹島は明治時代からの日本の領土

>>151
爆破したあとで海だけとればいい。
韓国のやってることは、
あんなちっこい島に無理矢理人を住まわせて
環境破壊して連絡船まで作ってるっていう赤字で
無駄で間抜けなことをやってまで
アホで必死すぎるからなw

>>152
それはまるで、C言語厨がC++を使うときに、
クラスを作ると遅くなるとわめくのとかわらないと思う。
STL使ったらC++使う意味がないとか意味不明なこと漏らす連中とか

>>149
まず、転置に'や`を使うのは不適切なケースだろう。だが、それは演算子オーバーロード
特有のものではない。例えば、メソッドだって、ある奴はtransposeという名前をつけるだろうが、
別の奴はtransとつけるかもしれないし、さらに面倒くさがりのやつはtrやtという名前をつけるかもしれない
また、乗算に関しても、メソッドに置き換えても全く同じことが成り立つ。以下、>>149の後半部分
に関して、*をmultiplyとして置換したもの。あと、「オーバーロード」だとメソッド定義の場合は不自然なので、
「定義」と置換した。

> ある奴は、multiplyを行列型どうしの乗算として定義する。
> だが、ほかのある奴はmultiplyを行ベクトル、列ベクトルどうしの内積として定義する。
> ほかのある奴は、ふたつの行列の個々の要素どうしを掛け合わせた行列型を返すように定義する。

と、このように全く同じことになる。もちろん、multiplyHogeHogeと修飾することで意味を明確にする
ことはできるだろうが、ここではそのようなことがプログラマに期待できない状況の話をしている
はずなので、無意味

>>127
Jarの場合はメモリ中で展開するから。
あと、セキュリティマネージャーを使うような設定にしてると、バラの場合は
classファイルをロードするたびに・・・

>>119
お前もしかしてCVS使ってない？
ファイル作ってコミットしたら削除するのに手間が掛かるから抵抗あるよな。

Subversion使えば楽だぞ。ディレクトリ移動や削除に何の抵抗もない。

もしSubversion使っててファイル作成にそれだけ抵抗あるなら、愚かとしか言いようがない。

>>130
否定したいがために無理な話をでっちあげるのはよせ。
「Classに対しては再定義できる、primitiveに対してはできない」というルールだけでOK。
primitiveでの演算子再定義なんか、必要あるわけねーだろ。

>するととたんにC++やC#の二の舞となるわけだ。
>あとはストラウストラップが指摘した問題だな。
だからその問題とやらを具体的に挙げろって何度もいってんだろ。挙げられないということは、おまえだって知らないんじゃねーか。

>>132
>(例えば、+なら可換であるとか)
なんでそんな必要があるの？それは勝手な思い込みじゃね？
例えばRubyのStringクラスでの * 演算子はまったく可換じゃないけど、だれも文句を言わないし、問題になったこともない。
可換であることを期待される場合とそうでない場合があるというだけだと思う。

>演算子オーバーロードそれ自体が悪いわけじゃなく、演算子オーバーロードの正しい使い方についてあまり啓蒙されなかったのが真の原因
なるほど。できれば正しくない使い方をもっと紹介してくれるとうれしい。

>>140
>この二つのメソッドを演算子オーバーロードした場合、どう区別つけるんだ？
何をどう区別したいのかが読み取れないけど、strとsbを区別したいなら、変数の型をみればいい。
メソッドの動作（appendのように破壊的かconcatのように非破壊的か）を区別したいなら、ドキュメントを読めばいいし、これはメソッドでも同じ問題が起こりうることであり、演算子固有の問題ではない。
メソッド名(concatとappend)を区別したいなら、
* C++やRubyのように演算子を直接定義する言語なら、メソッド名は関係なので区別する必要はない。
* Pythonのように演算子と対応するメソッドが一意に決まっている言語なら、ひとつの演算子に複数のメソッドが対応することはないので、区別する必要はない。

>>157
>それは演算子オーバーロード特有のものではない。
禿堂。メソッドでも起こる問題を、さも演算子オーバーロード特有の問題のように話すバカ大杉。
これだから、Java屋はJavaにない機能はすべて(ry

http://journal.mycom.co.jp/articles/2005/11/10/javaone1/
去年の JavaOne Tokyo の話によれば演算子オーバーロードが
dolphin に入るのは かなり望み薄だし、次世代Javaの動向と関係がない
演算子オーバーロード関連は他所のスレでやって欲しいぞ。

> これだから、Java屋はJavaにない機能はすべて(ry
最終的に これが言いたいだけの奴も居るみたいだし。

>>160
> 例えばRubyのStringクラスでの * 演算子はまったく可換じゃないけど、だれも文句を言わないし

* (積)は元々数学的に引数が可換な演算子じゃない。行列積とか考えてみればわかる。
+演算子について言っているのなら正しいけど、(Rubyの)Stringは最初期の頃からある
組み込みライブラリだから、変な風に定義されちゃっても大多数は普通は特に考えずに受け入れる。
あと、歴史的事情で、Stringの連結に+を使う言語が既に一般的だったというのもあるだろう。
ちなみに、「文字列連結演算子は可換でないのに+なのは変だ。*であるべきだ。」という主張は時々聞く。
少数派だけど。

> なるほど。できれば正しくない使い方をもっと紹介してくれるとうれしい。

正しく無い使い方なんて山ほどあるだろうけど(変なメソッド名の付け方がいくらでもあるのと
一緒)、例えば、+ - * /演算子で、引数を破壊的に変更するのは、おそらく正しく無い使い方だろう。

>>162
なんだよ、返答につまったら逃げるのかよ。
それはいいからストラウストラップが指摘した問題とやらを紹介してくれよ。
反対派の根拠がそれなんだろ？ちゃんと紹介しないからしょぼい理由ばっかりなんだよ。

>>163
>正しく無い使い方なんて山ほどあるだろうけど(変なメソッド名の付け方がいくらでもあるのと
>一緒)、例えば、+ - * /演算子で、引数を破壊的に変更するのは、おそらく正しく無い使い方だろう。
はげどう。あと、+= と << を混同しているケースもある。Rubyの場合だけど。

>>157
演算子オーバーロードで冗長な分かりやすい”演算子”をつける方法を教えてくれないか？

これだから石頭は困る

>>165
何が言いたいのかよくわからん

> もちろん、multiplyHogeHogeと修飾することで意味を明確にする
> ことはできるだろうが、ここではそのようなことがプログラマに期待できない状況の話をしている
> はずなので、無意味

と書いたのは
multiplyHogeHogeなどのように冗長に書くことで、メソッド名では(通常の演算子と違って)
意味を明確にすることができるが、ここで論じているのはプログラマがそのような適切な
名前付けをしてくれることが期待できない場合の話なのだから、そのことについて論じるのは
無意味だと言いたかったのだが。
ちなみに、Haskellでは普通の関数でも、``で囲むことで、1 `add` 2のように中置演算子として
扱うことができる。同じような仕組みをJavaでも使うことで、「演算子」であっても、冗長な
名前を付けることができるだろう。

>>164
どうでもいいが反対「派」とかいってひとまとめにひっくるめるのは止めろ。
おまえも賛成「派」なんて呼ばれたいのか。

おれはどっちかというと反対だが、別にC++がどうこうじゃなくて、なんでも
かんでも文法を拡張することに慎重でありたいだけ。
例えばコレクションもいずれは配列のようにアクセスできるようになる日が
くるかもしれんが、言語仕様を変更して採用するかどうかについては、
ぎりぎりまで十分に検討してもらいたいと思う。

言語仕様をどんどん変更されたら、言語としての安定性が疑われる。
PHPなんかひどいだろ。
Javaは言語仕様は小さく、ライブラリは豊かに、でいいと思うんだがね。

その上でもし仕様変更がなされたら、おれは文句も言わずに喜んで使うよ。
むしろ「楽になった」と喜んで喧伝するかもしれん。
それがなんか悪いか？ 散々慎重なこといっといてこれだからJava厨は、と
言われてもしらね。変更に慎重になることと、慎重に検討した結果導入された
ものを使うことは別に衝突しない話だと思うがね。

そんなわけでオーバーロードが導入されようがされまいが、こんなもめるという
ことは、まだ十分に検討されてない事柄だということだけはわかった。引き続き
数年かけて検討すればいいよ。
Java 7の話に戻してくれんかね？

>>167
よくできました！
この感想文には100点を差し上げましょう！

>>165
なんだ、[]や+の意味がわからないのか。そういうレベルとは知らなかった。議論の前提を間違ってた。正直済まんかった。

>>167
開き直り乙。おまえのいいたいことはわかったから、ストラウストラップが指摘した問題をよろしく。
それから議論の発端をちゃんと読んでね。

>>168
開き直り乙。仲間ができてよかったね。

で、>>169はどれを書いたの？

>Javaは言語仕様は小さく、ライブラリは豊かに、でいいと思うんだがね。
もはや言語仕様小さくないだろう。Java7になればもっとひどくなるだろうし。

>>167
> おまえも賛成「派」なんて呼ばれたいのか。
別にかまわないけど。何が問題なの？

> それがなんか悪いか？ 散々慎重なこといっといてこれだからJava厨は、と
> 言われてもしらね。変更に慎重になることと、慎重に検討した結果導入された
> ものを使うことは別に衝突しない話だと思うがね。
悪いね。「変更に慎重」なことと、理由をこじつけて否定することはまったく別のこと。
今までの反対派の発言をみてみろ、まず「演算子の再定義は悪」という結論があって、そのために無理な理由をつけて反対しているだけじゃん。
これのどこが「変更に慎重」なんだよ。そう言いたいんだったらそれらしい議論しろっつーの。
おまえが「ストラウストラップがこういう問題を指摘してるんだけど、それはどうしたらいいと思う？」とでも書けば「変更に慎重」ということにもなるよ。
しかしおまえらは、はなから「Javaは正しい」「演算子オーバーロードは悪」という結論ありきで話してるじゃん。
そして、そのための理由を無理にこじつけて、それらを論破されて、それを今になって「変更に慎重」とか、もうアホかと。

> 言語仕様をどんどん変更されたら、言語としての安定性が疑われる。
> PHPなんかひどいだろ。
言語仕様の安定性と、ライブラリや実装の安定性を混同している。
PHPで安定しないのは後者。前者は安定している（PHPの仕様は4→5で大きく拡張されたが、それはJavaでも同じ）。
実装が不安定だからといって、勝手に言語仕様まで同じにするな。

>>168
この感想文には「まけおしみ」というタイトルをつけましょう。

>>172
> 理由をこじつけて否定することはまったく別のこと。
なんか知らんけど、 「理由をこじつけて否定」されたから
腹がたってムシャクシャしてやったのであって、
次世代Java とは関係がない話って事だね。

> それらしい議論しろっつーの。
次世代Javaの動向とは関係がない話題だから ここでやるのはスレ違い

マ板のスレにでも行って愚痴れば？

>>164
本題とは関係無いが、Rubyだと+=演算子はユーザが定義することはできず、x = x + yの
シンタックスシュガーのはずなので、<<とは混同しようが無いと思うんだが。

オーバーロードの議論は結局
(f+g)(x)は読みやすいか？
まで遡るのでやっても無駄と思われ

たとえば演算子をオーバーロード出来たとする
すると、どんなにメソッド名を付けることが上手いプログラマでも、
+演算子のオーバーロードを使う場合が出てくる
これままぁいい

問題なのは、このときに自分の定義した+演算子と他人の定義した+演算子が
厳密には異なる動作をする可能性があるのが問題
これはドキュメントを読めばいい、というレベルの話ではなく、
間違いなく可読性(というか即読性？)が低下する

さらには、C++風に記述した*演算子(つまりoperator*)には名前が1つしかないのが問題
これでは行列型どうしの乗算なのか、内積なのか、外積なのか即、判断ができない
これが多分>>149が言いたかったこと
いまだと、メソッド名によって操作の内容が容易に判断できる

確かに駄目プログラマオンリーなら、演算子がオーバーロード出来ようと出来まいと関係ない
でも、世界は駄目プログラマだけじゃないので、演算子がオーバーロード出来てしまうと
上に書いたような事態に陥る

まぁ、Javaに演算子のオーバーロードが追加されるなら、
何らかのメソッドにアノテーションかなんかで実現してほしい

@AddOperator
public Hoge add(Hoge hoge) { ... }

それよりも、package private/protectedなinterfaceがほしい今日この頃
例えばRunnableインターフェイスをprotectedにすると、
runは外部から呼び出せないことになるので、
今のようにstartを呼ばなければいけないところをrun読んだりするミスがなくなるし

>>173
劣勢になったら「スレ違い」宣言かよ
それはいいからストラウストラップのやつよろしく

>>178
ストラウストラップのは>>149,176がいってるやつ
たしかD&Eで言ってたような・・・うろ覚えスマソ
ただ、ストラウストラップ自体はそこまで演算子の多重定義を否定してなくて、
あくまでそういう意見もいる、ってこと
まぁPuzzlersとか読む限り、俺もJavaに演算子の多重定義はいらないかな、と思う
>>176の案だったらまだ許せるけどね

あと、176よ、package privateなinterfaceは今でもあるぞ？

なるほどぐぐったらすぐ出てきたよ
粘着している元ネタはこれか

ttp://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

どう読んでもネタだわこりゃw

>>175すばらしい！

>>180は確かにネタだがこういうネタが通用する背景には
C++の言語仕様に辟易しているPGが多いっていう真実が隠されてるわけだね
ネタだからといって演算子オーバロードが良いとはいえないわけだ
「賛成派」の>>172には支持理由を是非とも熱く語ってほしいね

同じ次世代を目指しているから、D言語の人たちはどう思ってるかのぞいてみたら？

>>180 は多分C++使い始めの奴らが「わかるわかる」って言い出す内容だと思うんだ。
C++のプロはそんなこと絶対思わない。

じゃぁ、C++のプロってのは実プロジェクトにそんなに必要なのか？って言えば…。

いらないよな。

>>157
> >>149
> まず、転置に'や`を使うのは不適切なケースだろう。だが、それは演算子オーバーロード

ちょっとまったーーーーーーーーーーーーーー！！！
MATLABやOctave使ったことあるか？
MATLABやOctaveでは行列の転置に'を使うんだぜ。
A = [1 2 3; 4 5 6; 7 8 9];
って行列があったとき
B = A'ってやると
Bの中身は [1 4 7; 2 5 8; 3 6 9]になって

B = | 1 4 7 |
　　　| 2 5 8 |
　　　| 3 6 9 |

て表示されるんだぜ。


> 特有のものではない。例えば、メソッドだって、ある奴はtransposeという名前をつけるだろうが、
> 別の奴はtransとつけるかもしれないし、さらに面倒くさがりのやつはtrやtという名前をつけるかもしれない

それはまた違う問題だ。Javaにはpackageの概念があるんだから、
メソッドの名前が乱立しても、名前空間の衝突は起きないだろー

>>160
無理な話じゃないさ。
面倒なことになるから、どうしても導入したければ、
もっと頭をつかえっていっときたい。
enumや可変長引数を導入したときのように。
Genericsを導入したおかげでありゃうまいことやってくれたって思ったよ。

>>162
> http://journal.mycom.co.jp/articles/2005/11/10/javaone1/
> 去年の JavaOne Tokyo の話によれば演算子オーバーロードが
> dolphin に入るのは かなり望み薄だし、次世代Javaの動向と関係がない
> 演算子オーバーロード関連は他所のスレでやって欲しいぞ。
> > これだから、Java屋はJavaにない機能はすべて(ry
> 最終的に これが言いたいだけの奴も居るみたいだし。

みたいだな。

これみると、キッパリと否定されてるようだしw つか、C#でもつかってろってw
【レポート】JavaOne Tokyo 2005 - 見えてきたDolphin、Mustangのさらに向こう
Dolphin世代のJavaはどうなる? (MYCOMジャーナル)
"Peter氏は、今後もJava言語にはさらなる拡張が加えられると宣言する一方で、
Javaでサポートされる可能性のない機能の代表格として以下のようなものを挙げている。

* 多重継承
* 演算子オーバーロード
* AOP(Aspect Oriented Programming)
* プリプロセッサ/マクロ
* 多重ディスパッチ
* 複数返り値"
http://journal.mycom.co.jp/articles/2005/11/10/javaone1/


AOPが導入されないのはちょっと残念かもしれないけどAspectJでうまい使い方があるし
使い道も限られてるからまあいいかってとこだね

>>164
JavaOne TokyoでJava開発者が主張していることを
あげただけで逃げになるのかw

小学生かお前はw

>>167
オーバーロードのことで揉めるのは
C++厨やC#厨の連中がなんとかしてJavaをこき下ろしたいだけだろ。
なぜそんなことするのかわからんけど。
そんなにJavaが嫌いだったらC#かC++でも使っていればいいのに。

>>169
お前の粘着っぷりには笑った

>>170
ナイスツッコミｗ

>>172
> 今までの反対派の発言をみてみろ、まず「演算子の再定義は悪」という結論があって、そのために無理な理由をつけて反対しているだけじゃん。
> これのどこが「変更に慎重」なんだよ。そう言いたいんだったらそれらしい議論しろっつーの。
> おまえが「ストラウストラップがこういう問題を指摘してるんだけど、それはどうしたらいいと思う？」とでも書けば「変更に慎重」ということにもなるよ。
> しかしおまえらは、はなから「Javaは正しい」「演算子オーバーロードは悪」という結論ありきで話してるじゃん。

まてまて、それはお前の被害妄想だよw
まあ、落ち着けw

> そして、そのための理由を無理にこじつけて、それらを論破されて、それを今になって「変更に慎重」とか、もうアホかと。

おいおい、泣くなよw よしよし、ぼくちゃん虐められてたんだね、よしよしw

> > 言語仕様をどんどん変更されたら、言語としての安定性が疑われる。
> > PHPなんかひどいだろ。
> 言語仕様の安定性と、ライブラリや実装の安定性を混同している。
> PHPで安定しないのは後者。前者は安定している（PHPの仕様は4→5で大きく拡張されたが、それはJavaでも同じ）。
> 実装が不安定だからといって、勝手に言語仕様まで同じにするな。
名前空間もない致命的な欠陥に加え、import宣言も実装されないあのPHPがJavaと同じっておいおいw
__autoloadって何だよあのアホ仕様w

だったらさ、キミの大好きなPHPにも演算子オーバーロードをつけてくれるように頼んで皆よw
> >>168
> この感想文には「まけおしみ」というタイトルをつけましょう。

いや、お前のほうが負け惜しみのタイトルに相応しいレスを繰り返しているよw
>>168のレスは的を得ているし、すっきりするし説得力があるしレスとしては賢明なほうだと俺は思うぞ。

C#って演算子オーバーロードあるの？

かなり萎えた。

>>173
> >>172
> > 理由をこじつけて否定することはまったく別のこと。
> なんか知らんけど、 「理由をこじつけて否定」されたから
> 腹がたってムシャクシャしてやったのであって、
> 次世代Java とは関係がない話って事だね。

ワロタ。ムシャクシャしたC#厨がJavaスレにイチャモンつけてるのかw

>>175
読みにくい。

よって、Javaに演算子オーバーローディングは要らない。

>>176
もし仮に演算子オーバーロードをJavaに実装するなら、
アノテーションだけでなく、演算子に名前空間とアクセス権、演算子の優先順位、結合力もつけるべきだな。

>>193
あるよ。
しかもC#2.0ではめちゃくちゃな仕様が増えた。
?演算子がオーバーロードされたし。

演算子のオーバーロードって結局、
メソッドをグローバル化することに他ならないんだと思う。

このオブジェクトに対するこの操作は全員が把握してしかるべきもの
と思われるものに対してのみオーバーロードが許されるべき。

Javaでは「全プロジェクトにおいて許されるものはStringの+ぐらいである」
というスタンスで進んでる。

C++では「いろんなプロジェクトで特有のものがあるだろ」
ってスタンスで進んでる。

俺は、Javaのスタンスで一向に差し支えないと思う。
なぜなら、演算子のオーバーロードの情報がグローバルに共有されることが稀だから。

>>185
MATLABは使ったことあるよ
でも、Matlabのそれは言語組み込みの演算子だから、演算子オーバーロードとはまた違う問題じゃないの？
そりゃ、MATLABユーザなら、他の言語でその演算子を見たときに、すぐに転置を表すものだと
理解できるかもしれんが、普通は無理だろ

> Javaにはpackageの概念があるんだから、

同じ機能のメソッドが別の名前だったり、同じ名前で別の機能を持つメソッドがあったときに
ユーザが混乱するかどうかという話なので、名前空間の話は無関係

>>198
メソッドをグローバル化って何？名前空間のことを言っているのなら、
全然違うと思うが。演算子と言っても、名前空間をもてないわけじゃないし。

いい加減、C++厨は演算子にどれだけ情報量があるか気づけ。
高々１文字・２文字でどのように処理の意味を表現するのだ？

既に他分野で暗黙的に利用されている意味以外での利用
がどれほど保守性を下げるのか理解して言っているだろうな？

>>198
それじゃ、結局、
オーバーロードした演算子にアクセス権を設定することはできないのか・・・

>>199
お前、本当にMATLAB使ったことあるのかw

>>199
おいおい、あのさ
演算子に名前空間はつけられないんだろ。それとも、つけられる仕様にできるのか？
名前空間がつかなかったら、異なる定義の演算子どうしの衝突がおきるだろう。

メソッド名に演算子が使えるだけという程度ならまた異なる話だがな。

メソッドと演算子との違いもわからんのか。メソッドは
add()という加算用インスタンスメソッドがあるなら、x+yは
x.add(y)と表現するわけだろう。

それを、演算子にしたいがために x + y としたいわけだな？

そのことでお前がこういったことについて聞くが
　「例えば、メソッドだって、ある奴はtransposeという名前をつけるだろうが、
　別の奴はtransとつけるかもしれないし、さらに面倒くさがりのやつはtrやtという名前をつけるかもしれない
　また、乗算に関しても、メソッドに置き換えても全く同じことが成り立つ。」

お前の主張した、「演算子をメソッドに置き換えても全く同じ事が成り立つ」
ためには

x.add(y)はx.+(y)と置き換えた場合に限る。
(このケースの場合、()や.の定義も再定義しなければC++でもコンパイルエラーになるがな。)
だがC#やC++の演算子のオーバーロードは x.+(y)とはならない、あくまでx+yだ。
これでお前は自分のいっていることがおかしいことに気づいたか？

>>203
どういう意味？
MATLABの行列転置演算子は組み込みのものだと思っていたのだが、違うの？

>>201
奴はC++厨じゃなくてＣ＃忠だよ。

C#とマイクロソフトに忠誠を誓う男、C#忠だ。
経験豊かなすごうでなC++厨だったらもっとましなことを言うはず。

>>205
お前、さっき急いで「MATLAB 転置」でググッただろw

>>176
>問題なのは、このときに自分の定義した+演算子と他人の定義した+演算子が
>厳密には異なる動作をする可能性があるのが問題
だからそれはメソッドでも起こる問題だってんだろ。
自分が定義したメソッドfoo()と他人が定義したfoo()が異なる動作をするなんてしょっちゅう。
メソッド名がかぶっても問題ないのは、双方が異なるクラスで定義されているからであり、それは演算子でもおなじこと。

> *演算子(つまりoperator*)には名前が1つしかないのが問題
> これでは行列型どうしの乗算なのか、内積なのか、外積なのか即、判断ができない
複数の動作が考えられるなら、演算子をつかわずすべてをメソッドにするか、または代表的なひとつだけを演算子にしてのこりはメソッドのままにしとけばいい。
演算子オーバーロードができるからといって、なんでもかんでも演算子にする必要はない。
普通に考えればわかることだろ。はなから否定することしか考えてないから、そういう考えしかできないんだよ。

>>204
別にC++/C#の演算子オーバーロードに限定して言ったつもりは無いんだけど
例えばRubyだと、演算子の定義とメソッドの定義は全く等価だし

後半は言っていることが全く意味不明。そりゃ、C++/C#において、メソッド呼び出し
と演算子呼び出しのシンタックスが違うことくらいわかってるがな。一体何が言いたいのやら

>>192
まてまて、話をよくよめ。JavaとPHPの言語仕様が同じといってないだろ。言語仕様が大きく拡張されたという点で同じといってるだけ。
「言語仕様をどんどん変更されたら、言語としての安定性が疑われる。PHPなんかひどいだろ。」
→「PHPでは５になるときに大きく変更されたけど、それはJavaも同じ」
→「import宣言も実装されないあのPHPがJavaと同じっておいおいw」←いまここ

>>196
そんな複雑なのいらない。そこまではだれも望んじゃいない。

>>207
別にググって無いんだけど。…今ググッてみたが、MATLABにも
演算子オーバーロードあるのか。知らんかった。それに関しては
間違ってたので、謝罪する。
ただ、どちらにしてもMATLABで'が転置を表すのは、言語仕様あるいは
処理系に組み込みで定義されてるからであって、他の(MATLABのように
'が転置を表すことが一般的に認知されていない)言語のユーザがそれを転置
演算子としてオーバーロードするのが適切かは別問題だろう

>>198
>演算子のオーバーロードって結局、
>メソッドをグローバル化することに他ならないんだと思う。
意味不明。

>>201
記号には十分な情報量あるよ。+や-で処理の意味を十分表せてる。
やっぱり四則演算の記号すら知らないんじゃないの？

>>204
ちょー意味分からん。
定義のしかたは>>176の方法でもなんでもいいからさ、例えば x + y があったら、コンパイラが型の情報とメソッド定義とをみて、x.add(y) とかに変換してくれればそれでいいじゃん。

>x.add(y)はx.+(y)と置き換えた場合に限る。
どうやったらこんな話になるのやら。

>>208
> >>176
> >問題なのは、このときに自分の定義した+演算子と他人の定義した+演算子が
> >厳密には異なる動作をする可能性があるのが問題
> だからそれはメソッドでも起こる問題だってんだろ。
> 自分が定義したメソッドfoo()と他人が定義したfoo()が異なる動作をするなんてしょっちゅう。
> メソッド名がかぶっても問題ないのは、双方が異なるクラスで定義されているからであり、それは演算子でもおなじこと。

>>204をもう一度読み直してから出直してこい。

>>210
その「いまここ」という用語使いたがるところがゆとり世代のバカっぽくていいね。

あいかわらずJavaユーザは、Javaにない機能はイラネですか。10年同じことを繰り返してるんだなあ。
クロージャも導入されたら、とたんに手放しでマンセーするんだろうなあ。

あのさ、別に演算子オーバーロードがJavaに導入されようがされまいがどうでもいいけど、でもJavaユーザが主張している拒否の理由はどれも根拠が弱いよ。
LispもPythonもRubyも演算子の動作を再定義できるけど、それぞれ別のやりかたでうまくやってる。
そういうのを知らずに、たんに自分が知らない機能を嫌ってるだけじゃね？

COBOLerがCOBOLから離れられないように、Java-erはJavaから離れられないのね。

>>176
演算子オーバーロードやるならinterfaceにして欲しいような気もする。

interface 四則演算<T>{ //あるいは更に縛って四則演算<T extends 四則演算<T>> とか
　T add(T v); T subtract(T v); T multiply(T v); T divide(T v);
}
緩いほうで Hoge extends 四則演算<String> されると、
hoge + str の意味が、四則演算無しの時と有りの時で
文字列連結か演算子オーバーロードかで変わっちゃったり、
変わらない場合は演算子の優先順位が面倒だったりしないかな、とか思った。

後は .Comparable で <, <=, >, >= 使えるようにするとか……
でも、これは参照型の ==, != が同じ参照かを比較するのと相性悪いような。

ついでに
interface Indexer<I, E>{ void set(I index, E element); E get(I index); }
とか。 List でやったら autoboxing が発生しまくるような気もする。

>>176
>問題なのは、このときに自分の定義した+演算子と他人の定義した+演算子が
>厳密には異なる動作をする可能性があるのが問題
だからそれはメソッドでも起こる問題だってんだろ。
自分が定義したメソッドfoo()と他人が定義したfoo()が異なる動作をするなんてしょっちゅう。
メソッド名がかぶっても問題ないのは、双方が異なるクラスで定義されているからであり、それは演算子でもおなじこと。

> *演算子(つまりoperator*)には名前が1つしかないのが問題
> これでは行列型どうしの乗算なのか、内積なのか、外積なのか即、判断ができない
複数の動作が考えられるなら、演算子をつかわずすべてをメソッドにするか、または代表的なひとつだけを演算子にしてのこりはメソッドのままにしとけばいい。
演算子オーバーロードができるからといって、なんでもかんでも演算子にする必要はない。
普通に考えればわかることだろ。はなから否定することしか考えてないから、そういう考えしかできないんだよ。

>>212
> >>198
> >演算子のオーバーロードって結局、
> >メソッドをグローバル化することに他ならないんだと思う。
> 意味不明。
> >>201
> 記号には十分な情報量あるよ。+や-で処理の意味を十分表せてる。
> やっぱり四則演算の記号すら知らないんじゃないの？
> >>204
> ちょー意味分からん。
> 定義のしかたは>>176の方法でもなんでもいいからさ、例えば x + y があったら、
> コンパイラが型の情報とメソッド定義とをみて、x.add(y) とかに変換してくれればそれでいいじゃん。

認識が甘いな。
お前みたいな演算子オーバーロードを崇拝するバカは
フィッシング詐欺や甘い誘いに騙されやすい奴に実にそっくりだよ。
お前の例で聞くが、
x + y / z と書いたら、

x.add(y.divide(z)) と期待通りに動くように設計できるか？
x.add(y).divide(z)と間違えないだろうな。

>>212
> >>201
> 記号には十分な情報量あるよ。+や-で処理の意味を十分表せてる。
> やっぱり四則演算の記号すら知らないんじゃないの？

おまえは>>201の意図していることを理解できていないみたいだな。
>>201の例を俺が代弁するとだな。

ある言語では定義できる演算子が100種類。
定義できるメソッド名に使用できるアルファベットはもちろん26+10種類以上。
ただしメソッド文字数は256文字まで。

あるクラスを数十定義したとする。
それぞれ異なる振る舞いをするメソッドであり、
そのメソッドの数を数えると200もあった。

そこで、それぞれのメソッドをそれぞれ異なる演算子として定義したくなった。
そこでそれぞれのメソッドに次々と演算子を定義してゆくが・・・・

演算子が足りない！！！！！！！
演算子が足りないためにこれ以上演算子のオーバーロードができない！！！！！！！！！

こんな事態に陥ったら本末転倒だろう

>>215
> あいかわらずJavaユーザは、Javaにない機能はイラネですか。10年同じことを繰り返してるんだなあ。
> クロージャも導入されたら、とたんに手放しでマンセーするんだろうなあ。

その根拠は？　まさかGenericsがC++のtemplateと同じものだと勘違いして、
「JavaユーザはC++templateをマンセーしてる！」とかアホなこと言ってるんじゃなかろうなw

> あのさ、別に演算子オーバーロードがJavaに導入されようがされまいがどうでもいいけど、でもJavaユーザが主張している拒否の理由はどれも根拠が弱いよ。
どう根拠が弱いのかね。説明できないではどうにも説得できないな。
そもそもJavaはLispやPythonやRubyと違って強く型付けされた言語だってことを忘れていないかね。
そこをよく見れば、演算子オーバーロードがどういう問題を引き起こすかわかるはずなんだが。

>>216
それだったら、アノテーションにしてもかわらんだろ。

そもそもアノテーションというのは
java.lang.Annotationインターフェースを継承したものなんだから。

>>216
> >>176
> 演算子オーバーロードやるならinterfaceにして欲しいような気もする。
> interface 四則演算<T>{ //あるいは更に縛って四則演算<T extends 四則演算<T>> とか
> 　T add(T v); T subtract(T v); T multiply(T v); T divide(T v);
> }
> 緩いほうで Hoge extends 四則演算<String> されると、
> hoge + str の意味が、四則演算無しの時と有りの時で
> 文字列連結か演算子オーバーロードかで変わっちゃったり、
> 変わらない場合は演算子の優先順位が面倒だったりしないかな、とか思った。
> 後は .Comparable で <, <=, >, >= 使えるようにするとか……
> でも、これは参照型の ==, != が同じ参照かを比較するのと相性悪いような。
> ついでに

それだと、また新たな問題が出てくるな。
Comparableインタフェースを実装したある奴が作ったクラスではcompareTo()を
不等号演算子にオーバーロードしているが、
Comparableインタフェースを実装してはいるが、他のある奴が作ったクラスでは、
演算子のオーバーロードを一切していなかったとき、それぞれのクラスから
オブジェクトを作って、それら二つのオブジェクトを不等号演算子で比較したとき、
何が起こると思う？ C++どころかC#でも抱えている問題なのだが。

JavaはRubyみたいな言語と違って型に強い言語なんだぜ。下手なことをやると
C#と同じように痛い目を見るんだぜ。

>>216
それ、かなりいいね。そして、インターフェイスを理解している証拠だ。

>>221
言わなくても判ると思ったんだけど
アノテーションの方が自由な演算子オーバーロードが出来そうだよ。

同じinterfaceは複数回継承できないから、
例えばMatrix3D implements 四則演算<Matrix3D>, 四則演算<Vector3D>{...}とか出来ないし。

>>217
> >>176
> >問題なのは、このときに自分の定義した+演算子と他人の定義した+演算子が
> >厳密には異なる動作をする可能性があるのが問題
> だからそれはメソッドでも起こる問題だってんだろ。
> 自分が定義したメソッドfoo()と他人が定義したfoo()が異なる動作をするなんてしょっちゅう。

まだわかっていないようだね坊や。
もう一回>>204の最後の方をよくよんでごらん。


> メソッド名がかぶっても問題ないのは、双方が異なるクラスで定義されているからであり、それは演算子でもおなじこと。
> > *演算子(つまりoperator*)には名前が1つしかないのが問題
> > これでは行列型どうしの乗算なのか、内積なのか、外積なのか即、判断ができない
> 複数の動作が考えられるなら、演算子をつかわずすべてをメソッドにするか、または代表的なひとつだけを演算子にしてのこりはメソッドのままにしとけばいい。

それじゃ本末転倒だな。中途半端で、結局混乱を招くし、演算子で定義されていないメソッドのほうを
頻繁に使うことになると、一方の演算子が宝の持ち腐れになってゴミ同様となる。

だから、Javaに無理して演算子オーバーロードなんてつける必要がないんだよ。
そもそも、+演算子を勝手にオーバーロードされたら、toString()メソッドと+がうまく機能しなくなるわな。
オブジェクトをString型オブジェクトと+で連結すると、暗黙のうちにオブジェクトがtoString()メソッドを呼び出して
文字列化するっていうJavaに昔からある機能が、突然使えなくなってはあとあとバグを生み出すもとになりかねないわけだが。

Javaでは 四則演算<Matrix3D>と四則演算<Vector3D>は異なるクラスとして
扱われるのだが。

A<Integer>はA<?>のサブクラスっていうようにな

>>222
あぁ悪い。>>216の中段は、既存の参照型の ==, != を再定義しない前提で書いてる。

既存の参照型の ==, != を再定義できるようにするって方向もあるのかもしれないけど、
個人的な意見としては、参照型の ==, != を再定義すると躓く奴が多そうなので勘弁して欲しいかな。
それでなくても質より量な感じで投入されてくる人多いし。
技術的理由というより、政治より(?)な理由だけど。

>>228
他人に逃げるなといっときながら、
>222のレスについてはちゃんと読まずに誤魔化して逃げかw

>>204
自分の事しか言わないこういうトンデモちゃんが電波の代表なんだろうな。
上手くぼろを出さないように知ったこというだけで、適当にあしらわれて終わりなのに、
本人はそれにまったく気がついていない・・ ｹｹｹ

>>226
ダウト。基本的に別の型であるというのは確かにそうなんだが
Java Genericsの実装がErasure方式なせいで、メソッドのオーバーロードやインタフェース
の実装や例外クラスなどいくつかのケースで、同じクラスとみなされてしまう
>>224は自分じゃないが、
> Matrix3D implements 四則演算<Matrix3D>, 四則演算<Vector3D>{...}とか出来ないし。
と言っているのは、もしこれがコンパイルできると、型パラメータ情報が消去されて、
Matrix3D implements 四則演算, 四則演算{...}と等価になってしまい、クラスファイルの
仕様に反してしまうから。

>>230
Javaを知っている程度で実際は大して使えないSEなんじゃないか。

それも給料低いわりには重労働で時間拘束もひどい。

重圧に耐えられず、ここで八つ当たりしてるんじゃねぇ・・

Java関連のスレに頻繁に顔出してるしな。

そういう奴は、どこでも同じだし、そのうち過労で死ぬんじゃねぇの？ｹｹｹ

>>226
erasureのせいで実行時は四則演算<Matrix3D>と四則演算<Vector3D>は
同じ型に成り下がるので、>>224のはコンパイルエラーになる。

http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.5
> A class may not at the same time be a subtype of two interface types
> which are different invocations of the same generic interface (§9.1.2),
> or an invocation of a generic interface and a raw type naming that same generic interface.

>>230, >>232
どうしようもなくなると語尾にｹｹｹとつて
サクラな自作自演乙
ストラウストラップがいってたことってなんだよを連呼して
しつこく演算子オーバーロードに拘って八つ当たりしていたのは一体誰だろうねw

>>234

俺達の合言葉にｹﾁつける気か、お前は？

お前の気に食わないことにｲﾁｲﾁ脊髄反応している時点で、
お前が粘着ｻﾞｺなんじゃないか？ ｹｹｹ

一回氏ね！ ｹｹｹ

>>215
> クロージャも導入されたら、とたんに手放しでマンセーするんだろうなあ。
クロージャの出来が良ければ遠慮せずにマンセーするよ。
それで何か悪いの？

>>226
matrixとvectorは数学では同じように扱ってもプログラム上では両者は違うでしょ？
それを型で表していると考えると納得できるかな？

>>236
散々悪口だけ言って、生意気なんだよ。
そういうのは悪い奴の典型例で一回氏ね！

ところで、口だけでお前は一体何が出来るんだ？ ｹｹｹ

>>238って、ひょっとしてツンデレなのかも？ と思ってしまった。

大昔のgoslingの演算子オーバーロードに関する見解を見つけて見た。
http://web.archive.org/web/19990202050412/http://java.sun.com/people/jag/FP.html#overloading

例があがってるのは、
・二項演算子は右辺と左辺を交換可能である事もあるけど、
メソッド呼び出しはそうじゃないから、例えば左辺にプリミティブが現れた場合
1/m を m.divideReverse(1) に変換する、みたいにしないといけない。
交換可能ってだけなら @Commutativeみたいなアノテーションつければ良いような気もする。
1/m を m.divideReverse(1) ってのはそれだけじゃ無理だけど。

・今更==をequals()の呼び出しにできない。
immutableな型なら問題にならないって書いてあるけど、良いのかな？
mutableな型よりは問題少なそうだとは思うけど。

・構文解析の問題。
例えば (p)+q みたいに単項+演算子付きのqをp型にキャストするとも、
qと括弧付きのp との加算とも取れる曖昧な式が出現した時に、
今までのJavaではプリミティブ型かどうかでチェックしてたけど、
他の方法でチェックする必要が出るらしい。
良くわからんけど互換性を考えつつ別のチェック方法考えるってのが大変なんかな？

>>240
最後のって、単純に可視な変数かどうかでチェックすれば良いような気もするけど……

それじゃダメなんか？

>>239


ｹｹｹ

クロージャや関数型は望んでる奴が沢山いるだろ。
enumやジェネリクスだってそうだった。

けど演算子オーバーロードは違う。
「混乱するなら使わなきゃいいだけ」
って言うにはあまりにも厨房の
「俺って出来る奴」的プライドをくすぐる機能だ。

>>243
俺も別に今のJavaに無理して演算子オーバーローディングを導入する必要
は無いと思ってるが

> 「混乱するなら使わなきゃいいだけ」
> って言うにはあまりにも厨房の
> 「俺って出来る奴」的プライドをくすぐる機能だ。

はあんまりだぜ。確かにC++では厨房が変な使い方をした場合も多かっただろうけど、
実際に有用な局面もそれなりにある。例えば、事務処理系のプログラムや数値計算系のプログラム
などを多く書く人にとってみれば、BigDecimalや行列などの演算をメソッド呼び出しで書くなんて
耐えがたいだろう。それがどれだけ嫌かはintやdoubleなどのプリミティブ型でも+などの演算子を使う
ことが許されず、全部をadd,subtractなどのメソッド呼び出しで書かなければいけないとなったときの
ことを想像してみるとわかりやすいだろう。
他にも、DSL(Domain Specific Language)を作るのにも演算子オーバーローディングは有用。
見たことのある例だと構文解析器を構築するためのフレームワークを言語内に構築するとか。
んなもんParser Generator使えばいいじゃないかと言うかもしれんが、Parser Generatorは
構文定義中に埋め込まれたプログラムが変でも関知しないせいで、生成されたコードを
コンパイルする段階になって初めてエラーが報告されるなど、面倒な部分がある

javaのenumは、stateA | stateBが出来なくて使いづらい。
これも演算子オーバーロードなのかもしれんが。
EnumSetじゃね…。

なるほど>>245

>>245
Javaのenumでそんなことは出来ないだろ。
public enum State {
HOGE {
public void func() { ... }
},
PIYO {
public void func() { ... }
};
public abstract void func();
}
とかで、
State state = State.HOGE State.PIYO;
state.func();
はどうなるの？どっちも呼び出す？
そもそもそういう用途にはenumを無理して使うより、
public static final intでいいと思うんだが。

>>245
それの解決は、演算子オーバロードというよりも
EnumSetのシンタックスシュガーで逃げる解決方法がいいと思うな・・・

演算子の意味はやっぱり固定にして欲しいし
>>244 で上げてる問題の解決には
演算子オーバロードにこだわる必要ないしな
プリプロセッサで何とかなる程度だから、マクロでもいいんじゃない？
＋、＊とかの既存の演算子を使う事はないと思う
まぁ、問題を演算子オーバロードの是非からマクロの是非にすり替えてるだけかもしれんが。

>>235
ついに「死ね」と言いだしたか。
随分短気だな死者ﾌﾟﾁｭwww

>>239
いや、こいつはC#って死滅しちゃうの？ｽﾚで大暴れしていた
あのﾊﾞｶM$厨だよw

>>241
P p = new P(??????); //?には何かが入るとする。
Q q = new q(??????); //?には何かが入るとする。

p+=((((((((((-p++)))))))))*+q*(p*(q/(p*(q/(p+q))))

こんなのが出た場合、ちゃんと解析できるかな？

>>243
> クロージャや関数型は望んでる奴が沢山いるだろ。
> enumやジェネリクスだってそうだった。
> けど演算子オーバーロードは違う。
> 「混乱するなら使わなきゃいいだけ」
> って言うにはあまりにも厨房の
> 「俺って出来る奴」的プライドをくすぐる機能だ。

でたでた、うぬぼれC#厨お得意の機能w

>>244
> >>243
> 俺も別に今のJavaに無理して演算子オーバーローディングを導入する必要
> は無いと思ってるが
> > 「混乱するなら使わなきゃいいだけ」
> > って言うにはあまりにも厨房の
> > 「俺って出来る奴」的プライドをくすぐる機能だ。
> はあんまりだぜ。確かにC++では厨房が変な使い方をした場合も多かっただろうけど、
> 実際に有用な局面もそれなりにある。例えば、事務処理系のプログラムや数値計算系のプログラム
> などを多く書く人にとってみれば、BigDecimalや行列などの演算をメソッド呼び出しで書くなんて
> 耐えがたいだろう。それがどれだけ嫌かはintやdoubleなどのプリミティブ型でも+などの演算子を使う
> ことが許されず、全部をadd,subtractなどのメソッド呼び出しで書かなければいけないとなったときの
> ことを想像してみるとわかりやすいだろう。

頭使えよ。Jakarta Velocityでも使っても良いし。
数値演算のとこだけ
とりあえず演算子で記述して、
Javaソースコードに貼り付けるときに、自動的に演算子をメソッドに変換してくれる
ツールを使った方が効率がいいんじゃないかね。

そういうEclipseプラグインを探してくるか、自作するのがお勧めだね。

>>248
> >>245
> それの解決は、演算子オーバロードというよりも
> EnumSetのシンタックスシュガーで逃げる解決方法がいいと思うな・・・
> 演算子の意味はやっぱり固定にして欲しいし
> >>244 で上げてる問題の解決には
> 演算子オーバロードにこだわる必要ないしな
> プリプロセッサで何とかなる程度だから、マクロでもいいんじゃない？

それなら、Jakarta Velocityの出番

>>253
なんでそこでJakarta Velocityが出てくるかなあ。無関係でしょ？
後半部分についても、俺は、ある言語内でプログラムするときに
演算子オーバーロードがあれば便利な局面の話してるのに、
別の言語使えとかツールで補えってのは答えになってないよ。

繰り返すが、俺はJavaに演算子オーバーローディングを入れる必要が
あるかと言われれば、別に無理して入れなくてもいいと思ってる。
ただ、一般論としての演算子オーバーロードの有用性までむやみに
否定するのはやめようぜ

>>157
スレタイ読め
誰も一般論として否定してない
次世代Javaには必要無いだろうと言っている

>>256
スレタイはともかく、批判してる書き込みは一般論として演算子オーバーロード
について否定してるようにしか見えないんだが。

さっきByteBufferのテストしてて気づいたんだけど
Bufferの読み込みは8バイト単位であるlongやdoubleが一番速いのな。
ネイティブオーダーのintより速くて驚いた。
JVM上の演算は流石にCPUに依存しまくりだったけどね。

64bitCPUでBigEndianであるマシンが最強になるよう設計されてるのかな

>>255
テンプレートエンジンで演算子文字列をメソッドに変換せよってことかと

>>259
プリミティブ型かどうかチェックしないとメソッドに変換していいかどうかわからんから、
それは難しくないか？変換用に既存の演算子とかぶらない演算子(例えば+@とか)
を新しく作るならともかく

+演算子を$a
-演算子を$s
*演算子を$m
/演算子を$d
と定義しておけばいい。

>>244

事務処理系や数値計算系のプログラムを書くことなど
実際やってもいないのに、勝手な想像であれこれ言うの
も説得力ないよな

>>262
俺自身が事務処理系や数値計算系のプログラムを書いたことが
無いのは確かだが、別に勝手な想像だけで言っているわけじゃない
特に数値計算系の話に関しては、「java numerical computing operator overload」
とかで検索すれば、実際に数値計算系の人たちで演算子オーバーロード
を必要としている人が少なくないことがよくわかると思う

演算子オーバーロードは乗算の交換法則とか条件別にインターフェースをシステム側で定義してもらって
それらをimplementsで使った時に（要するにシステム的にそのインターフェースの意味を固定させる規則）
可能になるなら別に文句言わない。

メソッド名の代わりに演算子も使えるとか言うC++みたいな実装への約束事無し系ならいれなくていいや派

プリミティブ型にベクトルと行列を用意してくれ

>>244 >書くなんて 耐えがたいだろう。

これが言いたいだけでしょ。
オーバーロードがあろうがなかろうがあんまり関係く
実際では違うところを改善して欲しいのに
実際に係わっている人たちのそんな気持ちなどまったく知らないのにね・・

>>265それは配列だとおもうけど、嫌なの？

>>244みたいな奴が耐え難い保守作業を強いられるコードを書くんだよな。

死ねばいいのに。

>>244は数値演算言語仕様経験が浅いな。
PID制御とか信号処理とかろくに知らんだろ

>>265
嫌だ。

Jakarta Commons Math使え。
いや、つか、Mathworksが作ったJAMA(A Java Matrix Package)を使え。
MathworksはまさにそのMATLABを作った会社だが、
Javaのことはろくにわかっていないらしく、オブジェクト指向言語としては
いまいちな仕様だ。
どうみても、Jakarta Commons MathのMatrixクラスのほうが使い勝手が良い。

x + y

という文字列を書いて、
その文字列をマウスでドラッグして、
右クリックしたらその部分だけBigDecimalまたはBigIntegerなJava文法に変換する
コードに自動変換するEclipseプラグインを作れば、
「演算子オーバロードが欲しい！」と願っている香具師の夢も叶えられるだろう。

>>268-270
君達、うざい、氏ね。 ｹｹｹ
もうここに来るな。 ｹｹｹ

これもありだろう。

Eclipseで、

BigDecimal x = new BigDecimal("100.1");
BigDecimal y = new BigDecimal("100.2");

BigDecimal z = x + y * sqrt(x);

というコードがあったら
BigDecimal z = x + y * sqrt(x);の最後の行で
CTRL + SPACEキーを押すとコードアシスト機能により、
自動的に


BigDecimal z = x.add(y.multiply(x.sqrt()));
に変換してくれる機能だ！

>>272
>>270は寛大な提案をしているのにウザイ死ねｹｹｹか。
随分と失礼な発言をするものだねキミ。

>>270は単なる宣伝じゃん！
確かにそれらはよいと思うけど、行列とオブジェクト指向は関係ないのに、
270はそれに気がついてないで勧めているのがバカ丸出し。
だから死ねとなるんじゃないか？
ｹｹｹ

でんでん！

演算子オーバーロードは、使う側からするとどちらに転んでも構わないんだが。。。
たとえば Zaiko z = Zaiko.new(0); z = z + 1; って書けるんだったら、z = 1 + z; も書きたくなるもんな。
こういうの認めようとすると primitive 型も全部オブジェクトとか、既存クラス／オブジェクトに後から
メソッド加えられるとか、かなり面倒なことになる。言語設計者側にしてみりゃ、辛い要求なんだろう。

>>275
たかがオープンソース製品を宣伝してどうする。
どこかの企業が営利目的で作ったものじゃあるまいし。

語尾にｹｹｹ付ける奴はｹﾞﾗ厨とか255とか呼ばれたﾄﾞﾄﾈﾄ厨にそっくり。

>>277
equals()メソッドの実装よりめんどいな。


・a + b が保証されるなら b + aも保証されなければならない。
・a = b ならば、 b = aも保証されなければならない。
・a = b かつ b = c ならば、 a = cも保証されなければならない。

・a < c かつ b < c ならば、 a < c も保証されなければならない。
　　　　：
　　　　：
　　　　：
　　　　：
　　　　etc...

いやまあ、上の方のレスにあるようにStringの"+"は加法じゃないけどあまり違和感なく使えている
例があるから、そこまで気にする人は少ないかも。（順序関係はちゃんとしてくれないと困るが）
あ、そういや277の例はキャストをサポートすればいいのか ＞ z = ((Zaiko) 1) + z;
せいぜいこの程度なら、俺はやっぱりオーバーロード要らないや。

しかし、デクリメント演算子やインクリメント演算子まで勝手にオーバーロードされると
困った事態に陥る。

a++と++aとの違い、これらを組み合わせた優先順位をどうするか考えないといけないからな。

ある人がC++で書いたフーリエ変換のプログラムを見たことがあるんだが、
++と--演算子を、複素数平面のディリクレ核の「回転」に使っていてビックリしたよ。
そんなふうに勝手に演算子の定義を変えるから読みづらくて困る。

このように下手なオーバーロードはソースコードを読みにくくするからねえ。

>>278 もう気が済んだだろう。この辺でいいんじゃないか。

そんなにオーバーロード欲しいなら
もう実装されている言語でやればいいんじゃないの？

どうしてそんなにJavaがいいのかな？
ケツつけたいだけじゃ
怒るよー <#`A"> ﾌﾟﾝﾌﾟﾝ !

>>251
曖昧でなく解析は出来ると思う。
C/C++ とかと違って、組み込みの単項*が無い分 解析はしやすいよね。

むしろ p+++q みたいのがあった場合、
仕様によっては p が ++ をオーバーロードしてるかしてないかで
式の評価が p + (++q) になったり (p++) + q になったりする可能性があるとか。
そっちの方が曖昧なんじゃないかと思ったりしたけど……
Javaの場合は字句構造の方で制限かかってるから p + (++q) とは読めないのか。

>>277
> Zaiko z = Zaiko.new(0); z = z + 1;
いや、流石に Zaiko.new(0) は拙いだろう。

>>282
> ++と--演算子を、複素数平面のディリクレ核の「回転」に使っていてビックリしたよ。

その手のを防止したいなら、前置++や後置++を直接定義できるようにするんじゃなくて、
二項+、に加えてincrementalValueかなんかを定義できるようにするとか。

>>73
@NIs じゃなくて @Nls じゃね？

>>287
一件一件そーゆートンデモな使い方に対する対策を考えるのは愚の極み。
最終的にオーバーロードの廃止に行き着くから。

>>277
> 演算子オーバーロードは、使う側からするとどちらに転んでも構わないんだが。。。
> たとえば Zaiko z = Zaiko.new(0); z = z + 1; って書けるんだったら、z = 1 + z; も書きたくなるもんな。

その書き方はJava似はない。 Zaiko x = new Zaiko(0)が正解。

>>284
どうせ、鬱憤晴らしをしたがってる
C#厨がJava叩きのネタの材料にしたがっているだけでしょ

>>287
増加値を定義ってのがよくわからないけど。
ややこしくなって演算子のオーバーロードは無駄っていう方向に行き着いてしまうかね

>>292
> ややこしくなって演算子のオーバーロードは無駄っていう方向に行き着いてしまうかね
無駄ってか、++はオーバーロードさせない、使えるようにはするって感じかな。
二項+とか、二項-が破壊的な動作してる場合の評価値は知ったこっちゃないって感じで。

Ｃ丼.javaでもつくれば？
文法はC#、APIはJavaのAPI、JVMで動作。

それはJavaとは異なる仕様だってことで

まっenumにしろ演算子オーバーロードにしろ構造体にしろ
C#に先を越されたJava厨が、悔し紛れに言っているやせがまんだろう。
何も買えない貧乏人が「シンプルライフはすばらしい」と意地を
張っているのと同じ、何せ金持ちゲイツには勝てないからね。
もっとも言語としてはシンプルでも、世の中の複雑な事象に適用した時、
かえって複雑にならなければよいが...
まっどんな道具でも、使い方を誤れば逆効果だが、使い方を誤れば
危険だという理由で、板前から良く切れる包丁を取り上げるのはどうか。

久々に伸びてると思ったら・・・・・宗教っぽいな・・・

ｹｹｹ

次世代JavaやるくらいならC#でいいんじゃね？？？
ね

>>296
またいってるよこいつ。enumがC#やC++のenumと同じものだと
未だに勘違いしているのかね？

愚かなことだよ。
構造体が悔しい？　アホだよそれも。@Structで十分。

>>296
Googleの時価総額がM$に追いついて、
今、Googleの破壊戦略によって追いつめられているマイクロソフトを
経営していたビルゲイツを今頃引き合いに出してももう遅い。
Googleに有能な人材を引き抜かれてばかりのマイクロソフトには
もう魅力など何一つ無い。

>>301
「Googleの時価総額がM$に追いついて」
ほんとなの？
とってもビックリ！
一応MSとGoogleは活躍する市場が違うけどね。
SUNとの訴訟後からMSは良い方に変わった印象を受けるけどな。

>>286,290
あひゃ、恥ずかしい。Rubyとこんがらがっちまった。

>>282
よく分からんが、++a が左回転で a++ が右回転？

>>296
C#な案件皆無&ツールの使い方しか分からない無能MVPな状況を
如何にかしたらいいんじゃね？

>>302
おいおい、Googleがどれだけ恐ろしい企業に成長したのか知らないのか。

M$とSunとの訴訟については、
あれはあたかもSunが負けたかのように見えたが、
結局Javaの人気は依然として高く、M$が社運を賭けて開発したというﾄﾞﾄﾈﾄは
ろくに普及していない。
その事実を隠すために、今マイクロソフトの幹部は必死になって
適当な事ばかり言っている。

>>304
あれは、a++が左回転、a--が右回転だったな。
極座標系なので

今Googleは世界第２位の企業だぜ。
Web2.0に徹底的に力を入れて大成功を納めただけある

Googleはいつもお世話になっているが、あんまり追いかけてなかったもんでね・・
ところで、MSの肩を持っているわけではないけど、
Java VMの仮想プラットフォーム化構想というべきか、
MSがその波におされて、今まで単一環境(Windows)に意地を張っていた
のをあきらめて、方向転換したように見えた。
MSがソフト販売とかではなくて、違うところに利益を求めるようになった。

つうか、ゲイツは次々期かその次位にどっかの知事か大統領あたりを狙ってるのでMSなんかどうでも良いってのが本音

クロージャ関連で

int() f = (){ throw RuntimeException(); } //匿名関数の型は null()
はエラーになるんじゃね？ って話が出てるね。

http://weblogs.java.net/blog/forax/archive/2006/09/function_that_d_1.html

>>310
それはホントか？とんでもねえ話だ。
大統領なんかにさせたらまずいぞ。
オープンソースを徹底的に叩きつぶそうと
企むに違いない。増税も平気でやるに違いない。
それに全米の大学などの教育機関でドトネトやC#を
むりやり押しつけられて、多くの学生は、授業料を払うこと＝マイクロソフトにお金を払うこと
みたいにおかしなことになる。それに、アメリカでそんなことが起きると
日本にも影響がでる。アメリカでもやってもいいなら俺たちもやっても良いはずだと、
なって日本でドトネト製品を押しつけられる。最悪のシナリオだ。

大東呂野変わりに知事ねえ。もしゲイツがどこかの州知事になったらそこの州
には移住したくないね。高い税金払わされそうだし。

ゲイツが出馬したら、世界中からG13型トラクターの注文が殺到する

MS-DOS まきかえし記念！！

>>312
馬鹿だろ、最近はもう金じゃなくて名誉が欲しいって言ってる
シュワ知事と一緒で金持ちが政治家をやれば汚職は無くなるって考えだと思った

ここにいる人たちは、Javaに詳しくても、世の中の事は詳しくないみたい・・

Javaに詳しい人っているか？
C#マスターが多数かと

ここは一体なんのスレなのかと

C#好きが未来のjavaを妄想するスレ

C#で実験させて、上手そうなのをJavaの次世代で実装すること。
C#マスターはそれに嫉妬している。
指くわえて恨めしいだけ・・

C#マスターべイターは多数いるな

演算子オーヴァーロードは、激しい賛否両論だな
デブとデブのシーソーだ

>>315
> >>312
> 馬鹿だろ、最近はもう金じゃなくて名誉が欲しいって言ってる
> シュワ知事と一緒で金持ちが政治家をやれば汚職は無くなるって考えだと思った

過去の今までの経歴と行為からして名誉を得るなんてそう簡単な
ものじゃないと思うが。汚職はなくなるといっても、ビルゲイツ本人が
やってることが汚職に近いからな。

ビルゲイツは今、今まで独占によって得た金を使って
ゴッホの日記やレオナルド・ダ・ヴィンチの手稿を買い取って
さらなる新たな独占を得ようとしているのだからな。
あのダ・ヴィンチ・コードもビルゲイツが関わっている。

ああいう資料をビルゲイツが買い取り保管することが本当に名誉になるのか疑問だ。
あちこちに寄付をしているようだが。自分の年収から差し引いた寄付の金額の割合は
他の人間と比べると大したことがない。そもそも、ビルゲイツは自分の年収の10%も寄付していないのだ。
金が有る癖に寄付金もケチる。名誉を得るつもりがあるのか疑問だ。
ジーンズを履いて反社会的な行動をとるのが好きだったビルゲイツが名誉を欲しがっているのは、
常に自分が一番でないと気が済まないという子どもの頃からの性格から来ているものだろう。

>>316
じゃあ、Javaに関連して世の中に詳しいことを
証明する語りをしてくれ。

ビルゲイツの寄付やゴッホやダヴィンチの資料を
買い取ったことについてどう思っているのかお前から聞きたい。

>>320
> C#で実験させて、上手そうなのをJavaの次世代で実装すること。
> C#マスターはそれに嫉妬している。
> 指くわえて恨めしいだけ・・

なるほど。しかし残酷だな。
ジェームズ・ゴスリングはC#が出たとき、頭が痛くなりショックで倒れてしまった
というが、今じゃ逆にC#をうまく利用しているものだな。

2chが出た後で、2chに不満を持っていた西和彦が2chに対抗意識を燃やして1chを作ったが、
全然流行らなかった結果を招いたように。

>>323
お前は自分の年収の10%以上を寄付しているのか？
まずはそれから聞こうか

>>322
昔からすでに語られて結論が出ているのに
未だにしつこく拘る奴がいるってことは、
演算子オーバーロードに潜む副作用や罠を
未だに解っていない奴が多いって事だよ。

>>326
ああ、親に寄付している。

教えてやるけど、あちこちでペラペラしゃべるなよ。

ビルゲイツが寄付したりゴッホやダヴィンチの資料を
買い取ってるのは、次世代Javaを作るためだ。

ゲイツはMSを裏切ってSunに寝返るつもりで
実はJavaをのっとるつもりなんだよ。

やつはBASIC大好きだからな。

まあBigIntegerとかそれ系にJavaが純正で対応するのはありだな

>>329
> 教えてやるけど、あちこちでペラペラしゃべるなよ。
> ビルゲイツが寄付したりゴッホやダヴィンチの資料を
> 買い取ってるのは、次世代Javaを作るためだ。
> ゲイツはMSを裏切ってSunに寝返るつもりで
> 実はJavaをのっとるつもりなんだよ。
> やつはBASIC大好きだからな。

つまんねーセンス悪ー。お前4年前と比べ煽り能力落ちたなw
お前も歳かw

>>331
お前、4年もここに居るのか。
ところで、少しはC#でも使えるようになったのか？
どうでもいいが、今からRubyやっとけ。

また演技かw

closure の続報。
http://gafter.blogspot.com/2006/09/closures-for-java-version-01.html

新しいのは
13. Definite assignment
14. Exception type parameters
15. Implementing a Function Type

12. の省略構文が statement になってる。expression じゃないので、
ブロックの終わりに セミコロンが要らない代わりに式としては使えない。

13. は、クロージャの中で外側の final で修飾された変数には代入できないらしい。
DA/DU statusってのが何か良くわからんけど。

15 で、関数型の下位型を作る構文が提案されてるけど、
その影響で新しい予約語が入るかもしれないってさ。
class MyBlock implements void(){
　public void do(){ .... } //この例では、"do"が予約語
}

なんとなくダサダサになってきた悪寒

>>334
他にも、 LocalFunctionDeclarationStatement が消えたり、
Closure の記法から FormalParameters : Expression3 の記法が消えた代わりに、
return しなくても良くなった。
(旧) int(int) plus2 = (int x){ return x+2; };
(新) int(int) plus2 = (int x){ x+2; }

4. The type of a closure を見ると、return文 で返される型を
conditional operator のルールを使って 戻り型を決めるって文章が削除されて、
クロージャが 式で終わっていれば、その式の型がクロージャの戻り型になるってなってるから、
return しなくて良くなったというよりも、むしろ return しちゃダメなのかも？

9. Referencing names from the enclosing scope の note の内容も変わってるね。
クロージャから参照されるローカル変数の寿命は宣言したブロックより長くなるって。

10. Non-local control flow から NamedReturnStatement の構文が消えてる。

>>334
もいっこ。

>>311 が言ってるのと関係するかは判らんが、
int を返すクロージャを Integer を返すメソッドを持つ interfaceに変換したり、
逆に Integer を返すクロージャを int を返すメソッドを持つ interface に変換
って事も考慮中、みたい。

>>337
と、いうことはクロージャってのは特定のインタフェースを表現するシンタックスシュガーって
ことだね。

アノテーション型のように

>>338
> クロージャってのは特定のインタフェースを表現するシンタックスシュガー
それは全然違うと思うが。

annotation も interface の構文糖じゃないし。

ちょっと治が売ってか。

@interface と書いてアノテーションを宣言するが、
実際には Annitationインタフェースを継承したのがあのてーしょん型に
なるというやつ

>>340
注釈型の定義は構文糖じゃないぞ。

手動で java.lang.annotation.Annotation を extends する interface を書いても注釈型にならん。

それでもinterfaceに@をつければアノテーション型になる

それはシンタックスシュガーとは言わない

>>343でFA。

closure の続報。
http://gafter.blogspot.com/2006/09/nominal-closures-for-java-version-02.html

関数型(function type) の記述が削除された。
synchronized と言う限定子を与えると、従来の匿名クラスのように
取り囲まれたメソッドの final をつけた変数しか触れない。
常に中途完了する closure の戻り型は null の代わりに Unreachable を使うようになった。

jdk6ってb98のまま二週間放置されてるぜ。
いつb99でんだ？

10月に100かつ正式版とするために引っ張ってるんだろ

>345
ClosureConversionが発生しないときどーすんだろね、これ。
　Class c=(int x){ x+2 }.getClass( );
とか。

>>346
定期ビルドは終了の模様。
次にＤＬ出来るのはリリース候補らしい。

>>348
2. The type of a closure のところに
> It is a compile-time error if a closure is not subject to a closure conversion.

とか書いてある……

>>345
関数型無いのに Unreachable 使う必要あるのかね？

関数型があるなら
Unreachable() func = (){ throw new Exception(); };
int() func2 = func;
Object() func3 = func;
ってできるから必要があるのは分かるけど、

関数型無いと covariant return type を考慮しても
Unreachable は 全ての型の下位型と規定されているので
interface F{ Unreachable func(); }
interface F2 extends Func{ int func(); }
interface F3 extends Func{ Object func(); }
とかやっても、 F2 はプリミティブ型なので covariant return types
の対象にならないからコンパイル時にエラー
F3 は Object は Unreachableの上位型なのでコンパイル時にエラー

>>351
interface F<R>{ R func(); }

F<Unreachable> f = (){ throw new RuntimeException(); }
F<Object> f2 = (F<Object>)(F)f;

とかしろって事なんだよ。 未検査警告出るけど。
後は、戻り値が Unreachable だと常に中途完了する事がコンパイル時にわかるとか。
今気付いたけど >>345 のリンク先、8. が二つあるね。

>>349
http://blogs.sun.com/mr/entry/java_se_6_schedule_update
とか読むと、10月の終わりに release candidate が出て、
11月の最終週が感謝祭の休みなので、
正式版が 12月の第一週とは書いてあるけど、
weekly build が終わりとは書いてないような。

とか言ってる間に b99 出てる……

SwingがODFに対応するのはいつごろですか？

クロージャによる関数型は
enumみたいにjava.lang.Enumクラスのシンタックスシュガー
みたいな感じになるのかな？
実際には匿名クラスを実装したオブジェクトになってるだけとか。

>>355
まだ検討中の段階だろうから、最終的に どうなるかは誰にも判らんと思うぞ。

一番最近の案っぽい >>345 のリンク先のクロージャは、
匿名クラスのシンタックスシュガーになりつつあるようにも見えるけど。

> enumみたいにjava.lang.Enumクラスのシンタックスシュガー
これはシンタックスシュガーって言えるのかね？
言語規定で class MyEnum extends Enum<MyEnum>{} はできないって決められてる。
>>338 みたいにアノテーションが interface のシンタックスシュガーだって言うよりはマシだと思うけど。

> 匿名クラスを実装したオブジェクト
日本語かJavaかどっちかの勉強が必要だね。

もうJavaの時代はおわり

そして永遠にやってこない.NETの時代

永遠にやってこないドットネット

>>359-360
ジャヴァー乙

.NETが日本で最も普及しているプログラム言語
http://pc8.2ch.net/test/read.cgi/tech/1156986942/

>>361
リンク先のおっちゃん、ブッシュとクリントン足したような顔

>>361
お前必死すぎ。そのスレも見事に論破されてるし

Java6で実際使いそうなのはStAXとタスクトレイくらいかな。
特にStAXはシナリオ駆動型のプログラムが作りやすそうで楽しみ。
Java6の拡張は地味だなぁ・・・

偶数バージョンは小さく、奇数バージョンは大きく変える方針じゃなかったっけ？

J2SE1.3はそんなに大きく変わったか？

これからの話だよ

ベリファイ処理の高速化・エスケープ解析の導入とか、
ＶＭレベルの変更が多いから確かに地味なのかもなぁ

>ＶＭレベルの変更が多い
1.4>1.5の時に比べて多いか？
むしろapiの強化がメインな気がするが。。。

つか、プロセス管理は魅力的。


並列処理つかグリッドコンピューティング分野でも
さらなる強化が施されるのかな？

>>366
かなり大掛かりな改良はあったよ
おかげで業務で使えるようになったのは1.3からでしょ

AWTの糞仕様というかバグを大幅に直したのも1.3だね

>>372 1.1から1.2ならそれで分かるけど、どういうこと？

1.3からはSwingが追加されたし

Java Sound APIも追加された

1.3での改善点、新機能

個人的順位

１・hotspotVM　搭載
２・JavaSound　搭載
３・シリアライズの大幅な改良
４・Swingの改良
５・JNDI　搭載
６・AWTの改良
７・ネットワークの改良
８・マルチモニタ対応

Swingが実用的になったのは1.3からで、わりと業務アプリに使われるようになった。
ずっとSwing触ってきた身としては1.4.1時より個人的にはインパクトが大きい。

個人的には1.3がいわゆるJavaのひとつの完成形とみている。
この後は速度や機能が現実的な実装中心になっていく。
言い方は悪いが1.2まではRC品質というか。

何というか、この程度なのか・・

申し訳ないが、世間一般では1.3でなくて、
1.2がJava（やご指摘のAWT）が大きく変わったんじゃないか？
それを示すのに、jdk1.2 でなくて j2seとか名乗ってたと思うけど。

1.2なのにマーケティング的な観点でJava2とか言ってたしな。
終わってるよ。あの発想。

>>377
1.4よりインパクトあるんじゃね？
機能的には1.2が一番インパクトはあると思うが、速度低下メモリ使用量拡大といいことがなかった

>>379
Sunのメジャーバージョンアップは昔から0.1単位
だが、1.2だと大幅なバージョンアップに見えないので「２」をつけた

1.3からJ2SE,J2EE,J2MEの3種に明確にわけたというのは大きいかも

>>380 なんだね？こだわりがあるようだが、君は関係者なのかぁ

ここにいるやつはみんなJavaさわってる関係者だろ

こう考えるんだ。1.4.2が使われすぎてて過去の印象が薄い。

1.2かぁ
Swingアプリの動きがマイナーバージョンで違ってたりして
あんまりいい印象ないぞ
たとえばウィンドウの表示位置に一時マイナス値を指定可能な時があった
Xウィンドウユーザならお馴染みの方法だね
だがあっさり次のマイナーアップでこの仕様は取り消されてしまった
おまけに1.3にしたら警告を吐くようになり
1.4ではついに画面すら出なくなったのだ
Swingの互換性なんてこんなもんだ

Javaに限らず、米国産のモノなんてそんなもんだ。

Java７は中止して全OSの互換性向上に予算を費やした方がいいな

みんなそろそろ次世代に目を戻そうぜｗｗ

とはいえ、b99以降でてこんし、Dolphinもビルドないしなぁ

俺は1つのVMで複プロセス立ち上がるように改良されるのをずっと待ってるんだが…。
その時こそ、真のJavaの時代が来ると言える。

複プロセス実行可能ってJava7で採用されたんだったっけ？没だっけ？

>>388
JSR-277と291がらみの話?

?
ヒープ共有のことだろ？

てかヒープ共有は逆か。
複数のプロセスでVMを共有できるってやつか

>>376
JDBCが標準で追加されたことも重要だったりする。
Servletが流行りだしたのは1.3が出る頃だったからね

>>380
1,4よりはインパクトあるね確かにに。
1,4はassertが追加されたとか、メソッドの
オーバーライドで戻り値の型が異なってもかまわないとか。
大した変化はなくAPIが追加されたくらいだね。
XMLとか

>>381
昔からJavaをやっていた人間ならそれくらい知っているって。
Javaという言語の理想に惹かれて、早くからJavaに
触れた人間ならとくに。

>>383
新しいものが出ると、過去のどうでもいいものは
忘れていくんだよね。
脳みそがそう処理させてくれる。
余計なことは忘れろって、脳みそが指示している。

忘れるべきでないと思っている人は、本を書いている人とかだね

>>380
そのことを、Wikipediaの「Java言語」に書き加えておくと、なおよいと思うよ

>>384
それも1.5から改善されたろ。

しかし1.2からプログラミングしている香具師は、
import宣言に*をつける癖をつけているとろくなことが
無いんだな。
Java Pressの何月号かにそれ系の注意事項が載っていたな。
1.5から一気に5.0にアップグレードすると動かないプログラムでの
対策とか。

>>388
それはJava6で実装されるのでは？

Javaで本格的に組み込み家電プログラミングできる時代は
まだやってこないのかのう・・・

>>395
おまえ、さっきからいいことばっかり言ってるな。
おれには、どれが誰の発言か分かるぞ！

>>398
されないだろ

>>388>>398>>401
これのこと？
ttp://www.itmedia.co.jp/news/articles/0404/07/news018.html

JSR 121: Application Isolation API Specification
これか？

>>397
1.5から5.0？

>>393
1.4は現実的な実装がポイント

大幅なVMの高速化、積極的なアクセラレーションを意識したAPI群
クライアントサイドアプリの改善、JAXP標準装備、印刷サービス追加、NewIO追加

速度を意識したのがたくさんでてるよね
5.0では並列APIと言語仕様以外は新しい機能はあまりない

>>402
「J2SE 1.5では、Javaプログラミングの簡易化に焦点を当てている」

新構文とかでバグ減るし開発効率アップでいいことだらけなんだが
APIマニュアル読めない難民が続出してなかなか移行が進んでないというのが面白い

なかなか知っている。それで、次は何を期待するのかな。
ところで、APIマニュアルって何のこと？
>>404

>>404だけに、SUNのAPIリファレンスがダウンロードできなかったんだろうな。

>>404
1.2から5.0の間違いだった

>>405
>>404じゃないが、Generics使ったライブラリのAPIドキュメントのことじゃないかな
それだったら、読めない人が出てもおかしくはない、かも

APIとマニュアルという事か。
確かに5.0を解説した本はそれほど多くないからな。

JavaWorldオンラインにいい入門ページがあるよ。
確かにGenericsと並行ライブラリだけって印象だね。
Java6はJVM弄るらしいし、Java7は確か命令も増やすんだよね。

>>409
新構文2年以上雑誌やネット等でやってきたのに少ないとは

英語読めれば本家に行くしさ、
ネットだと知ったか振りの解説じゃないか？

しかし、無料のネットならそれでもまあ調べてみようとするのも分かるが、
有料のくせして質が悪い記事しかない雑誌じゃ・・

それも「雑誌」かよ・・

もう雑誌記事もブログ・HPも同じようなもんだし、記者の質も落ちたしな・・
その程度の情報を詰め込んでも、単行本一冊（ブックオフで500円のとき）
より高いんじゃあんまり買ってまで見る価値ないと思う。

>>410
> Java7は確か命令も増やすんだよね。
invokedynamicのことか。あれって、Pnutsの戸松さんがブログで反対表明
してたけど、どうなんだろうね。なんでも、invokedynamicだけあっても、
あまり性能は改善しないだろうとか。
ttp://d.hatena.ne.jp/tomatsu/20060329

↓じゃあかんの？「雑誌」の無料の散文だが十分だろ
ttp://www.javaworld.jp/technology_and_programming/-/18161.html

>>415
そういうことではないと思うよ。
雑誌一般の話じゃないか？

>>414 その人が影響力あるのはわかるが、文句が言いたいなら、JCPに参加してそこでやるべきだと思うが。

1.4も5も、6に比べれば大進化
6はぶっちゃけ中身なさすぎ

だから５が出る頃に、これから言語仕様を変えるのは
奇数バージョンにするって言ってたじゃん
18ヶ月毎に新しいバージョンを出していく計画だから
36ヶ月毎に言語仕様が変わるくらいならみんなついて
行けるだろうと考えたってわけだよ

６の目玉はDesktopとConsoleくらいしかないな

>>28
比較のStringの生成、どっちが計算コストが高いと思っているんだ？？

比較とStringの生成？
後者ではないの？

>>409
だね。
アノテーションんとGenericsのテクニックを把握するために

Effective JavaのJava5版が欲しい。
あれでEnumの説明も省かれるだろうし。
Genericsのテクニックがいくらかでるはず。ゴスリングは
新規にクラスを作るときはGenerics対応にせよって逝っているし。

>>413
それは日本だけの場合だよね。
英語なら、さがせば良い情報が
何十倍にも膨らむと思う

>>415
それだとアノテーション型の使い道/自作、Genericsクラス作成のテクニックやノウハウが載っていないんだよな

>>418
5への進化は今までの進化とくらべたら凄まじいものがあると思うぞ

>>420
JapansesEmperorCalendarがあるだろw

>>423
> Effective JavaのJava5版

出るらしいよ。来年中ってことなので、まだ結構待たなきゃならんみたいだけど
ttp://journal.mycom.co.jp/articles/2006/05/18/javaone2/

>>427
マジで皇紀入ったの？

>>430
既にスナップショットにも入ってんじゃないの？
誰か使ってみて

java.netのjdk-6のページって全然更新されないね

>>429
皇紀じゃないみたいよ
明治、大正、昭和、平成だけ扱えるカレンダーw

>>427
Formatterに実装されてないんじゃなかった？
ならいみねぇよ

>>425
sunの本ではannotationを自作で局所的に使用するのは進めてないよ
どっちかてとライブラリーとかでサポートされるイメージでしょ

genericsは確かにデザイン的な教科書が欲しいところ

>>431
どうせなら全部やって欲しいよな

>>428
だからそれがJava5版の元ネタソースだろ。

しかし、日本語版がでるのを考慮するとさらに時間がかかるのか。

英語でも良いのでネットでこういうテクニック情報手に入らないかな？

>>434
そんなに使うこと有るのか？
どうせ過去の年号なんて一年二年ずれてたり、
鎌倉幕府ができたとしが1192年かと思ったら全然違う年に
できたことがわかって教科書もかわったし「いい国作ろう鎌倉幕府」
なんて暗記もまったく役に立たなくなった。

しかもCalendarクラスで扱えるのは1960年くらいからだしな。
long型の範囲内でしか使えないんだし、情報に正確さが
求められていない時代の何千年前の過去のデータなんていらんいらん。

今あるJavaプログラムが1000年後にあるかどうかっていうとそりゃ疑問だが

Javaって2038年問題は対応済みだったっけ？

Javaのユニックスエポックの実装は符号付64bitだよ。
それって32bit機のC言語の実装に依存する問題じゃなかったか。

BREWが対応していないことだけはわかるんだが
Javaはどうだったろう

>>438
じゃあ、大丈夫か

>>436
おまえ、早く消えた方がいいよ。

ほんとかな
それってJavaが動作するUnix系OSの実装に結局依存するんじゃ？
とはいっても昨今のは大丈夫だろうけど
2038年には隠居してるからいいか

OSそのものの実装によるってのはあるかもな。
でもそれならOSが対応してれば自動的にJavaも対応済みって話だ。
迂回コードを書いてレスポンス落とすよりはそっちを待とう。

予定日とかで2038年以降を設定したらアウト？

BSD系のマニュアル見るとgettimeofdayシステムコールが使う
構造体の定義はlongになってるからこれならほぼ永久に問題ない

struct timeval {
long tv_sec; /* seconds since Jan. 1, 1970 */
long tv_usec; /* and microseconds */
};

しかし実際のヘッダーはこう
これだとアウトだな

struct timeval {
int32_t tv_sec; /* seconds */
int32_t tv_usec; /* and microseconds */
};

結局64bit系OSに早く移行しようということだな
2038年特需に関われる香具師は楽しみだな
また正月からホテルに缶詰か

>>441
なんで切れてんの？

JapaneseImperialCalendar の間違いだなエンペラーじゃなくてインペリアル

しかしさ、和暦って使い物にならない点がひとつある。

今の平成天皇が死んだらまた変わるんだろ。
面倒くさくてやってられない。官公庁向けだろうから使わないけどさw

旧暦もめんどうだな。閏月って特定の法則があるんじゃなくて、神社が決めるんだろ。

>>448
たしかにな
今上天皇が崩御されたらシステム対応大変そうだ
Java VMはたぶん上げないまま放置されてるシステムだろうから
その時Sunが新年号を旧VMのために対応してくれるかどうか

神社の気まぐれで決まるようなものをコンピュータに
採り入れるのは危険だな。

>>450
VMだけアップデートすれば自動的に年号がかわるシステムになってるとかだったりしてな

それをいったら西暦だって宗教のきまぐれだろう

てかそういうのって普通政府が用意するもんじゃねーの？
IPAの未踏とかに出すより余程低予算で有意義なプロジェクトだろ。

政府に介入されたくないな

>>448
お隠れになったって書かないと朝鮮人認定されるぞ

>>456
ゆとり教育で教えなくなったから、日本人と区別がつきにくくなった。

とくに中国擁護には介入されたくないとおれは思う

>>456
マジで？　知らなかった

>>457
教えてたのっていつの時代の話？
俺、そういう表現があること自体、初めて知ったよ。。。

お隠れになったを知らない？
俺も習った覚えはないが知ってるけどな

何のスレだったっけ。

>>462
次世代javaのお隠れｽﾚ

>>456
それを言ったらおまえ、今上天皇が「平成天皇」になるのは御隠れになった
あとなんだが....

こういう流れになるとはなぁ

皇族に男子ご誕生万歳！！

そこで「マンセーじゃねーか？」などぬかす奴、ちょっと裏まで来てもらおうか

昔は昭和天皇が今上天皇だと思ってたよ

>>56

今上ってのは現在在位中の天皇という意味だからほんとは今上天皇ってのも冗語だな。

本当は「天皇陛下がお隠れあそばされましたら」だ臣民ども

ちゃんとした言葉使わないと朝鮮人だよばわりされるっていっても

天皇家って1000年も前から朝鮮人の血がつながってるんだろ。
1000年前に半島から渡ってきた女の血を引き継いでいるのが今の天皇家なんだし。

伊邪那岐神 (いざなきのかみ) と伊邪那美神 (いざなみのかみ) の子孫だよ

いざよいの間違いでは？

なんかもう、なんだこのスレ

>>473
[mustang] 次世代天皇の動向 3 [dolphin]

２ちゃんらしくていいじゃないか

珍しくマンセーがこなかったな。
いいことだ。
個人的なことで恐縮だが、シナとかチョンはなんか臭いからな。

どうでもいいのではよリリースしてほしい

>>477 ソースは？

ウ

ス

そうか、JDK6の目玉は和暦対応か

>>481
お前！タだろ、そこ
台無しだよ、もうorz

タ

>>476
ああ、中国人や朝鮮半島人三国人はウザイ。

だから今後も俺は阿部・小泉を支持し自民党に投票し続ける。

もう中国人や朝鮮人・韓国人にはなにもあげないし
なにも奢ってやろうとも思わない。

日本に来ては日本人子供や恩人を殺す犯罪者が多いし
泥棒はするしスキミングはするし。電車では人の座席は奪うし。
ウザイから彼らにはもう何も与えてやらない。

>>481
マジレスするとGUI強化

>>484
三国人と書くなら、台湾人も書かなきゃ。

>>484
自民党に投票すると、お前が何ももらえくなるぞ。
税金の仕組みとか知らないだろ？
お前から吸い取り、奪い取って、
大企業や銀行・政府よりの関連企業に還元されているじゃないか？

>>485
そんなにかわるか？

>>402
俺のブックマークではこれかな
ttp://research.sun.com/projects/barcelona/
ITmediaの話は、クラス共有までにとどまっているんじゃないかと。

System.exit問題を何とかしないと駄目だかんね。

>System.exit問題
って何？

System.exitはVMを終了させる。
VM共有してると全部一蓮托生。
ってことかいね。

サーブレットコンテナも同じような問題抱えてるけど。

1つのプロセスでVMは複数立ち上げるということであれば問題ないんじゃね？
VM１つで1プロセスだと共有も限界があるが同一プロセスならなんとでもなるだろう
じゃないとシングルトンとかstatic使ってるところすべておかしくなる

なにも問題はない

>じゃないとシングルトンとかstatic使ってるところすべておかしくなる

tomcatは大丈夫だけど？
classloaderいじってあれば大丈夫なんじゃないの？

>>493
それクラスローダいじってる場合だろ？
VMレベルってことはブートストラップからなんだからまた違う話

VMひとつで複数アプリは問題あり
そもそもWEBアプリ部分はmainからスタートしねー

>>487
だからおれも経営者になるのさ。
まずは個人事業主から始めて
次に独立を狙う

>>494
mainから動かしたけりゃServletなんか使わなきゃいい。

>>496
話の流れみてくださいね

>>494
staticとかシングルトンで問題って例えばどんな問題？

>>498
隣のアプリが初期化したシングルトンオブジェクト握ってたら
２つめのアプリが動かなかったりしてな
セマフォとかトークンみたいな使い方だからシングルトンならではってわけでもないが・・・

やっぱ基本的に、クラスローダはブート時から別、か
アプリによって違うバージョンのライブラリに依存してたりするし

>>499
tomcatみたいなクラスローダーのシステム導入すればいいってことでしょ、結局。

exit問題は、個人的にはまぁいいんじゃね？と思ってるけど。
心配な場合はsecurity managerでどうにかなるんじゃないかなと。

>>500
で、そのあたりJSR-291でIBMがOSGi4を取り込むことを提案してるけど、
Sunが「OSGiですでに規格化されてるんだからSEに取り込む必要あるの?
とりあえず反対票いれとく」ってのが今年の3月の状態。9/1にJSR291のEDRが
終わったからそれがどうなるかはわからん。

IBMはWebsphere/Notes/Rationalと大体OSGi4(というかEclipse)ベースに移行済みだし、
ApacheもFelix立ち上げてtomcatをOSGiベースに移行したいみたいだし
J2ME以外でもOSGiフレームワークの有用性はあると思うんだけど、
OSGiベースのクライアントを推進するEclipse参加企業連と反対
するSunって感じになって政治的にきまっちゃったりして。

独立目指すのもいいが、今度は世間の荒波に揉まれて、
今度はお前が嫌な上司になったりシナやチョンを雇ってみたりするんじゃないのかね…
ｹｹｹ

>>486
台湾人は戦勝国人でしょ

日本人は敗戦国人と言いたいのか？

>>501
OSGiです
まで読んだ。

三国人=戦勝国でも戦敗国でもない第三国のひと

魏呉蜀の人の事だろ？

第三国人
　第二次大戦前および大戦中、日本の統治下にあった諸国の国民のうち、日本国内に居住した人々の俗称。
　敗戦後の一時期、主として台湾出身の中国人や、朝鮮人をさしていった。
　[大辞林]

>>507 お前、三国志好きなのか？三国志板あるぞ！

>>508
その解説は間違い。

戦後、戦勝国人を名乗って暴れていた韓国人、朝鮮人を抑えるために
マッカーサーが「おまえらの国は戦勝国じゃなくて第三国じゃ」と
言ったのが起源だよ。

従軍慰安婦、南京大虐殺30万人説、三光作戦…
日中戦争や韓国併合に関する大手出版社の
解説には間違いが多い。

結構調べてるな。次世代の日本の事ばかり。
ところで、まだチョンやシナが来ないけど
平和とはまさにこのことだな。
いいことだ。いいことだ。

>>510
それは、全くのウソ。マッカーサーにそんな発言はない。

もともと俗語で、犯罪行為を行う朝鮮人や台湾人をさし、
戦後、日本の警察・マスコミ・官僚・政治家が使い始め、
広めた言葉。

>>502
それよりお前Java質問スレ荒らすなよ

>>513 よく覚えておけ！なんでも人のせいにするな！！

>>501
なんでsunは反対してるの？
netbeansとeclipseの関係上？

>>501
JSR277でいーじゃんってことね。
こっちはどーなってんだろ

>>501
OGIS総研がどうしたって？

>>502
おい、三国人、何やってんだお前。
つか、お前はその上司にすらなれないんだろ。
ん？　お前は上司に嫉妬するダメ平社員か？

C#マンセーしてJavaに演算子オーバーロードを
つけることを強く勧めていた馬鹿だろお前。
それにJava質問スレをAAで荒らして今でも懲りて無いという。

>>514
文体からもうお前が誰だかわかってるんだが。

死滅スレで大暴れしていた餓鬼だろ。
Java質問スレでは「ゆとり世代は犯罪者が多い」
と言われたら逆ギレでスレを荒らしていたよな。
あれからＪａｖａ質問スレにサザエさん一家のAAを貼り付けて
「馬鹿質問者！」を連呼するようになっただろう

JSR277のプレゼンによると、
super package com.2ch.xxxx
とか
export com.2ch.xxx
みたいな表現が出てきてますね。意味はよくわからん

>>517
寒いよお前

始めてOSGiという用語を知ったときOSI参照モデルと間違えそうになった。

JDK7からは.jarに加えて.jamができるようだよ

>>520
super package?

あくまで憶測だけど
パッケージにも継承の概念をとりいれたということでは？
二つのパッケージの間には継承の関係がある、みたいな。
『アジャイルソフトウェア開発の奥義』にそんなのが載っていたようなきがする。


にしてもexportってのが気になる。
importの逆か。

>>523
jamって携帯電話のあのフォーマットが標準化されるってことですか

.jam = JAva Module
らしい。

super packageについてはMYCOMに記事が出てるよ。
ttp://journal.mycom.co.jp/articles/2006/05/18/javaone3/

要するに、 JavaにもPerl Module(.pm)みたいなものを作ろうという話
だと思う。

複数のパッケージをモジュールとして一つにまとめて、どのサブパッケージ、
どのクラスを外部に公開するか決められるとかそんな感じかな。

Win風に言えば、DLLでその関数を外部に公開するか定義するみたいな。

その部分が「export」とかいう部分だと思う。

>>527
つまり、今のprivate,protected,publicとかとjarだけじゃ
使いにくいぜってことか。

あ、importがモジュール単位でできるようになったら便利かな。

>>527
> super packageについてはMYCOMに記事が出てるよ。
> ttp://journal.mycom.co.jp/articles/2006/05/18/javaone3/
> 要するに、 JavaにもPerl Module(.pm)みたいなものを作ろうという話
> だと思う。

なんか違うような。そのまんま『アジャイルソフトウェア開発の奥義』に載ってる
ことを実践しようとしているだけだと思う。

SE 6の split verifierってどんくらい効果があるんだろうか？

>>527
この宣言、import宣言を短縮できるってことかね？


super package com.sun.myModule {
// super-package exports:
export com.sun.guild.myapi.*;
export com.sun.guild.util.Helper;

// super-package members:
com.sun.guild.myapi;
com.sun.guild.util;
com.sun.guild.impl;
}


import com.sun.myModule;
と書くと
一度に
import com.sun.guild.myapi.*;
import com.sun.guild.util.Helper;
宣言しなくても一行で済むってことかね？


あと、JSR 277として仕様が提案されている「Java Module System」とこれはまた別ものみたいだね。
あれはＪＡＲファイルの扱いってことで。

JSR 277 「Java Module System」ではJARの中にJARを入れる
ことができるってことだね。
今までOne-JARかFatJarに頼らざるを得なかっただけに。
よって、Perl Moduleとは関係なさそうな気がする。

あと、新しいJava モジュールシステムは
バージョン違いによるコンフリクト問題も解決するそうだ。
RPM(Redhad Package Manager)の依存関係みたいなもんかね？
それか、Fedora Coreで使われているWindowsUpdateライクな
yumでrpmを管理できるような仕組みとかできんのかね。

PM(Perl Module)というより、CPANモジュールみたいなもんかね？
するとApache Mavenで使われているJakarta JJarをJavaで標準装備するってことかね？

よくみるとJava Moduleという新たなフォーマットが生まれる可能性があるということか。
JNLPファイルのようにメタデータ情報を記載しておくってことか。

たとえ依存関係にあってもバージョンが異なれば、依存できないようにするとか設定できるわけか。
まさにRPMそっくり。JavaレベルでRPM同等のことができるとは、嬉しいことだね。
これで、Jakarta JJarやApache Mavenの仕様も若干かわることになるかな。

さらにJARの名前空間もサポートするとは。
バージョン管理されたマシン上で保存、探索のためのリポジトリもサポートとは。
モジュールのインストール、削除もサポートするのか。
ランチャー、クラスローダ探索のサポートか。モジュールチェック。

これだと、ＲＰＭどころか、yumやCPAN, JJarに似てくるってことか。

というか、Open Services Gateway Initiative (OSGi)を使うところが
Eclipseのアップデートマネージャみたいだね。あのプラグインフレームワークがJavaで
標準で使えるようになればかなり大きな進化になるぞ。

JSR 291 - 初期レビューフェーズをクリアするも波乱の幕開け、IBMほか (MYCOMジャーナル)
後藤大地 2006/3/17
http://journal.mycom.co.jp/news/2006/03/17/343.html

Java Community Process, JSR 291 Expert Groupは14日(米国時間)、
「JSR 291: Dynamic Component Support for Java SE」がJSR Review Ballotの
ステージを通過したことを発表した。投票期間は2月28日から3月13日(米国時間)まで。投票結果は次のとおり(全数16)。
　 * 賛成 11
　 * 棄権 0
　 * 反対 4
　* 投票なし 1

　「JSR 291: Dynamic Component Support for Java SE」は、既存のJava SEプラットフォームに対
してダイナミックコンポーネントフレームワークのサポートを規定するもの。OSGiから提供されてい
るダイナミックコンポーネントモデル仕様をベースにして策定が行われる予定になっている。
　初期レビューのフェーズはクリアしたが、Google、JBoss、Suleiman, Sun Microsystemsの4社は
反対を表明している。「JSR 291: Dynamic Component Support for Java SE」の策定に賛成しなかっ
たメンバーの主な反対理由は次の通り。

　 * すでにOSGiから提供されている仕様があり、それがすでに十分なものであるなら、わざわざJCPにお
　　ける認証プロセスを経てJSRに策定する意味があるのか
　* 「JSR 277: Java Module System」においてJavaにおける次世代モジュール仕様が定義されており、
　　OSGiにも適応することができるように努力している。別途JSRを用意する必要はないのではないか
　* OSGiと重複した規格を策定することはOSGiを軽んじることなりはしないか
　* OSGiを参照するように明示するだけで十分ではないのか

　JSRにおける他の規格との重複、JSR以外の規格との重複が指摘されたものであり、賛成/反対とも、
提出されている意見が興味深い。賛成を表明したメンバーも、OSGiやJSR 277にふれ、意見を述べている。
　JSR 291のスペックリードはIBM, Glyn Normington氏。Expert GroupにはIBMやIntelをはじめHall, Richard S.、
Hedman, Niclas、Kriens, Peter、Nortel、ProSyst Software GmbH、Snyder, Bruceがエントリされている。
半月ほどでエントリが倍になったことになる。

こんなニュースがあったとは。
Googleが反対しているところが気になった。
それどころか、Sunも反対とは。

IBMが推しているのは、Eclipseの
プラグイン管理がOSGiフレームワークに基づいているからかね。

統合開発環境プラグインAPI - JSR 198、4つの棄権も可決 (MYCOMジャーナル)
http://journal.mycom.co.jp/news/2006/02/25/360.html

JSR 198は、16中10の賛成を得て可決されたが、棄権に付随したコメントは、
このJSRの今後の展開について重要な示唆を含んでいる。代表的な統合開発環境
がJSR 198に対応した場合、たとえばEclipse IDE向けに開発されたプラグインであっ
ても、そのままNetBeans IDEで使用できるようになると期待されているが、どれだけ
実現されるかは今後の展開にかかっているといえる。



これってかなり重要だな。


EclipseのプラグインがそのままNetBeansでも使えるようになることは俺が夢見ていることだ。

>>536
J2MEにはJSR283でOSGiを導入しているから、OSGiですでにあるからとか
いうのはおかしい話だ。

Closure の文法の別案(?)が出てるね。
http://www.writely.com/Doc.aspx?id=k73_1ggr36h

これといって「何だぁ？」っていえるような文法が見あたらないね。

new Thread(new Runnable() {
public void run() {
foo();
}
}).start();

が
new Thread(Runnable(){ foo(); }).start();
に変わるってのが特徴なのかな？
しかし、run()メソッドの中で使っているってどうやってわかるんだろう。
約束事になるってこと？

それと気になるのはfor文の中でpublic が使えるようになっていることだね。

" for (public int taskId = 0; taskId < NUM_TASKS; taskId++) {
executor.execute(Runnable(){ newTask(taskId); });"
http://www.writely.com/Doc.aspx?id=k73_1ggr36h

>>541
ちゃんと読んだ？for文でpublicが使えることが重要なんじゃなくて
publicをつけたはclosure内から参照＆書き換えできるようにしようって話だよ。

Neal Gafter の blog にも面白いのが出てきてるね。
http://gafter.blogspot.com/2006/10/iterative-control-abstraction-user.html

>>543
なんかややこしいな
Mapをループで楽に扱うなら
for(String key,String value: map)
みたいに拡張for文をさらに拡張したほうがわかりやすいと思うのだが

>>544
問題は Map 以外に使い道があるかって感じかな。

拡張for を更に拡張してくのは、基本的に言語を肥大化させる方向性。
>>543 のは複雑になるけど、どちらかと言えばライブラリを肥大化させる方向性。

どちらかしか選べないなら後者を支持するかな。

もうMapはkeySetをイテレートでまわしてvalueでまわすのになれちまってるからなぁ

確かにほしい場面はあるが・・・

>>542
そんな仕様になったら、名前空間がどうなってしまうのだろうか。
グローバル変数のような事態に陥ってしまいかねないか？

>>546
valueがほしいときにkeySetをイテレートでまわしてからとるのと
最初からentrySetをイテレートでまわしてからとるのとでは
速度にかなり差があるよ。わかっててやってるならいいが。

>>548
実際に速度はかってみたの？

>>549
はかってみたから言ってんだろ、ボケ

計らなくても分かりそうなもんだが、、

LinkedHashListでvalues()してたら何のこっちゃだからな
ここらでオブジェクト指向を感じるときもしばしば

>>550
で、どれだけの速度差が出たの？

行列演算みたいに
内部でpivot操作できるようになっていれば
従来通りのやり方でも高速になるんだがなー

>>553
俺は >>548 じゃないが、Map まわすときの常識だ。
entrySet を使わない奴はその存在を知らん初心者だけ。
速度差なんか要素数で変わるが、keySet で回して value
取り出すほうが遅いのはあきらか。

Mapとリフレクションを上手く統合（？）できないもんかね。
アノテーションとかあるし何かいい方法がありそうなもんだが。
POJO相手にリフレクション使う最近のフレームワークを見て思う。

>>555
拡張forつかわないのならいいのかもしれんがね

>>557
>拡張forつかわないのならいいのかもしれんがね

for (Entry<K, V> entry : map.entry()) {
  K key = entry.getKey();
&nssp; V value = entry.getValue();
  …
}

ってするだけですが。

いろいろ間違ってたので書き直し。

>>557
>拡張forつかわないのならいいのかもしれんがね

for (Entry<K, V> entry : map.entrySet()) {
  K key = entry.getKey();
  V value = entry.getValue();
…
}

ってするだけですが。

>>557
このスレに来る前に現行 Java のことを覚えてきてくれ。

アノテーションでJavaソースコードやパッケージにバージョン番号を
つけて、依存関係にあるJARファイルのチェックをしたい。

どうすればいい？ そして最新のクラスだけ使用したい。

Java Module Systemが登場するまでこれはうまくいかない？

拡張forで複数のiteratorまわせればいいんだけどな

List<String> list1 = 省略
List<Integer> list2 = 省略sizeはlist1と同じ

for(String str:list1 , Integer i: list2){
//省略
}

みたいな

つまり、クラスパスにはすでに古いクラスが入ったJarファイルa.jarが通っている。

あとから、b.jarを入れた。このJARはa.jarに依存する。
しかし、このb.jarは、最新版のa.jarに依存しており、古いクラスが入ったa.jar
には依存できない。今、b.jarは最新版のa.jarを欲している。

ここで最新版のa.jarを入れてみたいが、古いa.jarが他の会社のプログラマが
入れて者で、上司に「ここは絶対に弄るな！(激怒」と厳重に、そのJarファイルの操作を束縛されている。
クラスパスから外すこともディレクトリ移動も設定ファイルの変更も許されていない。
サーバ内にある既存のシステムをただ拡張するだけにしろと支持されている。


どうする？　　もう納期は迫っている！！！徹夜残業に
加え休日返上する事態にまで追いやられた！切迫した事態だ！　
上司のメールには【大至急】とSubjectについている。

上司の指示に逆い反旗を翻してa.jarをアップデートすべきか？
それとも上司の指示に従うために最新版a.jarを適用するのを諦め、そのために
b.jarの適用も諦めて、b.jarに相当し古いa.jarに会わせたパッケージを莫大な時間とコストをかけて自作するか？

さあどうするどうする！！！！！？

>>563
上司に決めさせれば〜?

スレ違いだろ

最新のa.jarをコピーしてpackage nameをかえる。
IDEを使えば一瞬ですむ
b.jarはそっちを使う。以上

>>563
その書き込みをそのまま上司にメールして決済させればいいじゃねぇか
判断するために高い地位にいるんだから。

上司に判断させると一番面倒くさい（現場に苦労させる）判断しかしないのがデフォだがな。
この場合では、

「b.jarに相当し古いa.jarに会わせたパッケージを莫大な時間とコストをかけて自作する」

新しいa.jarから別途クラスをロードしておしまい。

>>566
この話はすでにもう終わったことなんだが、
そのとき上司が、jarどころかJavaのことをろくにわかってなくて
Javaのクラスパスといっても理解できなかったので救いようがなくてさ。
結局おれの判断でやったよ。テストしてみてその結果で判断するってことになって。
テストもショボい問だけど本番のサーバ環境でJarをバックアップしてから上書きして
Tomcatを再起動してテストして、
テストが終わっておかしかったらまた古いJarに戻してTomcatを再起動するというとんでもないこと
やっていたよ。
しかも俺に客先のサーバのroot権限のパスワード教えちゃってさ。

>>565
> スレ違いだろ
> 最新のa.jarをコピーしてpackage nameをかえる。
> IDEを使えば一瞬ですむ

a.jar解凍してから勝手に改変してEclipseのリファクタリングか。
うーむ。それはたまたまJakartaのブツだったからよかったが・・・。

a.jarとb,jarと自分が開発しているソースコードすべてを
Eclipseのプロジェクト上でソースコードに展開して
リファクタリングするわけだろ。

あとでb.jarに依存するJakartaのJarがあったら、
そのJarもいちいち名前変更リファクタリングしないといけないのか。
放置していると悪循環に陥りそうだ・・・

>>567
それはありがちだな。
Jakarta 並みのでっかいものを自作で手がけるとコスト増大だな。
>>565の名前変更リファクタリングなら確かに有効かも知れない。


>>568
クラスローダか

>>570
おまえ基本的に分かってないだろ？
解凍など不要

独自暮らすローダーをつくりforNameをオーバーライド
if(name.startWith("mondai.no.package"))
//新しい方のa.jarを使う

これでいいんでない？

もしくわこっそりコードの中でclasspathを変える。
まずばれる心配はない。

>>572
内部では解凍を行っているが表面上は
ユーザによる解凍操作が不要ってことを言いたいのか？

Commons系ので困った事あったか、な・・・
今度のJavaって、複数のバージョンを混在できるようにっていう
フィーチャー無かったっけ？こういう時役に立つ？

>>575
>>526 前後

クラスローダがパワーアップするのかな

>>575
VelocityとBeanUtilsとHttpClient何かを使っていたときだったろうか、
古いオッサンが書いたコードにバージョンの古いVelocityと何かが
使われていて、その「何か」はなんだか覚えていないけど、Commonsの古いバージョンのものだった。
そしたら、その古いやつに依存する他のJarも古い奴で新しい何かとは互換性がなかったんだ。

それで仕方が無くHttpClientを3.0から2.0にダウングレードする羽目になってしまったよ

>>436
> どうせ過去の年号なんて一年二年ずれてたり、
> 鎌倉幕府ができたとしが1192年かと思ったら全然違う年に
> できたことがわかって教科書もかわったし「いい国作ろう鎌倉幕府」
> なんて暗記もまったく役に立たなくなった。

過去レスですまないが、君、歴史に無知すぎ
「年号」と「鎌倉幕府」は、全く直行する概念

Hibernate 2.xと3.xの混在はよくあるな

>>579
空気嫁。
言いたいことは歴史の正確さの問題だろ。
年号と幕府創設との間には直接な関係は無いが
細かい年号を定めたところでその年号が正しい数値に
なるのか？ってことだ

>>579,581
スレタイ嫁。

もう秋だよー｡mustangのリリースまだですか？

age

天高く、馬遅れる秋。

>>583
延期されたよ

>>582
その程度のスレ違いはまだよい。
過去にはもっと酷い話題でやたら盛り上がったのがこのスレ

for(int i: 5){
System.out.println(i);
}
みたいな構文もｷﾎﾞﾝ

実行結果
0
1
2
3
4

>>588
>>543 の構文が採用されれば
public interface B<throws E>{ void invoke(int i) throws E; }
public static <throws E> void for each(int num, B<E> block) throws E {
　for(int i = 0 ; i < num ; i++) block.invoke(i);
}
for each(int i : 5){ System.out.println(i); }
とかできるようになるよ。

もっとも、まだ草案レベルだろうし、実際に採用されるかも知らんけど。

>>588
Intervalって名前付けられたクラスのインスタンスが行う振る舞いな気がする。

>>589
そんなこと
public int[] seq(int start, int end)
みたいなapiでたりるだろ

for(int i : seq(0,5)){
//
}
これじゃだめ？

>>547
それだと、約intのサイズ * (end - start) バイト分のメモリが必要になるから、
end - startが大きい場合に、多量のメモリを消費するという問題がある

>>591
自己レス
間違えた。>>547じゃなくて、>>591だった

>>591
富豪的プログラミングって奴ですな。

それなら int[] じゃなくて Iterable<Integer> 返した方が良いんじゃない？

>>592
速度重視なら591
（もちろんstatic finalにしてconst化する）
メモリー効率重視なら594

と選択肢があるのはよいと思うが。

> （もちろんstatic finalにしてconst化する）
これは笑うところだよな？

ってか、Tiger の構文で良いなら現世代スレ行け。
http://pc8.2ch.net/test/read.cgi/tech/1150286189/

と思ったけどメモリー効率は変わらないか。。。
多少Integerのキャッシュが寄与するくらいだね。

メモリー効率だとfor(int i =0; i<6 ;i++)か。

>>596
どのへんを笑っているん？

>>598
たぶん・・・「もちろん」だと思う
そこまで強調しなくてもいいし
と、、その記述が持つ性能向上はJVMの最適化能力によって次第に誤差に・・・
「const化」という用語も何か違和感感じるし・・・

staticにすることでのメソッドのメモリ消費量ということでいうなら
まぁ変わらんだろうから、そこを笑ってる可能性も否定しきれない

JVMというかコンパイラー依存でしょ？

本当はinlining(だっけ?)とかいうんだろうけど、const化のほうが分かりやすいでしょ。

>>600
Hotspotの最適化能力をなめてはいけません。
static finalのインライン化はコンパイラだけどね。

お前らバカにしやがって。。くやしぃ！！！



とにかくそれしきのことに新しい文法はいらないでないか？と言いたかった。

蛇足かも知れないが591がインライン化されるとメモリーそんなに使わないんじゃないか？

Hotspotっていつまで最適化するの？
マイクロベンチするとある回数から突然速くなるけど
サーバとかの運用でもその段階で最適化は止まるの？
それとも常日頃からOracleでいうanalyzeみたいなことしてるの？

現世代Javaの動向 1
http://pc8.2ch.net/test/read.cgi/tech/1150286189/

次世代な話題じゃなくなったんで
スレ移動したよ

>>602
>>591はインライン化されてもメモリ使うだろう。seqの呼び出しで
繰り返し回数分のサイズを持ったintの配列が必ず確保されてしまうから。

速度追求はJavaの本分じゃないだろ。
そこまでして便利さじゃなくて速さを求めるなら他の言語でやれ。

すでに速度もとめる言語でもあるよ

まあ実際早くなってきているんだし。
速度を求めるために文法を改造することにこだわって
C++やC#のようにスパゲティコード生成言語に成り下がるのは
ちょっとねえ

>>607
お前誰だよ。

>>609
お前こそ誰だよ

>>607どこに速度もとめるわけ？

おはようからおやすみまで

携帯で成功してしまい、Sun/Javaの思惑は既に成功してるんだが…
それでも「速度」とか関係ない方向を見てる奴がいるとは…

揺りかごから墓場まで

>>613
開発現場はBREWだろうがJavaだろうが、成功していないように
見えるが・・・

ずっとVM最適化しまくってるし速度もとめてるのは当たり前
遅いより速いほうがだれだっていいからな
状況に合わせて選択するクライアントVMと鯖VMがあるのもその証拠

ただ、速度という項目が一番目にはこないだけ
C言語と同じだろ

Mustangからだっけ？
Javaアプリを一旦起動すると、二回目移行からは
ネイティブアプリとして起動するために無駄にコンパイルせず
高速化するというPreJITが搭載されるのは

何その説明台詞ｗ

だからmustangは和カレンダーとscript以外は特にかわらないんだってば

エスケープ解析だとかいうのでスタックの利用率が上がるんでしょ？
多少はリソースの消費量が抑えられるようになるんじゃないかな。
対PHP向けにチューニングしてくれんかね、CGI代わりに使いたい

その和カレンダーも実装がイマイチでな

>>619
タスクトレイを使えるようになったことGUIが刷新されたこと
JMXが使いやすくなったことなど、
でかいことはかなりあると思うが

MSのように市場を支配する事を「成功」と勘違いしてるだろ。
単なる社内部の言語が、もはやないと困るほど広まっている
のは成功といえないか？

>>616
C（とアセンブリ）は速度重視が主目的だが、何がC言語と同じなんだ？

>>624
エロイ人は、なぜ高級言語を生み出したのか脳内で１００回暗唱しる。

>>617 と MVM を実現したらJavaかなり最強に近づくと思うんだけどな

>>616
お前、日頃から「キモイ」って言われてないか？
JavaじゃなくてCを駆使した速度チューニングの方がお前に向いてると思うぞ。

なんか釣がずっと住み着いてるようだが

>>617
>ネイティブアプリとして起動するために無駄にコンパイルせず

今も昔もコンパイルしてませんが。

昔はしてただろHotspotからです。

お前ら！jsr-277のearly draftでてるぞ！
jdk-7で導入かね？

>>626
どうやって？

1.6 はいつ頃正式リリースなんすか？

１２月らしいが

java.bean.XMLEncoderがenumを受け付けないってなんか間違ってないか？
newが出来ないのでダメーｗｗｗじゃねーよ orz

うぉ
そんな欠点が
ひでぇ

最近シリアライズにそれ使ってないからわからんかった
JAXBはうごくんかね

enumはまともなプログラマなら使いまくるからね
心配になってきた

まるでInteger.valueOf(int)よりも
あくまでnew Integer(int)に拘る香具師みたいだな

>>637
FindBugs じゃはじかれるけどねw

JDK 6 Beta 2ってバグはどのくらいあるの？
めったに遭遇しない程度?

せっかくのenumがクラスっぽいのがやだ。

そのほうがいいじゃないか

enumが独自の型だと型変換で悩むし
値私などの扱いに苦しむ

enumがタイプセーフじゃないほうがいいと考えてるほうが珍しいと思うのだがね

>>640
enum は現行世代だから。

まずは、>>640は何がいいのか聞いてからじゃないか？

オレは640じゃないが。。

むしろクラスらしくextendできるようにしてほしい。
何か理由があるんだろうが。

一意インスタンスが継承できちゃあかんでしょ

enum の話続けたいなら、そろそろ現世代スレ行ってやってくんないかな？

現世代Javaの動向 1
http://pc8.2ch.net/test/read.cgi/tech/1150286189/

東京大学教養課程の第一プログラミング言語がRubyに
http://d.hatena.ne.jp/sumii/20060928/1159394568
http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/sumii/20060928/1159394568

>>648
このスレ的には、そっちよりは
http://d.hatena.ne.jp/sumii/20060928/1159403268
の方が問題っぽいな。次世代じゃないけど。

B#compareTo(B) が override なのか overload なのかがわからん。
言語仕様みてみたけど、subsignature の説明で使われてる
the erasure of the signature って部分の厳密な意味がわからんので。
@Override つけると蹴られるので、コンパイラは overload と解釈してるっぽい。

個人的には言語仕様のミスなんじゃないかと思うんだが……

おいおい、お前…

>>645
できるはずだが、できなくなったのか？

5.0 の @Override ってスーパークラスで定義されたメソッドを override してる場合しか効かないのか。

つまり
interface A { void m(); }
class B implements A { @Override public void m(){} }
は蹴られる、と。 6.0 では この振る舞いは変更されてるけど、
ドキュメントの方は変更無し……

>>651
元から出来ないよ。

8.1.4 Superclasses and Subclasses
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.4
> It is a compile-time error if the ClassType names the class Enum or any invocation of it.

toStringとかオーバーライドできなかったっけ？

>>649
調べてみたけど、

8.4.8.3 Requirements in Overriding and Hiding
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.3
> It is a compile time error if a type declaration T has a member method m1 and there exists
> a method m2 declared in T or a supertype of T such that all of the following conditions hold:
>
> ・m1 and m2 have the same name.
> ・m2 is accessible from T.
> ・The signature of m1 is not a subsignature (§8.4.2) of the signature of m2.
> ・m1 or some method m1 overrides (directly or indirectly) has the same erasure
> 　as m2 or some method m2 overrides (directly or indirectly).

・B#compareTo(B) と A#compareTo(Object) は同じ名前。
・A#compareTo(Object) は B からアクセス可能
・B#compareTo(B) は A#compareTo(Object) の subsignature じゃない（たぶん）
・B#compareTo(B) が実装してる Comparable<T>#compareTo(T) と
　A#compareTo(Object) は same erasure。

なのでコンパイラがエラー吐かないのはバグなのかも？

>>654 出来ないよ

>>654
enum E{ a{ public String toString(){ return "overriden toString"; } } }
とかできるけど、extends java.lang.Enum できるかとは全く関係ないと思うぞ。

関係あると思うよ

そもそもenumは列挙定数なのでポリモーフィズムが意味ない
static intの代わりと考えればわかりやすい

そして宣言時の拡張は意味がある
インターフェースを付け加えたりすることが可能

switchでenumの初期実装がifだったんだからそろそろプリミティブ以外も
switch対応してほしいな
そっちのほうがよっぽどeod
クラスを入れた場合はtoString()で分岐くらいいれてもいいのに

> static intの代わりと考えればわかりやすい
それはそれで C の enum に毒された発想のような。
ってか、「関係がある」という説明になってないし。

> switchでenumの初期実装がifだったんだから
それ、記憶違いとか見間違いじゃなくて？

>>658
> クラスを入れた場合はtoString()で分岐くらいいれてもいいのに
そこは普通 equals() だろ。

どーゆーセンスしとんだ？

|-`).｡ｏO(・・・・・・static intの代わり以上に便利に使えるはずなんだがなぁ・・・)

>>659
> > switchでenumの初期実装がifだったんだから
> それ、記憶違いとか見間違いじゃなくて？
もしくは、case の数やらバイトコードのアラインの関係で
tableswitch や lookupswitch 使ってないだけだったりして。

http://www.javainthebox.net/laboratory/J2SE1.5/LangSpec/TypesafeEnum/TypesafeEnum.html
最初はif文であってる

if文って…… せめて if_acmpeq とか言えよ。

「せめて○○って言えよ」系のレスがきもくなかった試しがない。
if文で結構。分かりやすい。

>if文って…… せめて if_acmpeq とか言えよ。
>if文で結構。分かりやすい。

どっちもどっちだな

どっちでもかまわんが>>659が間違いってのが正解

なんかどっかの図だと5.0から6への実行性能向上が、
1.4から5.0への実行性能向上より大きいんだけど
これってSUNの捏造？

5.0は1.4からほとんど速度アップしてないからな
6で大きく変わってもおかしくはない

>>669
1.4から4ではGC周りが結構改善されてて個人的には1.4に比べてだいぶ助かってる
デスクトップ用途も結構パフォーマンス上がってたんだが
まぁ、サーバ用途に比べたら差がなかったかもな

6は・・・1.4→5よりも俺的には衝撃少ないかな
それというのも、リリース前からずっと試せてるし・・・
速度よりもデスクトップ用途の機能増の方が注目かな

GCの多少の性能アップだけは俺もよかったと思うけど
ベンチにその結果がでてくるかというと微妙だな

ただ、5.0はコンカレントAPIとか拡張構文とか便利だしもう1.4にはもどれんわ
ListとかMapとかでてくるとソースみないと中身がわからないというのが非常に困る

６はJava2DがWindows以外でやっとアクセラレーションがきくというから期待している
Windows版は変わってない気がするが

ベンチにでなくていいよ、GCは、アレは実行速度を速くするものじゃなくて
遅くしない、止めないための仕組みだから
どうも間違って期待してる人がいるようで・・・・

>>668
6.0 から入るとかいうエスケープ解析で
最適化しやすいコードで比較した場合の図だったんじゃね？

>>667
>>659の前半は間違ってない

>>672
GC時間が長ければ影響する
結果GCが最適化されていれば早くなる

5.0からはインクリメンタル指定がコンカレントGCなんだが、これかなりスループットさがるんだよね
ずっと通常の世代別GC以外はチューニングがイマイチなのはなんとかならんのかねぇ
コンカレントGCにしないとスループットよりレスポンスが重要なゲーム関係がイマイチだし

そもそもGCは場所によって利き方をコントロールさせてほしい
このメソッドだとスループットが必要、このメソッドはレスポンスが必要とかあるんだから
ひとつで何とかしようとすること自体が無理

あとSystemGCは実際にSunの実装としてフルGCがはいるが、新世代だけのGCとかも
コントロールできるようにしてほしいな
このへんは実装依存になるからアノテーションでヒントを与えるとかそういう感じで

JavaOne2005のときと違って何故か6の性能が格段に上がっている謎
ttp://sdc.sun.co.jp/news/2006/06/images/j1r-perf-specjbb.jpg

>>675
確かにGCにヒント出せると助かるなぁ

>>674
あれはintがいいとかじゃなくてstaticだというところをアピールしたかっただけ
intなのは1.4までの列挙に使われてたというのをあらわしている
しかしEnumMapのコンストラクタはどうにかならなかったのかねぇ

>>676
2005年から2006年になってチューニングが進んだというのは考えられるが
SPECｊｂｂ2000というのが気になるな

非現実なコードだったりして当時から存在意義を問われたベンチだったのだが
2005は大幅に改善されたが5.0以上が対象だったからということなんだろうけどね

そろそろ秒読みだと思うけど、6ってまだ？

>>678
> あれはintがいいとかじゃなくてstaticだというところをアピールしたかっただけ
それなら必要なのは static の他に final だろ。int よりは。

>>679
>>353

>>681 おお！

http://journal.mycom.co.jp/news/2006/10/21/342.html
JSR-277のEDR期間だったのでドラフトにざっと目を通してみた。
これ、すでにJavaME向けに通過してるJSR-232やOSGiの車輪の再発明
しちゃったって感はやっぱあるなあ。前回の投票時のBEAとIBMのコメントは
実質無視ってわけか。

>>645
おいおい、TypeSafeの意味がねえじゃねえか。
不変クラスはfinal にしてこそ、価値がある。

>>648
トラックバック:http://d.hatena.ne.jp/sumii/20060928/1159394568

東京大学教養課程の第一プログラミング言語がRubyに
http://d.hatena.ne.jp/sumii/20060928/1159394568

型変換に悩まなくて済む分、VB厨みたいな馬鹿を東大から
量産しそうだな

JavaとRubyと本の数を比較するとJavaの方が圧倒的だろ。

つーか、東大といっても文系馬鹿の連中のための課程かい。
文系東大卒は堀江被告みたいな馬鹿ばかりなのでどうでもいいや

>>685
Ruby も良い言語だし、良いんじゃない？

ってか、言語論争やりたきゃ他所でやれ。二度と帰ってくるな。

そいうのは、マ板でよろしく　( ´∀｀)つ

JRubyとかへの投資もされてるし、JavaとRubyは別に争う言語じゃねーよ。

GCの改善はそれはそれでやってもらっていいのだが、GCの発生自体は
制御できないから、やっぱり何らかの明示的なメモリブロックの破棄を
サポートして欲しいな。
デメリットは、リファレンスのテストだけじゃそのリファレンスが有効かどうか
判断できなくなるというのがあるけど、free()使いたい香具師には問題ないよね？
どうせならリファレンスカウンタを併用してもいいし。

あまりプログラムに詳しくない人に説明するとき

Perl → Mixi、はてな、Livedoor
PHP → Yahoo!

とかわかりやすい採用事例があるのですが、
Javaは特に思いつかないので困ってます。
次世代Javaではマーケティング面での戦略は進歩しますか？

マーケティング云々以前に、
なんで採用事例がないのか考えてみるべきだろう。
言語仕様のせいじゃないわけだが。

言語仕様は優れていても、運用環境などがダメってこと？

楽天もPHPか。

そしてAmazonはPerlか…

mustangあたりでどこか大手がJavaに乗り換えたりしないものだろうか。

あまり詳しくない人相手の説明ならケータイJavaでいいんでないの。

ANAとかWeb2.0と無関係な大企業では古くから広く利用されています。
だと微妙だよな。

確か既にgoogleではJavaが使われてるんじゃなかったっけ？

あ、正確に言うとJava「も」使われてるってことね

大手とか勘違いしてる奴が要るけど、Java使って行うサービスってほどでもないんだろ。
結局同じ結果なのに高くつくでしょ？
新興企業・ベンチャー企業で金持ってないところでは、安い人件費で人海戦術が最強ってこと。

GMailやAdSenseな
あとMMOのサーバに使ってるとこもある
デスクトップだとDBやCADなんかの
フロントエンドに使われてるな。

>>701
新興企業・ベンチャー企業にJavaはオーバースペックってこと？

そのへん解決するためにJavaEE5からはEoDを推し進めてるんじゃないの？

Javaがオーバースペックっていうわけじゃなくて人件費の問題じゃないかと。。。

TomcatとPHPとで生産性が変わるとは思えないんだけどどうなんかね。

SUNはNetBeans+JSFでポトペタ簡単開発を目指してるみたいだけど、
perl、phpみたいに気軽に利用されるようになるとは思えない。

ロードバランサで数増やすとして
PHPとJavaとでどっちが得できるかだな。

>>691
GCが発生してもいいタイミングと発生するとだめなタイミングがあるからね
それに発生タイミングはコントロールは出来るよ

いつおきるかわからない0.1msのGCより、空きがなくならない限りGCがおこらないように
コントロールできるけど5msかかるGCだと後者のほうがゲームとかで非常に使いやすい
スループットは大幅に下がるけどそういうもの

ページフリッピング発行直前でGCがおこると1ms未満だろうが今回の垂直同期とりこぼす可能性はあるわけで

比較条件は速度や負荷だけ？
開発（コード書き）のし易さ、メンテナンス・保守のし易さなんかはどうなのさ？

PerlやPHPでオブジェクト指向なんて泥沼だと思うけど。

>>705
PHPとの比較でいいのならJSPだけでいいから難易度は同じ
Javaのほうがロジックが絡むとIDEの関係でかなり楽にコードが書けるからなぁ

>>706
気軽に開発できるだけならJSPだけでいいんじゃね？
DreamWeaverでデザインできるし

動的コンテンツ程度の気構えでいいのかシステム開発として
将来的なメンテも含めてどうかという視点での選択だけでは？

はいはい。「次世代のマーケティング」と関係ない
現世代のマーケティング関連（よーするに言語論争と大差ないもの）は他所でやってね。

ttp://www.javainthebox.net/laboratory/JavaSE6/scripting/scripting.html

このへんのが上手くいけばPerlやPHPが得意な分野で対抗できるんじゃないかな？

>>708
GCを実行しない・指定期間は止めておくクラスとかメソッドってなかったか？
ん、あったか？なければ、コミュニティーでvoteしておくといいよ。
GCが発生して欲しくないのは、よく分かる。

>>712
例えば一年程度しか使わないプロジェクトにとっては、
それでも魅力はないし、余計なコストもかかるからいらないんだよ。
面倒な事したいんだね、君は。

>>691
個人的には、GCにメモリ管理を任せるメモリと
自分でリソース管理ができるメモリってのが使えればいいかな？
パフォーマンスが気になる部分では、そのメモリを使って発生オブジェクトから
GCを起こさせないようにする、と。

全部が全部管理しなきゃだめだから、free()が面倒なんであって
自分で気にしてる部分だけってことにできればねぇ・・・
無駄な使い捨てオブジェクトでGCの手間を増やす事も無くなる

現行GCはメモリの空きがなくなったときに発生＆ヒープ拡張
ならば使用メモリ量が把握できてるならゲームだったら
たとえば秒60回新世代専用のGCが発生させる手段があればいいだけ
FullGCを実行させる手段があるんだし可能だろう

その場合スレッショルドが問題となるかもしれないがそもそも
こういった用途ではスループットが絶対ではないので世代別
である必要がなかったりする

>>715
それは違うな。C++でメモリ管理が行き届いたライブラリーを作って、
それを組み合わせれば、結局メモリ管理云々の話は出てこないはずだ。
つまり、君は大きく考えすぎているだけじゃないか。

FPSコントロール用の機能があってもいい気がするんだけどね。
用途が狭いからむりかな。

なんだかわからんが、途中で止まったりしなくて一定の速度で動くように
したいなら...

つ Javolution
ttp://journal.mycom.co.jp/news/2006/09/20/343.html
ttp://javolution.org/

既存ライブラリとの併用にはちょっと工夫が必要なようだが（FAQ参照）、
オブジェクトをdirect buffer上に確保してリサイクルすることでGCを起動さ
せないようになってるみたい。

>>688
いや、Javaは言語ではなくプラットフォームだから
それを解ってない香具師がマ板やム板に未だにいるのが不思議

>>690
ますます東大の価値を下げる結果になりかねないかもしれぬ

>>692
> あまりプログラムに詳しくない人に説明するとき
> Perl → Mixi、はてな、Livedoor
> PHP → Yahoo!
> とかわかりやすい採用事例があるのですが、
> Javaは特に思いつかないので困ってます。
> 次世代Javaではマーケティング面での戦略は進歩しますか？

酷い喩えだ。

Java →　基幹系業務、金融系、各種オンライントレーディングサイト(例:イートレード証券)、
　　　　　　オンラインバンキングサイト(例:三井住友ダイレクト)、組み込み系(携帯電話)

などなど
と説明すればいい。

>>693
採用事例がないってことはないだろ

>>694
それも違う

>>695
だが楽天証券はJava。
PHPを使ってるとこは
アクセスが殺到するところや、
クリティカルでない単純な処理をしているところ

>>697
どうせなら、火星探査機とか銀行とかいったほうがましだと思う

>>696
Amazon APIの中にはJavaが使われているところがあったりする。
もちろんGoogle APIも。

緻密な電子商取引が関わるところではJavaが使われると考えればいい。
昔はCOBOLが使われていたところをJavaにとってかわる、みたいな。

>>720
Javaは言語だが、何が不思議なんだ？

>>701
それだったらPHPだね。
PHP開発なら安い人件費で済ませることができる。
Javaでやると、Tomcatのセットアップやメモリ増設など、高くつく

>>721
お前は東大じゃないだろ。余計な心配するな。
ところで、仕事は満足してるか？

>>703
それも誤解を招く意見だ。
Sunは大手企業にJ2EEを普及させてきたという経緯はあるが。

むしろ、単なる検索するだけのサイトや操作に失敗しても
大して支障を来さないサービスなどにはJavaを使うには
オーバースペックということ。
失敗は許されない処理を、ミッションクリティカルなところに
Javaは適している。オンラインショッピングやオークション、
証券取引など。

誤発注なんて許されないからな。
検索エンジンが間違った検索結果を返してももう一度やり直せば
済むが、オンライントレーディングサービスが間違って指し値を指定したり
手持ち金も無いのに信用取引で間違って大量に株を大量購入するような
ことがおきればとんでもないことになる。
「間違ってもやり直せばいい」なんて考えは許されない。そんなところに
Javaが使われる。

PHPが使われる大きな理由は
サーバー用のメモリは高いってとこにあるのかもシレンな

>>709
PerlはPerl6が出れば少しは良くなるだろう。
それでもJavaには及ばないとは思うが。
PHPは名前空間が使えない時点で即座にアウト。

どちらも、オンライントレーディングサイトには
使って欲しくない言語だな

>>710
> >>705
> PHPとの比較でいいのならJSPだけでいいから難易度は同じ

JSPのはうは型に厳しいという難易度がある、が、
カスタムタグライブラリやStrutsなどと併用するとなると、さらに難易度は上がる。


> >>706
> 気軽に開発できるだけならJSPだけでいいんじゃね？
考えが甘過ぎ。JSPがどれだけメモリを喰うと思っているんだ。
レンタルサーバでJSPやServletが使えるところがPHPやPerlなどと
比べて少ない理由をよく考えてみろ。


> DreamWeaverでデザインできるし
DWやAptanaなどはStruts向けに作られていないからそれも
どうかと思うが。DWだけではある程度までしか柔軟性を期待できない。

>>712
それはどうかね。それはJavaでJNIを通してC/C++を使えるから
C/C++に劣らない速度を期待できるという考えに騙されてることに似ている。

>>691
> GCの改善はそれはそれでやってもらっていいのだが、GCの発生自体は
> 制御できないから、やっぱり何らかの明示的なメモリブロックの破棄を
> サポートして欲しいな。

java.lang.ref.SoftReferenceだけじゃ物足りないかな？

>>713
まさにjava.lang.ref

>>712
それをPHPやPerl替わりに利用することに期待しない方がいいと思うぞ。
むしろ、お遊びやAjaxとの連携に使えるか、
ちょっとしたちっちゃなコードを埋め込みたいときに使えると考えた方が
楽じゃないかな

>>728
Sunの説明では「Java」といっても言語という意味のほかに
プラットフォームという意味も含めているみたいだが

>>730
東大でなくても、東大卒を信用できなくなるのは
がっくりじゃないか。あいつは東大だからこれができるだろう、と
思って期待してみたら全く仕事ができなくてがっかりするだろう

>>732
メモリが少ないだけでなく馬鹿でも手軽に扱える、
Tomcatをインストールする必要がない、
レンタルサーバで導入しても複数人に個人用サイトを
運営させるのが楽ってのがある

>>732
PHPが使われるのは敷居が低いからだと思うよ。
たとえば、画面にちょっとカウンタを表示したいとかだったら、PHPだったら
HTMLに直接PHP埋め込んで、HTML前後にタグを付けるだけで、ほれ、
PHPスクリプトできあがり、だからな。たしかに始めるにはお手軽だ。

敷居が低いから人が集まるし、敷居が低いから値段も安い。「それ、PHPだったら
いくらですか？」とかいわれるんだよ。もちろん、ビジネスだから安いほうがいいからね。

ところがHTMLに大量のロジックが混ざったようなHTMLだかコードだかわからないもの
の保守でいろんなところが混乱しているのが現状かな。いまでこそSmartyとかの採用が
進んでるんでマシだけど、「HTMLに直接書かないんだったらRubyかPythonでいいじゃん」
とか言われつつある。

正直、いま若手新人で「とりあえずPHPの仕事があるからPHPやっとけ」と言われている
人たちがかわいそすぎる。

>>734
型に厳しいのは難易度低下だと思うが
実行前にチェックが出来るというのは大きい
ステップ実行とかも容易だしね

そもそもPHPとの比較ならStrutsは使わないという前提
カスタムタグなんていうのもループ以外使わない
それにDWでのJSP開発は難易度高くはないぞ
Tomcatと連携できるようになったバージョンからはね

>>737
それ使えないだろ
GCはしてほしいのだよ
ただ、タイミングをコントロールしたいだけ

Javaは言語、
JVMはプラットフォーム

なら全然納得なんだけど。

>>734
>JSPのはうは型に厳しいという難易度がある、が、

型に厳しいと難易度高いのか？

そんなことより、Java製のブログやWikiを探してるんだが、
MovableTypeやPukiwikiやMediaWikiに匹敵するものが見つからない


なんかいいものないかねえ

とりあえずブログのほうがこんなのがあったみたいだ

人力検索はてな - JAVAで作られたフリーのブログサイト構築ソフトを教えて下さい。無ければPHP,Perlでもいいです。
http://q.hatena.ne.jp/1107748399

>>746
ちょっとぐぐったけどこんなのがあるみたいよ
The Roller Weblogger
Blojsom
MapleBlog
Blog
JSP Blog
SnipSnap
Pebble
Blogunity
DLOG4J

JSPWiki
DevWiki
VeryQuickWiki
Chiki
Snip Snap
FitNesse
UseModj
Friki
yaWiki
Platypus Wiki
XWiki
ButorWiki
JBossWiki
Elsie Wiki
JAMWiki

Blogのほうがあんたのリンク先にある回答がほぼ正解じゃねえの？

Javaだったらふつうにblojsomがあるんじゃん、と思うんだが。
ttp://wiki.blojsom.com/wiki/display/blojsom/About+blojsom

Movable Typeに匹敵するほど有名だというつもりはないけど、
それでも超有名といってもいいと思うんだが。

まあ名前から分かる通り、bloxsomの影響を強く受けてるブログ
生成プログラム。

「Roller」
ttp://rollerweblogger.org/

もJavaでは有名だし、Apache入り寸前だぞ？

>>746
純粋なWikiやBlogとは違うっぽいけどTuigwaaとかも結構面白そうだぞ。
DBも作っていけるぽい。

>>731 それは作るプログラムや設計の話であって、JavaかPHPかどれを採用するかの問題と違うと思わないか？

>>740
東大卒を信用するとか信用しないとか、君はちょっと頭おかしいんじゃないか？
大学まで（人によっては高校まで？）の日本国教育課程を難無くこなしてきた
だけ、なにか特別な思いでもあるのか？
東大卒よりも、司法試験合格や国家一種や税理士とか持ってるほうが
よっぽど役に立つはずだろう。

東大卒で30代になっても営業やってる奴は営業が大好きなんだろうな。
もう一回東大受験した方がいいと思うがな。

>>736-737
主プログラムの方で「ちょっともたつく」原因がGCが作動するからなんだけど。
java.lang.refでGCの起動（作動）を指定時間止める事は出来たか？

> java.lang.refでGCの起動（作動）を指定時間止める事は出来たか？
無理

GCに関してはゲーム関係のスレでよくでるよね
Sunはいつおきるかわからない0.1msのGCのほうが
指定可能な5msのGCよりすばらしいと考えてるのだろうか

だから「GCの起動（作動）を指定時間止める」要望を
次世代で実現してくれって、英語のサイトに行って、voteして来いってこと。
理由は>>755でいいでしょ？

>>756
今、BugDatabase 止まってるみたいだけど。メンテ中だっけ？
欲しい人は report 頑張ってね。
1票余ってるから脈ありそうだったら vote ぐらいはするからさ。

あと GCを指定時間止める、ってのは大雑把で使い勝手悪いんじゃないかと思ったり。

gcのスレッドをsleepしちゃえばよいんじゃないの？
できないんだっけ？

>>757
普通の用途やGCを気にしてない人はGCを指定時間止めたりしないから、
特定用途（例えばゲームとかアニメーションとか）で、それも開始し忘れたり
キチガイなこと（指定時間が適当）やるなら自己責任でやっててオチだろ。

GCを一定時間とめるじゃなくて
メモリに空き容量があるうちでもGCを発行させたいが正解だな

>>760 それだと、>>755のように一瞬でもGCが起動する可能性があるから、意味が違うと思う。

俺>>755なんだがそれでいいのよ

1フレームで1回GCはしらせればその間にGCがはいることはない
もちろんその間にメモリが足りなければ入るべきだし
普通はどんなアプリであれメモリ使用量を把握するのは普通なので
そんなあふぉなことはおきない

ココは次世代スレだから、GC云々の話は要望・改善じゃないのか？
それとも現世代スレで続けるのか？

>>747-749
おうサンクス。かなりの種類があるもんだな。

今、Perl + PHP製のMovableTypeが日本国内で優勢で
アメリカではMovableTypeの座を首位から奪った、
PHP製のWordPressが、優勢で
どうしようか迷っていたところだったんだ。
MovableTypeはエントリ数が多く、あるプラグインを入れると
再構築に時間がかかり糞重いので、
MovableType独自のタグも必要ない、
再構築の手間を省ける軽量のWordPressが勢力を拡大しているようだ。

Eclipseのようにプラグインが豊富にあれば、即座に
Java製ブログツールに飛びつくぞ。

そして、MTGoogleMaps, アフィリエイトサポート、
MTAmazon, MTPhotoGallery, MTBlackList, MTCollate, MTCompare,
MT-ISBN, MTWidgetManagerm MTPaginate, GoogleSearch, MTMacro,
MTIncludePlus, TinyMCE for MT, StyleCatcher, Template Baclup and Refresh,
OpenID Comment, などの各種MovableTypeプラグイン
に相当するプラグインや「はてなダイアリーキーワード」に
相当する機能、カテゴリ管理、タグクラウド、アクセス解析、moblog,
WordPressにも備わっている投稿スラッグ、それからテンプレート編集機能、
トラックバックスパム管理機能、それにAjaxによって管理しやすくなっている機能、
TypeKey認証またはOpenID認証、プラグイン開発支援、
などの機能がJava製ブログツールにあれば即座に飛びつく。

そりゃ飛びつくだろうさ。

>>764
完全にスレ違いなんだけど・・・
他所でやってくれんかね？

Mixi、はてな、Livedoorがperlなのは基本的なアイデアは10年位前だからだろ
最近考え付いたんじゃなくて10年位前のWeb黎明期にcgiから始めた奴らが中心にいるからだな
そこで、JavaをみるとIBMを中心に大手ベンダーがたむろしてるからその線で行くと利益むしりとられるただそれだけの話
プラットフォームとしては貧弱でも生産性がたいしてひどくなかったってのが正解
まちがっても作りづれえけど抱え込みの為には仕方が無かったなんて事言うわけには行かない
Yahooがphpなのはフロントエンドは出来る限り生産性を高めたいが、辞められても他じゃ使えない言語が良いって感じ

東大の文三なら適当な奴が多いから変なのいるだろうな。
文一、文二はそうでもないけど…

人は学歴を見るけどコンピュータは見ないからなー
学歴高いんだったら人系の仕事についた方がいいよ

>>767
> Mixi、はてな、Livedoorがperlなのは基本的なアイデアは10年位前だからだろ

そのなかでまともそうなのは「はてな」だけだな。Mixiは上場してもそこいらのブログツールと
比べると使い勝手がイマイチだし、Livedoorなんか問題外。Sledgeなんて糞役に立たんライブラリ
開発して大した技術も無い粉飾犯罪企業が作ったものなんてその程度。
最近上場した会社といえばドリコムとかいう会社もそうだなサーバーエージェントの都会コンプのミーハー社長が
株を大量購入したはいいが、BlogPeopleやテクノラティなどのサービスと比べるとあまりにも
劣る点が多すぎ。


> 最近考え付いたんじゃなくて10年位前のWeb黎明期にcgiから始めた奴らが中心にいるからだな

ネットサーフレスキューやKend Webを思い出すじゃねえか。確かにあのころはServletなんてまだ
存在しなかったからperlしかしらない堀江被告みたいな古い考え方に捕らわれた馬鹿が
暴れて日本国内でIT業界に対する印象が悪くなってしまったんだな。テレビしか見てない馬鹿は
IT企業関係者＝堀江や村上みたいな変な奴だと勘違いしているし。

>>768
成績が悪い堀江被告が宗教学科になってしまったために
がっかりして東大を中退したという件を思い出した。

いま法学部の奴が世の中を牛耳ってる感じだな。
どこの会社の社長も法学部出身が多いし。
技術系出身が少ない。アメリカ人から見るとあまりにも珍しすぎるし
不思議すぎる。ああいう酷い状態が続いているのは日本だけだろうね

>>771
法学部じゃなければ、牛耳るのはどの学部出身がよさそうなんだ？
ところで今の君は、技術畑で野良仕事している事に気がついてないだろ。

ダライラマみたいな人

次世代の話を書け

もうOMGのパッケージとかはずしちゃいなYo！

>>770のような奴は、周りから嫌われてるんだろうな…

>>687
東大工学部だが、
(前期)教養課程は東大の1,2年は全員通る道なので、文系のみに限った話じゃない。

しかし、昨日駒場の教科書販売所にいってみたら、Javaの教科書もあって売り切れてたんだが。
どうも全部が全部Rubyになったという訳ではなさそうだ。

連書きスマソ。

というかJavaだったころもプログラミングの講義は必修だったわけじゃないし、必修の「情報基礎」って講義すら学生にはほとんど身に着いていない状況。
(1年の必修の情報基礎では一応Mac OS XのTerminalを触るんだが、シェルのコマンド3年生になったら忘れてる)

JavaからRubyになったから学生の質が下がるとかそういうものではないと思われ。どうせやる人はやるし、やらない人はやらない。
ちなみに漏れは大学のプログラミングの講義でJavaは書きやすい言語だってわかってServlet+JSPとか書き出したクチ。

ただ、JavaよりRubyのほうが学びにくそうな気がするんだが...

>>788
東大でプログラミングの基礎みたいなことするならJavaだろうがRubyだろうがどっちでも良いんじゃね
そもそも社会のヒエラルキー的に東大でた人がやるべき事はちがうんだから
仮にも国の最高学府の東大でて底辺なドカティになるのは持っての他だよ
無駄に税金使ってるんじゃねえよって事だ