【Java SE 7】 次世代Javaの動向 ７ 【dolphin】

genericsよりお前らのいってることが分からない
みんな端折りすぎなんだよ

>>951
お前のコスト安はどこからだよ！
俺、明日からキャスト沢山振りかけて食べることにするわ

閑話休題。

ごめん、JAMってどうなった？JSR-277は破綻したんだよな？
.jamアーカイブそのものが無くなったの？

jsr277は死亡、jsr294だけJava7に入る

JSR294だけでどうやってクラスパスの衝突を避けるの？
JAM（というかMODULE-INFディレクトリ）はJSR277の仕様でしょ？
結局の所、最新のjarを落としてきて後方互換性を盲信するのと何が違うんだろ。

jsr277がjsr294に取り込まれたんじゃないの？

>>951
知らないの？VM上ではキャストはコスト高いよ。
特にループ内部にキャストのコードを入れるときは無駄が多くなる。

IBMとapacheがOSGiに流れてる状況で、JSR277が出てきてもまとまらないよなあ。

ヒント：IBM=apache

どうでもいい言語機能よりさっさと native2ascii を捨てろよ。
UTF-8 を標準にしときゃ native2ascii かけた既存のプロパティファイルと互換保てるだろ。

XMLプロパティか

てかさ、Propertiesクラスそのものを非推奨にしようよ。
あれ何でHashMapベースなの？Mapをコンポジットしろよ。
出力した時は普通LinkedHashMapかSortedMapの動作を期待するだろ。

Propertiesはextends Hashtableだが。

ほぼどうでもいい重箱の隅だと思うのだが。

どうでもいいネタにふさわしいツッコミだと思うのだが。

スレ汚ししたいなら他所でどうぞ。

他所いけってさ>>961

SEIのXMLを利用できるAPIを総点検中なんだが、
XMLEncoder/Decoderがひっそりと enum に対応してた。
どっかにアナウンスがあったっけ？

jdk7 build54
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b54.html

awt関連のバグ取り。

大規模なシステムほどJAVAで組まれてると言われるけど、
実際はけっこーCも多いよね。
結局大量の処理をする場合Cの速度が優位になっていく。
事実Cで組まれたシステムが第一線で使われてるケースもかなり多い訳で。
JAVAがそれに対抗しろとは言わないが、汎用性ではJAVA・・でもやっぱシステム組んでもらえるならCがいいという構図は
なかなか変わりそうにないなぁと思った

ベンチマークだと、速度はともかくメモリ消費量は１桁違うみたいだね
ttp://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=gcc&box=1

そりゃぁ、年金から年間８００億円も融通してもらえるような超巨大企業なら
工数度外視でＣで開発したりできるだろね。
とにかくガバガバ金つかえ、納期気にすんな、人月？なにソレ？って漢字で
何年も何年もダラダラダラダラと、去年８００億円、ことし８００億円、来年も８００億円・・・
年金という金のなる木が枯れるまで、骨の髄までしゃぶり尽くすんだろ。
民営化とは名ばかりで、金の流れ道が少し変わっただけ。政府とズブズブやんけ。

大規模が処理量の大規模ならCなんだろうけど
機能数の大規模や開発者数の大規模の場合に
Cを選ぶとプロジェクトが遅延しまくるんじゃまいか

大規模で膨大なトランザクション抱えている所はどこも I/O がネックになってるから
C と Java 程度の速度差なんてたいした話ではないな。インフラならともかく、金融系の
膨大かつ毎年改訂の入るような業務ロジックを C で組むなんてアホも良いとこ。
大体、速度を求めるなら普通は開発リスクのないハードの増強に投資する。

トランザクション量で金融は大規模ではない
ネット証券大手でもTwitterやブログとは何桁も少ない
もちろん信頼性の要求も桁が違うがそもそも金融程度の
トランザクション量ならCを選ぶ必要はない
例外は証券取引所くらいか

トランザクションと HTTP リクエストの区別の付いていない方が居られるようだが…

976は当然トランザクションのことを書いている
それが分からないのは視野が狭いのではないか

元の話(>>971)ではトランザクションの話なんてしてないし
実際Cで書く意味があるかどうかはトランザクションより
HTTPリクエストの量だろうがな

おまいら C に幻想持ちすぎ。

それLinusに言ってみたら？

COBOL化まっしぐら

WEBアプリ以外はアプリに非ず、って風潮？

どこが？

>>979
元の話(>>971)ではトランザクションの話もＨＴＴＰの話もしてないし。
ただ「大規模なシステム」としか書いてない。
何の前提も無いときはＨＴＴＰの話がデフォルトというわけなのか。

>>976
DB/ホストへのアクセス量が全然違う。ブログと同じ程度のシステムしか組んだ事ないのかよ。

C言語と相性の悪い言語って基本的には無いと思う。
処理性能とフットプリントの小ささに信頼のある言語は他に見あたらない。
処理性能だけならいくつかのベンチマークではGNU CよりJavaのが速いから、
これはもう言語というよりコンパイラ屋をどれだけ囲ってるかの差だな。

Javaのメモリ周りの最適化はやりつくした感じ（スタック割り当てとか）だけど、
Cのほうは、JITの導入が始まってきた（LLVMとか）ところだからなあ。

>>985
>>979は>>977を見て書いたからHTTPが出てる
トランザクションは>>974-975の流れだな

>>986
君は金融しか経験がないようだな
いくらハイエンドのサーバでもOracle(RACも含む)なんかで集中型の
DBMSで運用できているという事実が金融はトランザクション量が
たいしたことないという事実を語っている
大規模ってのは君が考えてるより二桁三桁多いトランザクションをさばいてるよ

>>990
いや、単におまいがオープン系の世界しか知らんだけだと思う。

>>991
大手ネット証券やってますが何か？

ちょｗ
基幹系が Oracle で運用できてるってどこのサラ金の事だよｗ

バックはメインフレームだけどフロントのDBMSはOracleよ
ネット専業に限らず証券はだいたいそんなもん

>>992
でかいところだと赤と緑の某都銀にもっと巨大な某生保、損保最大手、某FRB生命なんかで
やってましたが何か (何をかまでは特定されるので言わない)。先日民営化されたバケモノは
何とか足抜けられたが。
というか、どう見てもトランザクション≒HTTPアクセスという認識で語ってるようにしか
見えないわけだが… 今時のブログは PHP を TP モニターで監視でもしてんの?

やっぱり金融バカかw

おまえ、やっぱりフロント側の、しかも Web 周りしか開発したことのないだろ。
トランザクションの話でブログ引き合いに出してるような時点で知れてんだよ。

2

証券バックもやったし銀行も少しだけやったよ
つか、後ろの方がトランザクション量的にはずっと少ないじゃん
バッチやディレイドオンラインのデータ量は多いけど効率いいから負荷少ないよね
保険はやったことないからどんな感じか興味あるけど次スレに持ち越して欲しくはないw

1000ならJava7年内リリース

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。