06/12/31 02:41:17
Channelはデコレートパターン向きじゃないからね
Buffered*StreamみたいなのBuffer版アダプタを
標準で用意してくれるだけでも嬉しい
264:デフォルトの名無しさん
06/12/31 02:52:32
ああ、しかし、BufferedとByteBufferだと名前が似すぎて間違えるか
265:デフォルトの名無しさん
06/12/31 10:56:51
>>263
BufferedChannel みたいなものが欲しいって事？
ByteBuffer.wrap(new byte[1]); みたいな小さい ByteBuffer 作って
ちょこまか読み書きしてないなら大して必要とも思わないけど。
ってか、java.ioとの親和性とか関係ないような。
266:デフォルトの名無しさん
06/12/31 12:14:45
ByteBufferInputStreamとかStream側にあわせるアダプタだろ
267:デフォルトの名無しさん
06/12/31 13:16:45
> ByteBufferInputStream
要るか？
268:デフォルトの名無しさん
06/12/31 13:34:33
>>267
それが欲しければアプリの中で用意すれば？
ってレベルの需要だろうなぁ
269:デフォルトの名無しさん
06/12/31 13:34:34
場面によりけり。ダイレクトバッファ使ってる場合なら欲しい。
270:デフォルトの名無しさん
06/12/31 13:51:22
writeToメソッドみたいなのがBufferに欲しい
271:デフォルトの名無しさん
06/12/31 14:46:16
>>269
ダイレクトバッファ使ってても、
InputStream や OutputStream のデコレータだったらアドバンテージないんじゃ？
272:デフォルトの名無しさん
06/12/31 14:48:28
>>270
ByteBuffer#get(byte[]) とかあるけど。
273:デフォルトの名無しさん
06/12/31 14:50:18
>>272
それを言うなら ByteBuffer#put(byte[]) じゃないかと。
274:デフォルトの名無しさん
06/12/31 14:52:27
マップファイルを外部にゲロるのに便利そう writeTo
275:デフォルトの名無しさん
06/12/31 14:55:19
>>271
コンポーネント単位で見ればそれもありでは？
nioのが効率はいいんだから、
最適化が必要になった時にnioにあわせていけばいい。
276:デフォルトの名無しさん
06/12/31 14:56:41
便利に使いたいだけなら
NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
みたいなユーティリティメソッドつくっときゃ良いだけのような。
277:デフォルトの名無しさん
06/12/31 15:01:08
>>275
いや、単純に無駄だよねって話。
中途半端にやるとクラスが汚くなるだけだし。
最適化が必要になりそうならアプリ側で入出力処理を抽象化しておきゃ良いんだし。
278:デフォルトの名無しさん
06/12/31 15:06:00
>>277
内部で Channel 使った ChannelInputStream とか ChannelOutputStream で最適化する時
read(ByteBuffer) とか write(ByteBuffer) があると便利なんだよ！
すげーアホ臭いな。そんだったら最初から Channel 使えば良いし。
279:デフォルトの名無しさん
06/12/31 15:07:05
> NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
要るか？
280:デフォルトの名無しさん
06/12/31 15:07:07
ん？Servletにnioを適用するための記事とか普通に出回ってるが
281:デフォルトの名無しさん
07/01/05 02:17:08
6.0でCommons Modelerを使用してPOJOを登録したんだがjconsoleのmbeanタグ
で表示されないのは既出ですか？
282:デフォルトの名無しさん
07/01/10 21:20:03
DOMとコレクションフレームワークの親和性をあげてほしいなぁ。
283:デフォルトの名無しさん
07/01/11 01:52:34
Closure の人(?) が面白いアイデアを書いてる。
URLﾘﾝｸ(gafter.blogspot.com)
なんか、javac弄って遊ぶプロジェクトらしい？
URLﾘﾝｸ(ksl.dev.java.net)
URLﾘﾝｸ(blogs.sun.com)
>>224 の一番最後の人が property を試しに実装してみたらしい。
URLﾘﾝｸ(weblogs.java.net)
protperty 慎重派の人も居るらしい。
URLﾘﾝｸ(weblogs.java.net)
アプリ書く人と、ライブラリ（Swingコンポーネントとか）書く人の違いなんだろか？
284:デフォルトの名無しさん
07/01/11 19:27:09
propertyってどんな機能を指してるのかよくわかんないんだけど
object.x = "hoge" を object.setX(String str)
String str = object.x を object.getX()
にmappingする機能でおｋ？
ObjectPascal とかだと直接フィールドを参照するか、メソッドを指定するかとか出来るけど
そーゆー事も考えられてるのかな？
フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
propertyを導入する最大の利点だと考えてるのでそーゆーのが考慮されてないといまいちだなぁ
285:デフォルトの名無しさん
07/01/11 20:03:56
>>284
> propertyってどんな機能を指してるのかよくわかんないんだけど
それ自体も議論の対象っぽい。
getterやsetterの呼び出しのシンタックスシュガーだけじゃなくて
暗黙的なフィールドやgetterやsetterの宣言のシンタックスシュガーまで含んでたり。
例えば、public property int hoge; って書くと、暗黙のうちに
private int hoge;
public void setHoge(int h){ hoge = h; }
public int getHoge(){ return hoge; }
が自動生成されるとか。
java.lang.Class に getProperty みたいなメソッドを追加したいって人も居るし。
JavaBeans の場合は firePropertyChange よんだりも！ってのもあるかもしんないし。
他にも色々あるんじゃない？
>>283 で紹介されてる実装だと、property つけて宣言しないと
シンタックスシュガーでセッターゲッターにアクセスできなかったりする。
286:デフォルトの名無しさん
07/01/11 20:22:31
> フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
でも、これって 5文字ぐらい節約できるってだけなんだよねぇ……
287:デフォルトの名無しさん
07/01/11 22:05:40
>>286
いやいや違う、漏れが言いたいのは
//フィールドの定義
private int fieldX = 0;
//値をセットするときに必要な特殊処理
public void setX(int x){
this.fieldX=x;
this.logic();
}
//プロパティの定義でgetterはそのまま使って、setterはメソッドを使う
property int x read fieldX write setX;
イメージ的にはこんな感じ。ほぼObjectPascalなんだけどさ。
フィールドの定義は省略して、暗黙的に定義してくれるとなおよさげ。
288:デフォルトの名無しさん
07/01/11 22:43:37
>>287
その辺は どー転ぶかわかんない。property 自体却下される可能性もあるし。
とりあえず >>283 のプロトタイプだとできない。
> property int x read fieldX write setX;
この構文だと、Java では フィールド名と同じメソッド名付けられるから
fieldX って名前のフィールドに加えてメソッドまであったらどーすんだろ、とか
setX 以外の名前が指定できると、現在既にあって setX を期待してる
フレームワークが困りそうだなぁ、と思った。
289:デフォルトの名無しさん
07/01/12 23:43:12
URLﾘﾝｸ(jcp.org)
Eclipse FoundationがJCPメンバーとして参加することに
なったらしい。ちょっと前にEclipse代表のMike Milinkovichが
JSR277とJSR291の進行に激怒してたからなんかやるだろうなとは思ってたけど。
JSR291に反対票投じたRedhatも先月推進派に転じたみたいだし、さらに今度の
Eclipseの票も加えて1/16～22にあるJSR291の投票をのりきりたいんだろうね。
290:デフォルトの名無しさん
07/01/16 01:46:34
>>287
setXxx、getXxxっていうのをプロパティとみなす仕様は変えれないと思うよ。
IDEのプロパティエディタやらJSPのELやら、既存のツールやライブラリが使えなくなる。
291:デフォルトの名無しさん
07/01/16 05:09:43
Java6の話はどこですればいいのかな？
292:デフォルトの名無しさん
07/01/16 19:56:31
>>291
現世代Javaの動向 1
ｽﾚﾘﾝｸ(tech板)l50
293:デフォルトの名無しさん
07/01/18 08:02:25
AjaxでハイブリッドP2P型を作成しようと思っているのですが、
これを作るにはJ2SE,J2EE,J2MEの内、どれが相応しいのでしょうか？
次世代Javaに詳しい方教えて下さい。
294:デフォルトの名無しさん
07/01/18 08:06:11
mustang で普通に起動した JVM に jconsole からアタッチできるようになったという
記事を見て jconsole を使おうとしたんだけど、起動後に "JConsole: Output" っていう
ウィンドウが開いて
java.lang.UnsatisfiedLinkError: no attach in java.library.path
というエラーが表示されるし、ローカルプロセスに接続しようとしても
「接続に失敗しました」となってしまいます。
うまく JVM にアタッチするにはどうしたらいいんでしょうか？
Windows XP, JDK 1.6.0 を使っています。
295:デフォルトの名無しさん
07/01/18 19:15:17
>>293
構成が今一良く分からない。Webサーバ＋P2PでUIがブラウザなわけかい？
J2EEのServlet（Jettyあたり）を落としてきて、残りはSEでガリガリ書きなさいな。
296:293
07/01/19 07:57:58
>>295
P2Pでコミュニティとファイル共有システムを作って、ソフトウェアで提供しようとしているので、
中継ノードでピュアP2P型にするか、中央サーバーでハイブリッドP2P型にするかのどっちかになるのですが、
それぞれJ2SE,J2EE,J2MEのうち、何が相応しいのでしょうか？
教えて下さいませ。
297:デフォルトの名無しさん
07/01/19 10:32:49
>>296
まず、J2SE,J2EE,J2MEが何かぐらいは調べて置いたほうがいいだろ。
それとスレ違い。
298:デフォルトの名無しさん
07/01/19 15:30:45
JDK7 build06
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
個人的にはまだぱっとした新機能ないなぁ
299:デフォルトの名無しさん
07/01/19 20:33:11
Java6の役目はその機能ではなく、1.4.2を古いものとし、
Generics環境へのGOサインを導き出してくれることにある。
Java7もXML構文とか登場してまた汚れる（ｗ）から
Java7のデビューはJava8のリリースからとなる。
300:デフォルトの名無しさん
07/01/19 23:12:57
Genericは結構なんだけど旧形式のコレクションも@deprecatedにしないで
共存させといて問題ないと思うのだが。これのせいで１．４からの移行が進みにくい。
301:デフォルトの名無しさん
07/01/19 23:15:09
5.1が出ないってことは、最近のJREはアーキの急遽対応がないんだな。
6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
302:デフォルトの名無しさん
07/01/20 01:27:40
6はおまけっぽいのがてんこもりだからね。
303:デフォルトの名無しさん
07/01/20 01:29:35
>>300
どういうこと？
304:デフォルトの名無しさん
07/01/20 01:55:04
普通に「互換性あれば簡単に乗り換えれるのに」って意味じゃないの？
305:デフォルトの名無しさん
07/01/20 02:22:19
コレクションは互換性のために残されたレガシーコレクションとはあるが
非推奨だなんて注釈もdocタグも無いはずなんだが。
306:デフォルトの名無しさん
07/01/20 02:28:02
> 6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
1.5.1 とか 1.6.1 とか出さないって言ってなかったっけ？
307:デフォルトの名無しさん
07/01/20 03:06:14
ああこれのことね。無視すればいいけど、うちは何も考えずに<Object>つけてるぞイミねぇ
注: ArrayListDemo.java の操作は、未チェックまたは安全ではありません。
注: 詳細については、-Xlint:unchecked オプションを指定して再コンパイルしてください。
308:デフォルトの名無しさん
07/01/20 03:17:36
無視したいなら@SuppressWarnings("unchecked")でいいじゃん
309:デフォルトの名無しさん
07/01/20 06:46:59
>>307
<?>の方がよくねぇ？
310:デフォルトの名無しさん
07/01/20 13:18:36
例外にもジェネリクス対応して欲しいな。
型パラメータが付いたThrowableのサブクラスを作りたい。
例えば、
class IORuntimeException<IOException> extends RuntimeException{
}
のように定義して、
catch(IORuntimeException e){
throw e.getCause(); //<--IOExceptionをスロー
}
と使えると最高。
311:デフォルトの名無しさん
07/01/20 15:38:32
RuntimeExceptionが何故IOExceptionを投げるんだ・・・
312:デフォルトの名無しさん
07/01/20 15:49:49
IOExceptionをRuntimeExceptionでラップしたいんだろ。
313:デフォルトの名無しさん
07/01/20 16:06:04
>>310
Closure で例外を透過的に使うために、ってんで検討はされてるけど、
>>310 みたいな気持ち悪い奴じゃない。
314:デフォルトの名無しさん
07/01/20 16:31:14
Neal Gafter's blog
Thoughts about the future of the Java Programming Language.
URLﾘﾝｸ(gafter.blogspot.com)
315:310
07/01/21 01:49:23
キモくてスマン。
単純にチェック例外を実行時例外でラップしたいだけ。
例外にジェネリクスが使えると、色々面白そうだけど。
class Hoge<T>{
void piyo() throws WrapperException<T>{
...//色々
}
void fuga() throws T{
try{
piyo();
}cathc(ExceptionWrapper<T> e){
throw e.getCause();
}
}
}
316:デフォルトの名無しさん
07/01/21 02:15:50
> void piyo() throws WrapperException<T>
> }cathc(ExceptionWrapper<T> e){
……。
ってか、普通に考えて ExceptionWrapper<InvocationTargetException> と
ExceptionWrapper<IllegalAccessException> が実行時に同じクラスに
成り下がりそうで拙いよね……
まぁ、ある意味では「色々面白そう」だけど。
317:デフォルトの名無しさん
07/01/21 11:26:48
>>300
問題ないはずだけど
>>308
は旧式のライブラリとの境目で使う
事実上JPAでも必須だけど
>>309
明示的にするなら<Object>のほうがいいとおもう
ただ、これを使ってる時点でGenericsの恩恵ゼロだけどね
従来のライブラリ葉変更せずに使う場合>>308を接合部分につかってラッピングするべし
318:デフォルトの名無しさん
07/01/23 10:31:36
突然だけど将来的にSEとEEにApache FOPも追加してくれんかな？
そうすると標準ライブラリだけでXML何でもあり状態で便利なんだが。
EEは需要ありそうだが・・・
ただでさえjdk6は標準ライブラリだけで近代的なブラウザが書ける奇抜な言語だぜｗ
319:デフォルトの名無しさん
07/01/23 15:43:59
安藤幸央のランダウン[32]
Java SE 6へ移行する理由と移行をとどまる5つの理由
URLﾘﾝｸ(www.atmarkit.co.jp)
320:デフォルトの名無しさん
07/01/23 18:04:30
>>319
Itanium 1、2がサポートされなくなったのか。
Itanium おしまいだな。
321:デフォルトの名無しさん
07/01/23 21:53:16
>>319
なんか、細かいミスというか認識不足が多すぎる気がするよ。
Java SE 7は、もうDolphinとは呼ばれてないはずだし。
322:デフォルトの名無しさん
07/01/23 21:59:45
というか、JDKとJava2SE/JavaSEが混同されすぎ。
323:デフォルトの名無しさん
07/01/24 18:06:01
>>319
正式リリースされている 6系の話題は、現行スレでお願いします。
324:デフォルトの名無しさん
07/01/24 19:59:04
java.comがjre6を頒布するのはいつごろの予定なの？
325:デフォルトの名無しさん
07/02/02 17:04:58
JDK7 build07
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
やはりまだnew featureよりバグフィックスが目立つ
326:デフォルトの名無しさん
07/02/02 18:15:15
>>322
いまならJava SE
JDKは開発キットだからな(JREに対しての)
327:デフォルトの名無しさん
07/02/02 18:16:33
>>319
> 1.3.1以前のバージョンはEnd of Life、サポート終了の扱いです。
なるほど。古いことは気にしなくて良いとは
気が楽だ
法務省のJavaアプリが古いJVMに
しか対応していなかった問題も解決されると願う
328:デフォルトの名無しさん
07/02/02 19:20:14
1.4も1.4.2までいったから多少長かったけど、今からだとサポート期間短いよね
2世代前のものだから当たり前だが
329:デフォルトの名無しさん
07/02/03 08:40:58
>>327
MOJ乙
330:デフォルトの名無しさん
07/02/08 21:18:56
Closures for the Java Programming Language (v0.5)
URLﾘﾝｸ(www.javac.info)
{int,int=>int} plus = {int x, int y => x+y};
うーん、もすこしメソッドと同じような文法にならなかったのかな・・・
331:デフォルトの名無しさん
07/02/09 02:06:03
>>330
新しいのは
・nominal version が消えた。
・ユーザ定義のループ定義が草案入り。
ぐらいか。
より良い構文を考え付いたなら、
そっち方面の人のブログにでもコメントしとけば？
332:デフォルトの名無しさん
07/02/09 02:06:58
>>329
MOJ?
何それ？
333:デフォルトの名無しさん
07/02/09 09:01:30
ぐぐると一番最初にくる省庁の英語略称
そこの担当者
334:デフォルトの名無しさん
07/02/10 14:59:27
Java++
335:デフォルトの名無しさん
07/02/11 20:39:31
Java#
336:デフォルトの名無しさん
07/02/12 01:18:02
=>
ってどっかで見たことあるような
337:デフォルトの名無しさん
07/02/12 03:26:06
PerlやPHPのハッシュに使う演算子だろ。
338:デフォルトの名無しさん
07/02/12 07:48:17
Java2.0
339:デフォルトの名無しさん
07/02/12 13:04:01
>>338
それはもう古いぞ
340:デフォルトの名無しさん
07/02/12 13:24:02
JavaX
341:デフォルトの名無しさん
07/02/12 13:42:03
>>338-339
ﾜﾗﾀ
342:デフォルトの名無しさん
07/02/12 14:25:37
>>340
それはjavax.rmiみたいなパッケージとして存在するし
>>338
今はJava 6 の時代だろ
343:デフォルトの名無しさん
07/02/12 14:33:13
>>340
JBuilder Xを連想した。
344:デフォルトの名無しさん
07/02/12 15:56:36
JavaOSX？
345:デフォルトの名無しさん
07/02/12 17:26:37
Java Vista
346:デフォルトの名無しさん
07/02/12 17:58:03
JavaMillenniumEdition
347:デフォルトの名無しさん
07/02/12 18:33:41
Javaって、いつからOSになったんだ？
348:デフォルトの名無しさん
07/02/12 18:34:34
JNodeから
349:デフォルトの名無しさん
07/02/12 18:35:56
Japan Vistaと
Java MEみたいだ
350:デフォルトの名無しさん
07/02/12 20:05:48
JavaMX
351:デフォルトの名無しさん
07/02/12 21:06:04
JMXみてえじゃねえか
(Java Management Extension)
352:デフォルトの名無しさん
07/02/13 05:36:14
Java侍
353:デフォルトの名無しさん
07/02/13 15:41:53
ooの画面ってJavaみたいに見えるし、
実行はネイティブみたいだし、
あれはどういうテクノロジーなんでしょうか？
354:デフォルトの名無しさん
07/02/13 23:17:23
oo?OOoか？
eclipseもOOoもネイティブな実行ファイルはただのダブルクリッカブルじゃなかった？
355:デフォルトの名無しさん
07/02/14 01:53:19
>>353
Swingのように自前でUIコントロールを描画しているのかねぇ？（謎
356:353
07/02/14 08:42:19
＞ネイティブな実行ファイルはただのダブルクリッカブル
ダブルクリッカブルって何ですか？
OOoはクロスGUIを使ってるからモッサリなんじゃないですか？？？
モッサリでも良いからクロスGUI欲しいお。
357:デフォルトの名無しさん
07/02/14 08:53:48
ググレカス
URLﾘﾝｸ(api.openoffice.org)
358:デフォルトの名無しさん
07/02/14 10:40:15
>>357
（＞＜；） なんにもわかんないんです！＞＜
/つと ﾉ
しー-Ｊ
359:デフォルトの名無しさん
07/02/14 13:57:37
>>356
クロスGUIつーかSwingのLnFが何やってるか知ってるか？
360:デフォルトの名無しさん
07/02/14 14:12:15
（＞＜；） Swingを使った事はありますがLnFわかんないんです！
/つと ﾉ
しー-Ｊ
361:デフォルトの名無しさん
07/02/14 14:28:01
>>353
あれはC++だろ。
362:デフォルトの名無しさん
07/02/14 14:28:44
>>356
普通に考えて
Double Click + able
ダブルクリック可能って意味になるだろ
363:デフォルトの名無しさん
07/02/14 14:30:45
>>360
URLﾘﾝｸ(e-words.jp)
URLﾘﾝｸ(ja.wikipedia.org)
364:353
07/02/14 14:47:38
Java2より前のSwingしか使った事無いのですが、
今のSwingってXMLのスキンとかいうやつですか？
そのUIから、実行ファイルみたいなのをキック？
それともJNIコール？
365:デフォルトの名無しさん
07/02/14 15:03:35
>>364
言ってる意味がわからないが
勝手に言ってることを予測して答えてみる。
今のSwingは性能が良い。
スキン変更はJavaプログラムで可能。
そのためWinXPのルナスキンを利用可能。ただしこれはWin
意外のOSで使うと著作権侵害になるのでWinのとき専用。
MacのときはMacのスキンも使える。
よって見た目は綺麗。XAMLやCAMLやXULみたいな、
XMLでスキンを変えられるかどうかということについてはよく知らない。
キック？ については、これも推測すると。
恐らく、Java Web Startの事を言っているのかと推測。
SwingアプリをJava Web Startに対応させるには、拡張子がjnlpという
XMLファイルを作って、そこの決められたフォーマットでSwingアプリの
main()メソッドがあるクラスへのリンクや
バージョン情報、必要なJREのバージョンなどを記述する。
すると、ブラウザ上で拡張子jnlpファイルを見つけると、まさにキックされ、
MIMEタイプを確認し、JREが入っているかどうかを確認し、バージョンチェックされ、
Java Web Startが起動し、Swingアプリのバージョンをチェックされ
Swingアプリが起動し実行される。
Java Web Startは、JNIは一切関係が無い。
366:353
07/02/14 15:09:13
OOoのような画面をクロス環境（Win、MAC、Linux）で使いたかったらどうすれば良いのでしょうか？
で、処理部分はC++を使いたいです。
367:デフォルトの名無しさん
07/02/14 15:10:08
Java2より前ってことはオプショナルパッケージのころか
そのときの知ってる人はもう少ないな
あの当時とはもはや別物だと思っていい
WebStartは今はデスクトップやプログラムメニューなどのショートカットに対応
つまり2回目からはブラウザの起動すら必要はない
そしてプログラムの追加と削除でもアンインストールができるようになってる
もちろん今までどおりコントロールパネルのJavaキャッシュからの削除なども出来る
368:デフォルトの名無しさん
07/02/14 15:18:38
OooでJavaを使うのは、文書にJavaアプレットを埋めたりするくらいじゃな
かったか?
もしかしてMetalでない各プラットフォームで固有LnFにしたいってだけの
話なら、
String sysLnfClassName = UIManager.getSystemLookAndFeelClassName();
UIManager.setLookAndFeel(sysLnfClassName);
369:353
07/02/14 15:23:15
いや、Java側から考えるのでなくて、
C++のコードがあるのですが、
GUI部分を１つ定義してWin、MAC、Linux全対応したいです。
そのときにC++側からSwing画面を開けるのかなー？、と。
370:デフォルトの名無しさん
07/02/14 15:26:58
JNIはC++ APIもあって、データのやりとりも出来るので、
GUIをSwingで作って、エントリとなるメソッドをC++から
キックすればOK。
371:デフォルトの名無しさん
07/02/14 15:39:37
>>364
Java2以前ってことはSwingというよりJFC?
XMLスキンは、恐らくSynthLookAndFeel
>>353
やりたいのは、NeoOfficeのやってることだな
GUI描画部分を、Javaにやらせるという
372:353
07/02/14 15:43:18
MACでもJNIを簡単に作れますか？
373:353
07/02/14 15:45:00
NeoOffice見ましたが、MACのみ。
クロスＧＵＩとして使われてるわけじゃないんだ？
374:デフォルトの名無しさん
07/02/14 16:34:17
MacOSXにおいてJavaは標準サポートされてるし、JNI関係のヘッダもツールも
ある。C++コンパイラはg++。
製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて
くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。
antも入ってる。
375:353
07/02/14 16:42:45
じゃ、Javaで画面作って、C++コードはg++でコンパイルすれば宵ってことかぁ。
”Java＆C++”の開発効率がちょっぴり不安。
376:デフォルトの名無しさん
07/02/14 17:04:19
>>366
Swingの勉強をする。
377:デフォルトの名無しさん
07/02/14 17:35:14
>>375
俺はやったけど、両方わかってりゃ大した事は無かった。
つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。
あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。
java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。
テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。
まー規模にもよるだろうが。
378:353
07/02/14 17:38:49
ｻﾝｸﾂ>>377
DLLコールと比べて、さらに効率悪いのかなぁ？
出来上がったアプリはやっぱりモッサリ？
379:デフォルトの名無しさん
07/02/14 17:51:13
次世代Javaの動向と関係ない話題は他所いってやれ。
380:デフォルトの名無しさん
07/02/14 17:53:03
次世代Java＝C++と連携
ですが、何か？
381:デフォルトの名無しさん
07/02/14 17:54:42
ところで、次世代Javaというか有力候補のウィンドウライブラリって何？
Swingって落ち目な感じ？
382:デフォルトの名無しさん
07/02/14 18:03:33
Swingは1.4以降実用レベルになってしまったから、
SWTとかの代替候補の立場が微妙になってるのが現状じゃね?
383:デフォルトの名無しさん
07/02/14 18:12:19
あ、SWTが落ち目なんだ知らなかった。
知らないうちに勢力図が変わるんですね。
それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
384:デフォルトの名無しさん
07/02/14 18:20:25
其処までは行ってない。
むしろ、SWTの活躍の場は、eclipseしかない、という感じ。
Netbeansは、Jackpotがどうなるか、か？
誘導
Java 高速GUI SWT 3
ｽﾚﾘﾝｸ(tech板)
Java低速GUI Swing 5
ｽﾚﾘﾝｸ(tech板)
【Java】NetBeans Part2【Sun】
ｽﾚﾘﾝｸ(tech板)
385:デフォルトの名無しさん
07/02/14 18:27:26
オライリーだっけ
去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの
一番使われてるのに負け組みはおかしいといわれたそうだが
386:デフォルトの名無しさん
07/02/14 18:41:27
ふ～ん
じゃぁ、NetBeansとSwing使っとけば問題無いか。
Windows上だとちょっぴりモタツクだろうけど。
でも、モッサリドトネト（流行ってないくせにWinForms、WPFと２つあって最悪）よりかはましか。
387:デフォルトの名無しさん
07/02/14 18:42:36
ごめん、もう一つ教えて。
NetBeansがEclipseをやっつけたってことは、
JBuilderとかは無用の長物？
388:デフォルトの名無しさん
07/02/14 18:50:15
ごめん、さらにもう一つだけ教えて下さい。
以前のSwingではレイアウトマネージャのおかげで、
思ったように画面作り難かったのですが、
今のSwingはポトペタしやすいですか？
389:デフォルトの名無しさん
07/02/14 18:59:48
>>388
NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。
と、漏れは個人的には思っている。
390:デフォルトの名無しさん
07/02/14 19:11:20
>>380
JNI なんぞは、1.1 の頃には既にあったわけなんだが……
誘導
★お前らJavaはJNIで組もうぜ★
ｽﾚﾘﾝｸ(tech板)
391:デフォルトの名無しさん
07/02/14 19:14:29
>>388
個人的には、GUIポトペタ(←(・∀・)ｲｲ!!)は、Netbeans。
ロジック書き書きは、eclipse。
両方使ってるよ。
NetbeansのSubversionプラグインは使いにくいし。
392:デフォルトの名無しさん
07/02/14 19:24:34
じゃ、Netbeans使います。
CVSはWinCVS（←もしかしてサイアク？）使ってるんで。
JNIもふつーに使われてますか？
393:デフォルトの名無しさん
07/02/14 19:27:48
誘導
【Java】NetBeans Part2【Sun】
ｽﾚﾘﾝｸ(tech板)
394:デフォルトの名無しさん
07/02/14 19:57:46
名前のないメソッドつくろうぜ。例えば、
public class ArrayList<E> {
public nameless E (int index) { return get(i); }
//その他省略
}
のように書いて
String s = list(2); //listはArrayListのインスタンス
みたいにインスタンス名(引数)の形で呼び出す。
他にも、Mapなら
public nameless E (K key);と書いて
String s = map("key0");とか、
さらに、オーバーロード可能にすれば他にも使い方ができそうだ。
395:デフォルトの名無しさん
07/02/14 20:06:55
>>394
じゃあ標準出力はSystem("%d%d", 100, 200);でOK？
396:デフォルトの名無しさん
07/02/14 20:18:36
関数呼び出しのときの表現を変えるのをアノテーションで定義するのはどうだろう
@Alias(value = "ltgt" , type = "literal")//自作リテラル（ここでは<>）
@Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード
これで実装するなら>>394は
@Alias("nameless")
ってとこか
んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。
まぁ設計がまずいのに無理やり使わされるのもあれだしね。
397:デフォルトの名無しさん
07/02/14 21:33:06
> それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
その文字を見たら昔のSunのCMを思い出した。
398:デフォルトの名無しさん
07/02/14 21:45:16
396だけど、だめだな。
細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。
よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。
399:デフォルトの名無しさん
07/02/14 22:40:43
>>394
>>396
次世代Javaの動向をヲチるスレであって、
勝手な妄想繰り広げるスレじゃないから。
400:デフォルトの名無しさん
07/02/14 22:48:56
>>394
C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。
演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。
401:ﾈｶﾏ由紀恵
07/02/14 23:05:20
Groovy でやっていることは
入れなくても良いんじゃ・・？
402:デフォルトの名無しさん
07/02/14 23:23:43
ていうか今時中身の処理が遅いからJNIなんてのは無いな。
特殊なデバイス叩かん限りpureJavaでいける。
実行速度なんて5.0 6.0で激変したしSwingも1.3→1.4以上でまともになったし。
joy pad使うとかしかJNIの存在理由が見当たらん・・・。
ここら辺は成熟してきたからこれ以上はOpenGLドライバの成熟待ちだろ。ATIもnVidiaも最近のドライバはOpenGLが糞。
そのせいで6.0でもsun.java2d.openglプロパティが使い物にならない。
Java側はドライバの対応を待つしかないからベンダと連携とって行くって言ってるし。
俺はあまり言語仕様を動的にするのには興味ないな。
仕様が複雑化してきてるし当初の仕様ポリシーから外れてきてる気がする。
個人的には値渡しの出来る構造体が欲しいかな。
一々データクラス定義してインスタンス化するのがちょっと・・・
403:デフォルトの名無しさん
07/02/15 00:06:36
>>402
public type Hoge{
String hoge;
int piyo;
}
見たいな感じかな。でも予約語が・・・
JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。
404:デフォルトの名無しさん
07/02/15 00:36:38
>>402
そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。
405:デフォルトの名無しさん
07/02/15 01:23:08
>>391
NetBeansのSubversionは動作がよくおかしくなる
というかAntとかもおかしい気がする
JDKを5.0にすると安定するから6のVMバグかも
>>392
CVSだったらNetBeans標準装備なんでそれ使えば楽
>>402
Swingは速度が目立つけど、実際は1.3で実用になるようなAPIが多数追加されて
5.0で目立つようなのが追加されていたりする
6も5.0と同じくsun.java2d.opengl使い物にならないね
JOGL自体は安定してるんだがGLJPanelのほうがイマイチなのもなおらねぇ
というかベータ時代はOpenGL有効にして動いてたような気がするのが気になる
406:デフォルトの名無しさん
07/02/15 01:34:56
>>400
その下の奴って構文解析できるのか？
class hoge{}
class A {
public static Object method(int arg){ return null; }
public static int (int lh)method(int rh){ return lh + rh; }
public static void main(String[] args){
int hoge = 0;
(hoge)method(10);
}
}
とかされたら面倒なよーな気がする。
407:デフォルトの名無しさん
07/02/15 07:18:52
>>399
昔は希望を書きまくっていた気もするが？
408:デフォルトの名無しさん
07/02/15 08:40:38
>>402
遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。
CocoaとかいうやつはObjective-Cだったりして困るし。
409:デフォルトの名無しさん
07/02/15 08:51:30
>>407
希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。
ksl とかあるんだし。
URLﾘﾝｸ(ksl.dev.java.net)
410:デフォルトの名無しさん
07/02/15 08:56:41
>>406
int Integer = 1;
System.out.println( (Integer)+10 );
とかと同じ扱いにすりゃ良いんじゃないかと思ったけど……
参照型へのキャストは 単項+ とか 単項- ついたらいかんのか。
つまり Integer って変数が宣言されてないときに
System.out.println( (Integer)+10 );
がコンパイルエラーになるから参考にならんと。むぅ。
411:デフォルトの名無しさん
07/02/15 17:24:26
>>399
ヲチりながら、愚痴るんじゃないの？
412:402
07/02/15 17:43:18
>>405
リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなｗ
>ベータ時代は・・・
URLﾘﾝｸ(bugs.sun.com)
これの応急処置だと思う。
JDialogに限らずOpenGL使ったコンポーネントが破壊される。
描画領域の破壊は-Dsun.java2d.opengl.fbobject=falseを指定すれば回避できるが・・・
FBO周り以外もバグがあるみたいでどうも-Dsun.java2d.opengl.fbobjectに関係なく-Dsun.java2d.opengl使った処理自体まずいみたい。
nVidiaのリグレッションバグなんだがOpenGL有効にしたらグラボ自体が不安定になって最悪システムクラッシュする。
グラボのドライバって既存アプリの描画に影響を与えるしな。リグレッションバグならそうそう戻す訳にはいかんだろうし。
>>408
結局JNI噛ます共有ライブラリ部分はネイティブなんだからリビルドするだろ？
てかwinのライブラリをmacで使おうって発想もな。
JNIにしたってネイティブ部分はプラットフォーム毎に用意するんだし。
J2MEはそれでカオスってるｗ
413:デフォルトの名無しさん
07/02/15 18:05:37
C++のコードをJavaに移植するほうが早そうだな
414:デフォルトの名無しさん
07/02/15 19:04:29
>>413ロジックのみならね。
Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、
Win→だとGUI周り以外はそうgdgdにならない？
415:デフォルトの名無しさん
07/02/15 19:11:21
あーJ2MEはJSR118-MR2からOpenGL実装したので専用チップ要求して更にカオスｗ
MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化（新たに取り込まれたオプションパッケージが目立つ）してSEのノウハウもフィードバックされて結構良いんだが・・・
416:デフォルトの名無しさん
07/02/16 17:45:58
>>402
OpenGLといえばJava3Dを思い出した。
あちらも気が付けば大きな進展があるようだ。
JavaからOpenGLのライブラリを使えるようにするというやつ。
プラットフォーム非依存と呼ばれているJavaも3Dとなると
そうもいかないケースがあるものだが、
今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく
なるか、(AWTのようにOS依存する)劣化表示
or
(Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。
417:デフォルトの名無しさん
07/02/16 17:48:15
>>405
> >>391
> NetBeansのSubversionは動作がよくおかしくなる
> というかAntとかもおかしい気がする
> JDKを5.0にすると安定するから6のVMバグかも
EclipseでJava SE 6でAntを使っているがとくに問題ない。
おかしいってどんなエラーがでるのかね。
Subversionは不安なら、TortoiseSVNでコミットしてみるのはどうだろう。
> >>392
> CVSだったらNetBeans標準装備なんでそれ使えば楽
Eclipseと同じだな。しかしSubversion使ったらもうCVSには戻れない。
それだけ使い勝手が良いから。
418:デフォルトの名無しさん
07/02/16 20:23:44
そろそろ
MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな
419:デフォルトの名無しさん
07/02/16 21:14:44
JSR 296: Swing Application Framework
URLﾘﾝｸ(jcp.org)
これどうなるかねぇ。
420:デフォルトの名無しさん
07/02/16 21:17:41
>>416
JavaからOpenGL使うのはJOGL
去年1.0でたばっかりなのでこれからだと思うがOpenGL2.0がそのままラッピングされている
結果SWTのように汚いけど、これはCのコードのラップだからこれはこれでいいだろう
結果staticImportと相性がいい
まぁJOGLはSwingとは直接関係ないけど
>>417
Java6はVMがバグってるので演算結果がたまにおかしくなるというひどいバグがある
次のupdateでなおってるはずだけど最適化のバグっぽい
まぁ5.0とは別次元の速度になってるんでこんなにVMに手を入れていいのだろうかと思ったけど
予想通りVMのコアにバグいれるとは
はじめてオープンソースになった成果がこれってひどすぎ
つまりsubversionだけじゃなくてNetBeans自体が不安定になる＞JDK6
それにトータスは使い物にならないよ
バージョン管理ツーつってのはIDEと統合されてナンボだから
>>418
Swingの時点でMFC以上にラッピングされてるのだが
421:デフォルトの名無しさん
07/02/16 21:21:08
Swing Application Frameworkのプロトタイプ実装らしい。
URLﾘﾝｸ(appframework.dev.java.net)
見てみよっと。
422:デフォルトの名無しさん
07/02/16 21:55:57
SwingのラッパーはGroovyやRhinoから使うの便利そうだな
423:デフォルトの名無しさん
07/02/16 21:58:35
>>420
URLﾘﾝｸ(d.hatena.ne.jp) で話題になってた
URLﾘﾝｸ(bugs.sun.com) か？
J2SE 1.4.0 のときも、コードによっては 1.3.1 より遅くなって処理完了まで
2倍時間かかったり、とかあったしなぁ。個人的にはいつもの事だと思うんだけど。
ってか、JDK6 は既に現行世代だと何度言えば……
424:デフォルトの名無しさん
07/02/16 22:20:15
>>421
SessionStorage.WindowState って最大化状態サポートせんのか？ と思って
users@appframework.dev.java.net に検索かけたら
URLﾘﾝｸ(appframework.dev.java.net)
で、最大化状態は保持してるみたい？
最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな？
425:デフォルトの名無しさん
07/02/16 22:30:55
>>424
最大化解除したサイズって、どっかのメソッドで取れたっけか？
常に Frame のサイズ保存しておきながら WindowEvent おっかけて、
Frame#getExtendedState が MAXIMIZED になったら、
直前のサイズを最大化解除したサイズとして保存するとか、
Windows と他の OS で最大化する時の WindowEvent の届き方が違うので
面倒くさくて Windows だけしか対応しないとか、そんな記憶が……
426:デフォルトの名無しさん
07/02/16 22:44:31
>>423
いつものことの上、
修正コードが手早く手にはいるようになっただけで
大助かりですよね。
うまく動かなくなるバグなんて、1.4の頃ですが
GC周り突っつけばすぐ出てきましたよ。
バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。
直るにしても、次のリリースまで待たなきゃ駄目だしね。
427:デフォルトの名無しさん
07/02/16 22:55:57
とはいえ今はJDK7で自分で治せて配布できるようになったのは大きいかも
428:デフォルトの名無しさん
07/02/17 00:06:11
>>420
んなの初めて聞いた。バグ修正もてえへんだろうなあ。
TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を
するときもわざわざ右クリックでめんどいことしないといけないけどさ。
429:デフォルトの名無しさん
07/02/17 00:10:08
>>427
直すのかなり難解だと思うが・・・。
Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを
作れるのだろうか。
430:デフォルトの名無しさん
07/02/17 00:11:12
そもそも新しくなるの?
431:デフォルトの名無しさん
07/02/17 00:18:35
NetBeansのSubversionは修正がされているかどうかがわざわざ再表示押さないと反映されないのがカス
コミットする前に最新状態取得しないとだめってあふぉか
CVSクライアントのほうは問題なし
というかSubversionはCVSのように自前で実装してないからなぁ
CVSモジュールに依存してるし
NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ
だから標準実装されてないのだろうね
432:デフォルトの名無しさん
07/02/17 01:02:26
>>424
> で、最大化状態は保持してるみたい？
保持してないんじゃね？単に最大化したbounds持ってるだけで。
ってか、WindowStateだしな。getExtendedState使えるのFrameだし……
433:デフォルトの名無しさん
07/02/17 02:32:28
>>431
SVNはCVSにそんなに依存していたっけか。
434:デフォルトの名無しさん
07/02/17 08:40:54
>>433
NetBeansのsubversionモジュールはCVSモジュールに依存している
435:デフォルトの名無しさん
07/02/17 19:04:07
SE 6てOSSにしてからコードの提供あったの？
６で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。
あの超進化マジックは何？
ヒープの割当・インクリメンタルＧＣのアルゴリズム変更だけであそこまで変わるとは思えん。
＃まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。
そろそろstaxとrhinoが使われだしても良いと思うんだ・・・
436:デフォルトの名無しさん
07/02/17 19:13:41
>>434
なんだ、そういうことか。
CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に
対してかなり起こっていたからな。
「すでにCVSがあるのに、なんで独自に開発するんだ？」と質問された
ことについてもう反論していた気がする。
437:デフォルトの名無しさん
07/02/17 20:01:54
>>435
インクリメンタルGCの変化あったの?
5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど
またかわったの？
速度は強度の最適化がクライアントVMでかかってるのがわかる。
演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。
だからサーバーVM同梱してないのだなと。
438:デフォルトの名無しさん
07/02/18 18:07:24
レジスタ割付アルゴリズムが Linear Scan Register Allocation
とかいうものに変更されたとは聞いているが、そんなに効果があったのかー
Linear Scan Register Allocation
URLﾘﾝｸ(www.research.ibm.com)
439:デフォルトの名無しさん
07/02/18 19:25:03
従来のバイナリをいじらずおおむね2、30%速度向上してるんだよね
440:デフォルトの名無しさん
07/02/19 12:35:31
そろそろABAPみたいにSQLをネイティブに書けるようになると思うんだ。
441:デフォルトの名無しさん
07/02/19 12:59:36
>>437
インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ？
5の段階では、Xinc使うなって言われてて・・・・
何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。
むしろ、Hotspot系だと思うな。
エスケープ分析効いてないかな？
というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる？
JVMの機能強化ってJCPに乗らないと思うし・・・
442:デフォルトの名無しさん
07/02/19 13:03:38
5.0からだよ、コンカレントGCにかわったのは
1.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね
トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた
GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう
６でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと
443:デフォルトの名無しさん
07/02/20 19:28:14
Lucidaフォントに日本語を追加する事ってできるの
444:デフォルトの名無しさん
07/02/21 15:02:25
可能だけど莫大な金と人材と時間と日本語を熟知したフォントデザイナが必要だからsunだけじゃ不可能。
フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。
所でJavaってGCが勝手にメモリガリガリやってるから
メモリの断片化をプログラマで制御出来ないよな？
長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、
今後ここら辺の解決策はないの？
緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。
＃そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。
今思い出したｗ
445:デフォルトの名無しさん
07/02/21 16:32:00
>>444
System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。
ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。
ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。
どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
446:デフォルトの名無しさん
07/02/21 17:33:20
> 所でJavaってGCが勝手にメモリガリガリやってるから
> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
447:デフォルトの名無しさん
07/02/21 17:47:52
>>446
C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。
勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
448:デフォルトの名無しさん
07/02/21 18:01:42
>>447
それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし
JavaのGCはそのタイミングをコントロールできないという点だけが問題
449:デフォルトの名無しさん
07/02/21 20:44:23
>>445
-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
URLﾘﾝｸ(java.sun.com)
450:デフォルトの名無しさん
07/02/21 23:45:23
>>448
mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
451:デフォルトの名無しさん
07/02/21 23:50:06
>>444
GC でコンパクションが発生するのに断片化って???
452:デフォルトの名無しさん
07/02/21 23:53:01
なんか、全然次世代じゃない話で盛り上がってるな。
453:デフォルトの名無しさん
07/02/21 23:57:03
>>452
いつもの事だ。
454:デフォルトの名無しさん
07/02/22 00:01:05
>>445
> >>444
> System.GCしか今のところコントロールする方法はない。
java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
455:デフォルトの名無しさん
07/02/22 00:02:05
>>445
> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
456:デフォルトの名無しさん
07/02/22 00:04:13
>>446
Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ
C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
457:デフォルトの名無しさん
07/02/22 00:05:52
java.lang.refでオブジェクトの「到達可能性」をコントロールできる
香具師はいないのね
458:デフォルトの名無しさん
07/02/22 00:14:10
>>457
そりゃ、居ないだろ。
あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。
459:デフォルトの名無しさん
07/02/22 01:27:33
>>454
それ定期的に出てくるけどぜんぜんコントロールできねーよ
460:デフォルトの名無しさん
07/02/22 13:56:01
いつの世代でもGCは永遠の謎なのだ。
461:デフォルトの名無しさん
07/02/22 21:22:26
GCなしの方がよかったかもな～
462:デフォルトの名無しさん
07/02/23 00:09:49
GCなしなんていまさらありえんだろ
463:デフォルトの名無しさん
07/02/23 00:26:43
C++に逆戻りか？
464:デフォルトの名無しさん
07/02/23 00:27:32
C++0xの使用をみたが、期待はずれだった。
あんな仕様では当分Javaには勝てないことがわかった。
D言語やC#のほうが全然魅力的だった。
465:デフォルトの名無しさん
07/02/23 00:31:08
もう使用されているとは
466:デフォルトの名無しさん
07/02/23 01:51:35
なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。
467:デフォルトの名無しさん
07/02/23 01:57:48
そうだよな。
チンコの仕様に優れていても、使用に優れてない奴とかいるし。
468:デフォルトの名無しさん
07/02/23 02:01:08
チョンの仕様かと思ったw
チョンのチンコの仕様は9cmで世界一ミクロ
469:デフォルトの名無しさん
07/02/23 02:06:38
仕様も使用もダメな例だな
470:デフォルトの名無しさん
07/02/23 04:24:39
JDK7 build08
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした
471:デフォルトの名無しさん
07/02/23 05:02:19
マネージド○○って完全にわすｒｙ
472:デフォルトの名無しさん
07/02/23 06:35:41
CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry
コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。
マジレスするとunsignedが欲しい。
static final unsigned byte の範囲の定数が欲しいのにって度々思う
#Java書いてるとshortの存在を忘れてint使っちゃう俺
473:デフォルトの名無しさん
07/02/23 07:56:31
>>472
>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。
474:デフォルトの名無しさん
07/02/23 08:57:09
マイナス、負の値を使えばいい。
475:デフォルトの名無しさん
07/02/23 10:10:27
>>473
そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！
そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。
文字列定数の長さを気にする様な世界だ。
ややこしい・・・
476:デフォルトの名無しさん
07/02/23 11:16:49
>丁度0-128を使う
嫌がらせだなｗ
477:デフォルトの名無しさん
07/02/23 11:19:44
>>475
ビット操作でも負数は使えるはずだが
478:デフォルトの名無しさん
07/02/23 12:33:58
まあ、負数使いたくないのは個人的理由でもあるｗ
どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで
マジックナンバーに展開して定数フィールド排除、
クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して
昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。
（まあ、今は難読化だけで間に合うが）
そんなんでshortとかintとかlongなんて無駄に使ってられませんｗ
少数も勿論固定少数点数ですｗ
XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz
一般的にはCLDC用のXMLパーサって10K台だよ。
＃つくづく趣味グラマで良かったと思うこの頃。
よくopera mini何て出来たもんだ
479:デフォルトの名無しさん
07/02/23 13:38:05
>>472
> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺
ラッパークラス作れ
480:デフォルトの名無しさん
07/02/23 13:54:21
>>475
> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
今はJ2MEではなくJava ME。
つうか、もうそろそろ、スペック問題解決してもいいのでは。
昔と比べ、容量は10倍以上になったんじゃないのか？
S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。
昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？
481:デフォルトの名無しさん
07/02/23 13:55:32
>>476
0-127に加えて-1か128を128替わり使えばいいのではと
482:デフォルトの名無しさん
07/02/23 13:56:13
>>478
とりあえず新たにデータ型作るってのはどうよ
483:デフォルトの名無しさん
07/02/23 13:57:12
>>478
jarsで圧縮率を上げればjarサイズが半分になるぜ
484:デフォルトの名無しさん
07/02/23 21:57:02
static final は普通に、コンパイラでインライン展開することが
言語仕様で決まってなかったっけ。
485:デフォルトの名無しさん
07/02/23 22:04:07
今のJava MEではGenericsやアノテーションは
使えるのか？
486:デフォルトの名無しさん
07/02/23 22:05:35
>>484
決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。
それに、ME とかの場合は static final な変数自体も節約したいんでしょ。
487:デフォルトの名無しさん
07/02/24 03:48:32
>>845
使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。
けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。
インターフェイスすら排除する世界だぜｗ
ところでこんなリスト見つけた。VM仕様関連の情報らしい。
URLﾘﾝｸ(www.ingrid.org)
488:デフォルトの名無しさん
07/02/24 12:23:48
>>487
ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ
489:デフォルトの名無しさん
07/02/24 12:59:51
Java SE 5になってから大分高速化したのに携帯電話には
まだ搭載できないでいるのか・・・
しかもまたまた1.3レベルとは。assertも使えぬのか。
アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？
それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。
490:デフォルトの名無しさん
07/02/24 13:32:37
>>487
> URLﾘﾝｸ(www.ingrid.org)
古いね。デッドリンク多いし。
491:デフォルトの名無しさん
07/02/24 15:42:08
>>489
高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？
492:デフォルトの名無しさん
07/02/24 17:23:16
>>488
コレクションFWないよ？レガシーしか。
java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。
端末毎に返ってくる値が違う事があるし端末の時計とは
別にＶＭが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ？
UTCなんてない。
これでもちゃんとした仕様の範囲だから困りもんだ。
>>491
主流はアプレックスのJBlend。
一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。
最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・
ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・
クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから
再開発部分が多いだろうねぇ。
プリベリファイがSEに取り込まれたんだからMEに何かくれよｗ
493:デフォルトの名無しさん
07/02/24 17:52:22
>>492
CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？
TimeZone は GMT をサポートするけど、それを使っても
GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。
そーいや、JSR-310 で Date and Time API ってのがあったような。
あれって、JDK7 の contents だっけか？
494:デフォルトの名無しさん
07/02/24 18:28:20
>>492
System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？
495:デフォルトの名無しさん
07/02/24 18:31:30
>>492
> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。
ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。
そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。
496:デフォルトの名無しさん
07/02/24 19:48:51
>>492
いやVectorとかでいいんだよ
それでも十分使い勝手がいい
中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする
そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが
497:デフォルトの名無しさん
07/02/24 20:10:36
>>489
IBMのJavaME向けコンパイラ/オプティマイザみたいな商用系使ってると
かなりのレベルまでstaticメソッドのインライン展開するし、
アサーションってMEの言語仕様で定めなくてもいいかなって気がするんだよね。
それよりも言語仕様のほうはシンプルにしてアプリケーションプログラマ
のほうで適切にアサーションのutilクラスを書いた方が全体としてシンプルで融通効くと思う。
というかコンパイル時にstaticメソッドのインライン展開なくても
>static final boolean DEBUG = false;
>public void assert(...){
> if(DEBUG){
> System.err.println(...);
> ...
> }
>}
みたいなコードが書けるように1.3でも言語仕様上ifブロックでの到達不能性チェックに
例外が設けられていて、かつ実装系の方でもSunとかIBMとか大体のコンパイラは
DEBUG=falseのときこの部分ごっそり削除してくれるし。
498:497
07/02/24 20:36:05
アサーションだから
>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。
499:デフォルトの名無しさん
07/02/24 20:52:52
なるほどー。
今ならAspectJでもっと効率よくできるかな？
500:デフォルトの名無しさん
07/02/24 22:31:51
>>493
確か仕様上はGMTサポートしろゴルァだけどオチは
>GMT な時間が返ってくるとは限らないってオチはあるかもなー
だったかと・・・
>>495
仕様上は130K程度の不揮発性メモリ（KVM用）と30K程度の揮発性メモリ（コンフィグレーションライブラリロード用）
と16/32bit CPU及び何らかの方法でのネットワーク接続方法。
結局はプロファイルとオプションのライブラリロードが居るんでSUNは160~500K程度のメモリ（揮発・不揮発問わず）を想定してるんだけど。
が仕様上の要求だけどねぇ。携帯電話はそれでもリソースケチるからな・・・。
>>496
いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
ホットスポットVMなら仕様上はCDC HIとCLDC Hotspotて感じのが一応ある。
CDC用はネフロのVMが実装してたな。
>>497
良いねそれ。eclipseのjavacで試してみよう。
まあ、MEも仕様上はEcmaScript並みに互換性あるけどベンダーの実装が変な事やってんだよね。
MS VMとネスケVMとSUN VMで互換性が無かった時代のように
（厳密にはMS VMがネスケVMとSUN VMに互換性なかったんだけど。ライブラリのサポートも屑だったし）
学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
501:497
07/02/24 22:46:46
>>500
IBMがつくったコンパイラは例えば
1. VisualAge for Java
2. j9c(後期型は4と同等) + jxelink
3. IBM JDKのjavac
4. Eclipse/JDT(ecj.jar)
5. jikes
が挙げられる。497でstaticメソッドの展開が...って言ったのは
1のjxelink。厳密にはポストプロセッサ。
>良いねそれ。eclipseのjavacで試してみよう。
これが4のことを言っているのなら、1のjxelinkとは別物だよ。
502:デフォルトの名無しさん
07/02/24 23:54:51
>>500
もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！
とハード屋に圧力をかけてさ。
マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。
今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。
「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ
503:デフォルトの名無しさん
07/02/24 23:58:12
>>500
> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。
> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。
ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。
504:デフォルトの名無しさん
07/02/25 00:04:27
>>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
505:デフォルトの名無しさん
07/02/25 00:42:46
国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。
まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）
ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・
SUNの苦労体質全部をJavaが担ってる気がするｗ
506:デフォルトの名無しさん
07/02/25 01:02:42
>>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。
現実問題として電力消費が激しいと言う問題があるそうだ。
しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。
つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
507:デフォルトの名無しさん
07/02/25 01:23:02
KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？
Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。
その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。
ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
508:デフォルトの名無しさん
07/02/25 01:38:36
つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。
509:デフォルトの名無しさん
07/02/25 06:56:24
今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。
510:デフォルトの名無しさん
07/02/25 07:12:43
て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か
511:デフォルトの名無しさん
07/02/25 10:59:44
Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。
512:デフォルトの名無しさん
07/02/25 12:55:29
>>509
燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。
携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。
513:デフォルトの名無しさん
07/02/25 13:37:18
>>510
CPUのクロックだけで比べても意味がないぞ
514:デフォルトの名無しさん
07/02/25 21:46:09
まあ、VMはハードウェアとＯＳを仮想化してるから下にパワーが無いとVMも非力になるな。
515:デフォルトの名無しさん
07/02/25 22:17:51
>>510
すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。
516:デフォルトの名無しさん
07/02/26 03:24:52
>>510
今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ
517:デフォルトの名無しさん
07/02/26 04:23:39
>>516
>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。
518:デフォルトの名無しさん
07/02/26 06:53:19
*7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。
それどころかボロクソに言われてた
昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。
519:デフォルトの名無しさん
07/02/26 08:18:20
Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。
新型レンダラまだー？
520:デフォルトの名無しさん
07/02/26 09:07:33
JOGLがあるよ。
521:デフォルトの名無しさん
07/02/26 10:50:29
3DはJOGLが1.0になったので使い物になった
ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし
あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい
JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ
522:デフォルトの名無しさん
07/02/26 16:20:42
JOGLのコア化ってありえるか？
あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？
どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。
523:デフォルトの名無しさん
07/02/26 16:59:41
>>516
> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ
多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。
Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。
その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。
524:デフォルトの名無しさん
07/02/26 17:06:04
>>517
Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。
いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。
それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、
アプリケーションはJavaでできている。
なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。
そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。
そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
525:デフォルトの名無しさん
07/02/26 17:21:02
>>523-524
マ板行け。
526:デフォルトの名無しさん
07/02/26 17:30:02
マ板ネタも含まれているかもしれないけどJava MEの将来に対する
要望も含まれているから、ここでもいいのではないかと
527:デフォルトの名無しさん
07/02/26 17:35:53
>>526
要望なら要望聞いてくれるところで言わんと意味無かろうが。
動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。
528:デフォルトの名無しさん
07/02/26 22:03:34
表題みるかぎりSE専門かと
529:デフォルトの名無しさん
07/02/26 23:23:01
技術的な話も含まれているがのう。
要望ねえ。JCPか？
530:デフォルトの名無しさん
07/02/26 23:26:20
>>529
含まれてないよ。マ板池。
531:デフォルトの名無しさん
07/02/26 23:29:54
>>530
営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。
532:デフォルトの名無しさん
07/02/27 03:14:34
むしろBREW上のJAVAで話を広げて欲しかった。
というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している
533:デフォルトの名無しさん
07/02/27 06:00:49
>>524
>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
＃何だよ、scratch padって。
#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？
534:デフォルトの名無しさん
07/02/27 07:00:15
>>532
phoneME Advancedのどこが不満なんだ！ｗ
Mysaifu JVMは俺も入れてるけど・・・。
だって～かんきょうなくてびるど出来なかったんだも～んｗｗ
まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。
てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。
もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・
ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？
535:デフォルトの名無しさん
07/02/27 07:09:12
>>533
M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。
536:デフォルトの名無しさん
07/02/27 12:07:15
>>532-535
キミら、次世代と関係ない話題は他所でやってくれんかね？
次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。
537:デフォルトの名無しさん
07/02/27 19:04:27
て言ってもSE7って情報少ないな
538:デフォルトの名無しさん
07/02/27 20:21:12
これがSDKに内包されてjavaguiが広まないかなぁ
URLﾘﾝｸ(journal.mycom.co.jp)
539:デフォルトの名無しさん
07/02/27 21:17:25
それSwing普通に使える人にとってメリットがほとんどないぞ
フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい
540:デフォルトの名無しさん
07/02/27 21:33:51
ポトペタツールが対応するか次第のよーな。
541:デフォルトの名無しさん
07/02/28 09:38:38
>>533
> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
プリ糞セッサに依存している時点で設計が全然駄目じゃん。
> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
Python載せられることのどこがいいの理解できない。
542:デフォルトの名無しさん
07/02/28 22:01:15
どこかで見たような・・
543:デフォルトの名無しさん
07/02/28 22:22:37
>>533
んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。
544:543
07/02/28 22:31:04
スレ違いの話だけだとあれなんでSEの話もふっとく。
URLﾘﾝｸ(techon.nikkeibp.co.jp)
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。
545:デフォルトの名無しさん
07/03/01 09:21:12
>>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。
>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。
インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。
546:デフォルトの名無しさん
07/03/01 10:02:45
>>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？
最低プロファイル・機種毎にソース分けんと確実に死ねる。
jadも分けんとたまにハマるから油断できん！
547:デフォルトの名無しさん
07/03/01 10:13:36
あー言い忘れたeclipseでリファクタリングしただけでエミュでは動いて実機では動かなくなるのがMEの世界だ。
システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。
実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない）
あと実機じゃ機嫌悪いと動くコードもマジで動かん。
MEでプリプロセッサ使ったソースなんて保守以前の問題。
548:デフォルトの名無しさん
07/03/01 10:58:01
>>545
>だからそれはJ2SEのような環境が統一されている場合の話であって、
>機種依存が激しい携帯ではなりたたないって。
>VMですら機能やバージョンが違うのに。
つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、
Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。
549:デフォルトの名無しさん
07/03/01 11:39:58
いやだからそういう次元じゃないとｒｙ
MEやれ
550:デフォルトの名無しさん
07/03/02 00:07:56
>>548
SEで、ifdefは勘弁して欲しい。
それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・
551:デフォルトの名無しさん
07/03/02 20:50:21
JDK7 build09
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
何だろう？2回続けてサマリがないビルドだ・・・
まあ今回もupdateするけど～
552:デフォルトの名無しさん
07/03/02 21:32:24
>>551
>>470 のリンク先見たら前回のは出てる。
ビルド方法でトラブってて changes が自動生成できてないから、
後から手動で生成してるとか？ それとも単に怠慢で遅れてるだけ？
553:デフォルトの名無しさん
07/03/03 07:27:48
フィールドのgenericTypeを取りたいんだが方法はある？
例：List<Integer> listのInteger
554:デフォルトの名無しさん
07/03/03 08:19:37
>>544
べつに無理にJava標準に含めることを早めなくても問題なかろ。
早めることよりもむしろ、理にかなってこそ導入すべきだが。
Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。
JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから
下手にほいほいと導入するわけにはいかんでしょうや。
そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。
OSGiはなぜかEclipse Communityががんばっているようだし。
Eclipseのプラグインフレームワークに導入されているが、
SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。
SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM
に不信感を抱いているのではないかな？
555:デフォルトの名無しさん
07/03/03 08:22:53
>>548
駄目だお前。
ソフトウェア工学をなめとる。
修行が足りんぞ。
556:デフォルトの名無しさん
07/03/03 08:24:07
>>553
get(i)
557:デフォルトの名無しさん
07/03/03 08:28:45
>>553
URLﾘﾝｸ(download.java.net)
558:デフォルトの名無しさん
07/03/03 08:50:51
>>557
$ cat Test.java
import java.util.List;
import java.util.ArrayList;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class Test {
public static void main(String[] args) {
ArrayList<Integer> l = new ArrayList<Integer>();
Type type = l.getClass().getGenericSuperclass();
ParameterizedType pt = (ParameterizedType)type;
for (Type t: pt.getActualTypeArguments()) {
System.out.println(t);
}
}
}
$ java Test
E
ありゃ。
559:デフォルトの名無しさん
07/03/03 09:02:20
class IntegerList extends ArrayList<Integer> {}
public class Test {
public static void main(String[] args) {
Type type = IntegerList.class.getGenericSuperclass();
for (Type t: ((ParameterizedType)type).getActualTypeArguments()) {
System.out.println(t);
}
}
}
とすると
class java.lang.Integer
となるな。
560:デフォルトの名無しさん
07/03/03 11:03:18
>>553
List<Integer> の Integer はコンパイル時に情報消えるよ。
>>559 みたいなのは特殊な例。
561:デフォルトの名無しさん
07/03/03 11:15:54
って、ローカル変数じゃなくてフィールドの宣言についてか。
public class test {
public List<Integer> sample;
public static void main(String[] args) throws Exception {
for (Type t: ((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments()) {
System.out.println(t);
}
}
}
>java test
class java.lang.Integer
562:デフォルトの名無しさん
07/03/03 11:21:52
>>558はgetClassしてる時点でどうなるかをかんがえればよろし
563:デフォルトの名無しさん
07/03/03 14:24:41
>>553
初心者質問スレ行けよ。
564:デフォルトの名無しさん
07/03/03 15:28:47
>>556-563
㌧
565:デフォルトの名無しさん
07/03/04 09:29:05
>>551
追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。
デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな
566:デフォルトの名無しさん
07/03/05 16:02:11
invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？
567:デフォルトの名無しさん
07/03/05 16:44:34
>>566
実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？
そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？
568:デフォルトの名無しさん
07/03/11 15:34:36
某スレの 288 へレス。
> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。
URLﾘﾝｸ(blogs.sun.com)
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスで それ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスする とかだけど、これはこれでキモイから嫌なんだそうで。
URLﾘﾝｸ(weblogs.java.net)
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。
569:デフォルトの名無しさん
07/03/11 17:20:57
>>568
そうか、キモイか・・・うん、キモイなぁ
dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ
俺は、個人的な好みは->はキモイけど、 : ならOKです。
570:デフォルトの名無しさん
07/03/11 17:41:54
::
.
.*
->
->*
いろんな言語のaccessor。あと何があったっけ？
571:デフォルトの名無しさん
07/03/11 17:48:11
>>569
オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。
URLﾘﾝｸ(jroller.com)
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。
572:デフォルトの名無しさん
07/03/11 18:14:36
>>569
:: じゃなくて : なの？
class A { property Object b; }
class B { property Object c; }
class Hoge {
A a; B b; Object c;
boolean flag;
Object method(){
return flag ? a : b : c;
}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。
573:デフォルトの名無しさん
07/03/11 18:15:17
dot人気ないね。
フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？
574:デフォルトの名無しさん
07/03/11 18:42:44
>>573
皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。
>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。
C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？
575:デフォルトの名無しさん
07/03/11 22:38:47
>>572
あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。
>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。
-> は、演算記号と紛らわしくて、嫌。
576:デフォルトの名無しさん
07/03/11 23:03:00
プロパティなんてそもそも本質的には冗長な機能なんだから、
どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
577:デフォルトの名無しさん
07/03/11 23:08:52
> マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
具体的には？
578:デフォルトの名無しさん
07/03/12 03:22:06
C++で->使ってるから、->でいいや。
579:デフォルトの名無しさん
07/03/12 04:10:14
>>576
VBだとdotじゃなかったっけ？
580:デフォルトの名無しさん
07/03/12 08:32:28
>>577,579
VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。
581:デフォルトの名無しさん
07/03/12 08:50:48
>>580
C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。
なんでこんな簡単な事が理解できないのかわかんない。
582:デフォルトの名無しさん
07/03/12 08:55:00
>>581
プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ
583:デフォルトの名無しさん
07/03/12 09:19:05
>>582
> プロパティ自体後付けじゃん…て思ったんだけど、
JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。
だから、完全に後付けってわけでもない。
JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。
あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。
例えば、
class MyComponent implements java.beans.DesignMode {
private boolean designTime;
public boolean isDesignTime(){ return designTime; }
public void setDesignTime(boolean f){ designTime = f; }
}
みたいな既存のコードがあるとする。
プロパティが追加されて java.beans.DesignMode が
interface DesignMode {
public static final String PROPERTYNAME = "designTime";
public abstract property designTime;
}
みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。