Java低速GUI Swing 10

1 ：デフォルトの名無しさん：2011/09/20(火) 23:23:15.82 .net

ハードウェアの高スペック化、描画アルゴリズムの変更、JavaVMの高速化に伴い、パフォーマンスの問題は改善されています。
しかしながら、"Java"というだけで未だに敬遠されるのが現状。
そんなSwingと引き続き付き合っていくみんなのスレッドです。

Java低速GUI Swing 9
http://hibari.2ch.net/test/read.cgi/tech/1261232019/
Java低速GUI Swing 8
http://pc12.2ch.net/test/read.cgi/tech/1227234261/
Java低速GUI Swing 7
http://pc11.2ch.net/test/read.cgi/tech/1204155623/
Java低速GUI Swing 6
http://pc11.2ch.net/test/read.cgi/tech/1190807478/
Java低速GUI Swing 5
http://pc11.2ch.net/test/read.cgi/tech/1161139809/
Java低速GUI Swing 4
http://pc8.2ch.net/test/read.cgi/tech/1140533866/
Java低速GUI Swing 3
http://pc8.2ch.net/test/read.cgi/tech/1121700954/
Java低速GUI Swing 2
http://pc8.2ch.net/test/read.cgi/tech/1095398949/
Java低速GUI Swing
http://pc5.2ch.net/test/read.cgi/tech/1062271447/l50

440 ：デフォルトの名無しさん：2018/07/06(金) 12:38:27.29 ID:uTPDH9XV.net

JD7SU

441 ：デフォルトの名無しさん：2018/08/07(火) 22:54:59.59 ID:Mbqc13Y2.net

JavaFXが死んでこっちは盛り上がっているかと思ったが、そうでもないんだな。

442 ：デフォルトの名無しさん：2018/11/17(土) 11:41:05.83 ID:LJA6Qb6G.net

向こうのスレから転載

An Oracle White Paper March 2018
Java Client Roadmap Update
https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf


Swing and AWT
AWT has been an integral part of Java SE since its launch in 1996.
Swing was introduced shortly thereafter as a separate library and finally incorporated into “J2SE 1.2” in 1998. Both toolkits are still part of the Java SE Specification and core to many other toolkits and applications that build on top of them.
Oracle will continue developing Swing and AWT in Java SE 8 and Java SE 11 (18.9 LTS). This means they will be supported by Oracle through at least 2026.

443 ：デフォルトの名無しさん：2018/11/21(水) 18:59:51.94 ID:b35PMmU2.net

> This means they will be supported by Oracle through at least 2026.
オラクルがこういう言い方するときは要するにまだ何も決まってないってことだぞ。
未来のことに触れてると見せかけて現状を説明しただけっていういつものやつ。

444 ：デフォルトの名無しさん：2021/01/05(火) 04:06:24.80 ID:UotbUhIg.net

ほしゆ(・ω・)

445 ：デフォルトの名無しさん：2021/01/20(水) 19:27:35.65 ID:MNAZOc7q.net

GNU LGPL3で立ち上げたいけど、
Javaのオープンソースでもいける？

一応GNUにメールはしてる

446 ：デフォルトの名無しさん：2021/01/20(水) 19:31:29.29 ID:RjL3wS6+.net

あ、URL必要かな

447 ：デフォルトの名無しさん：2021/01/20(水) 19:38:59.15 ID:RjL3wS6+.net

大丈夫だろうか、あまりGNUライセンスにする傾向じゃないプログラムで、
ただ、他に向いてそうなライセンスが見当たらないんですよね。

メールはしたから返事まちかな、、

OSDN > ソフトウェアを探す > マルチメディア > サウンド/オーディオ > ミキサ > Extended MIDI Mixer

Yahoo知恵袋の宣伝目的NGに該当するので、こちらで伺います。
Swingなのでこのスレを見てました。

ビクビクしてますが、、

448 ：デフォルトの名無しさん：2021/01/20(水) 20:11:53.92 ID:c8t2FVIz.net

あ、メールは必須じゃないのか、、

何か間違えた

449 ：デフォルトの名無しさん：2021/01/21(木) 13:27:13.82 ID:jRLswf9/.net

MidiDevice用のINはスレッドをAPIが立ち上げてるのか
一応対処しました。

ひょっとしてOUTも？

あとOutputのバッファオーバーを知るAPIがないから
それは勘弁な

0.93リリースです。

450 ：デフォルトの名無しさん：2022/08/05(金) 08:04:11.70 ID:i6vOLsi1.net

予想通り過疎ってるwww
独り言落としてくね！

Win版OpenJDK使用のアプリで、タッチパネルピンチ操作イベントをマウスホイールイベントとして拾えないバグ、報告されたの5年前なのにずっと放置w

もう本家もやる気ないんだろな。
FXですらMac版のスレッド実装問題でdndで落ちるバグ放置されてるし。
仕方ないので、前者はJNA使ってイベント拾う実装を書いてる。
ピンチ検出までできたからもう少しでインかアウトの判定に辿り着けそう。

というわけで未だにswingでマルチプラットフォームアプリ書いてるわけだけど、
WindowsのUWPはオワコンになったし、
なんだかんだで業務用アプリ書くには悪くない環境ですよswing は。
動作もjavascript頼みのマルチプラットフォームフレームワークより軽いと思う。

では、数年後スレが残ってたらまた来ます。

451 ：デフォルトの名無しさん：2022/08/06(土) 21:42:05.07 ID:wJirtnJ7.net

>>450
＞なんだかんだで業務用アプリ書くには悪くない環境ですよswing は。

これは大収穫のお言葉、詳しく教えてください！！

452 ：デフォルトの名無しさん：2022/08/09(火) 00:04:39.25 ID:bKJRywmG.net

俺もswing好きだわ。

453 ：デフォルトの名無しさん：2022/08/09(火) 00:18:40.76 ID:KAEQzIc+.net

じゃあ俺も

454 ：デフォルトの名無しさん：2022/08/09(火) 06:39:20.83 ID:/QsLf7Eg.net

俺も俺も

455 ：デフォルトの名無しさん：2022/08/10(水) 18:32:47.04 ID:8wl1vZ8Q.net

プログラミングモデルは好きだけど
look & feel は不完全な模倣になってて
ネイティブのラッパーの方が
実用的だなと思った

456 ：デフォルトの名無しさん：2022/08/10(水) 22:13:11.96 ID:gf2K0ZCl.net

わしも！
非同期処理の実装しやすいし
androidとかフレームワークによってはダイアログ表示と結果取得が非同期だったりするしw

457 ：デフォルトの名無しさん：2022/08/12(金) 11:53:04.45 ID:0e2Dltzu.net

Swingは設計が綺麗だなと思った。

458 ：デフォルトの名無しさん：2022/09/17(土) 15:06:22.57 ID:5gb6FxEB.net

swingアプリにJFXPanelのwebkitブラウザ実装したUIキメラ作ったったw
これでjsベースのエディタとかビューのモダンなUIフレームワーク使える

ブラウザ内のjsエンジンから発生したイベント拾ってJava側でハンドルする
ただswingとjfxのスレッドが別だから
初期化時の同期と相互にinvokeLater()使うことに注意必要だけど

459 ：デフォルトの名無しさん：2023/07/11(火) 07:46:05.23 ID:hZK5sFkA.net

男は黙ってJEditorPane

サシャナゴンの方が好きだ

460 ：451：2023/09/24(日) 22:24:00.15 ID:jzYiScHF.net

>>450

本業の合間にやってたから今頃なったけど、Windowsでピンチ操作拾えないバグの回避実装に成功した～
JNAでWin32のローカルメッセージハンドラフックしてピンチイベント検出できた
VC++の構造体の内部資料が無くて
色々なソースから類推するのが大変だったけど勉強になった

461 ：451：2023/09/24(日) 22:34:50.62 ID:jzYiScHF.net

>>451
亀レスすまん

流行りのWebのvue.jsとかreactとかより
設計がシンプルだからデバッグしやすいなど実装が楽ってだけ
業務用はuiのカッコ良さより安早楽が大事でしょ？
あとビジネスロジックにおいてJavaは高機能ライブラリが豊富なのも有難い
MSの.NETほどにフレームワーク設計しくじってぐちゃぐちゃになってないし

逆に今どきのおしゃれインターフェースにしたいならjs系がいい

462 ：デフォルトの名無しさん：2023/09/27(水) 23:34:40.13 ID:Kbex28u5.net

そういやスレタイでswingを低速言うてるけど
JavaFXのほうが初期化しめちゃめちゃ時間かかってもっさりしてるんだけど…
そしてmacでは未だにスレッド競合解決してない
swnigよりオワコンな気がする

463 ：デフォルトの名無しさん：2023/09/28(木) 21:16:38.66 ID:x1hSo4u3.net

真実を愛せ。ただし過ちは許せ

464 ：デフォルトの名無しさん：2023/12/28(木) 23:54:02.59 ID:eFg1sCcO.net

スタンドアロンアプリ自体が絶滅しようとしているんだ…
クラウドが大規模障害起こして復旧目処立たなくなったとき
人々はjavaアプリの偉大さを噛みしめることであろう

swingは死なず、ただ去りゆくのみ

465 ：デフォルトの名無しさん：2023/12/29(金) 17:52:36.41 ID:rzQLK+Os.net

JavaでGUIするぐらいならウインドウにHTMLでええやん…

466 ：デフォルトの名無しさん：2023/12/29(金) 22:00:11.69 ID:JQn1FaNw.net

まあハードウェアアクセラレートあってもHTML/jsのUIがもっさりしてるのみんな慣れてきたしね

467 ：デフォルトの名無しさん：2023/12/30(土) 00:25:28.91 ID:9n1xxmBk.net

GUI表現としてHTML/CSSは十分なんだけどロジックをJavaScriptで書くのはつらい

468 ：デフォルトの名無しさん：2023/12/30(土) 00:55:38.23 ID:CvaIx2Pu.net

ビジネスロジックは鯖側のnode.jsで書けるしスタンドアロン系も同じnode.jsで動くフレームワークあるよ
ただマルチスレッドじゃないから似非非同期による安定実装めんどくさい

469 ：デフォルトの名無しさん：2023/12/30(土) 08:42:45.57 ID:9n1xxmBk.net

サーバー側のnode.jsだってJavaScriptじゃん
それに昔と違ってビジネスロジックはサーバーサイドが担当するって考え方も今は通用しない
SPAが流行しててクライント側で動かさなければならないロジック（JavaScript）が昔より増えてるのだ

470 ：デフォルトの名無しさん：2023/12/30(土) 09:17:16.16 ID:CvaIx2Pu.net

ビジネスロジックとUIロジック整理しないで実装してるから開発管理破綻してるのでは？

フロント/バックエンド部隊の連携、運用保守まで考慮した設計できないならSPAは採用すべきでないと思うけどなぁ
俺のvue.jsとlambdaの開発リーダー経験からの話だけど
next.jsあたりはもっと進歩してスッキリしてんのかと思ったが違うの？

471 ：デフォルトの名無しさん：2023/12/30(土) 12:30:59.06 ID:9n1xxmBk.net

ビジネスロジックをサーバー側に閉じ込めようとすると
SPAではクライント／サーバー間の通信回数が増えてレスポンスが低下したりするのよ
だからクライントでビジネスロジックを動かすようになってきてる

472 ：デフォルトの名無しさん：2023/12/30(土) 13:40:32.71 ID:CvaIx2Pu.net

そうなのか、そんなファットになると
遅延読み込み使ってもロード&jsコンパイルのせいでキャッシュ前は凄く重そうだ

そんならアプレットやActiveX時代のほうがよほど合理的だよねw
4年くらい前は鯖と無駄な通信しないように同期対象データを複数のグループにまとめてパフォーマンスと操作性のバランス保ってたけど
いまだにフレームワークで鯖と自動差分同期も出ないんだ…

というわけで、アプレットはダメでもswingアプリ復活の方向でめでたしめでたしw

473 ：デフォルトの名無しさん：2023/12/30(土) 16:51:42.98 ID:4WPbBasM.net

Ruby on Rails 7 からは、Hotwire に変わった。
HotwireはHTML Over The Wireの略で、
SPAの開発において、JavaScriptのコーディングを極力必要としない。
脱node.js, webpack

JSONではなく、HTMLベース。
サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信する

https://techblog.gmo-ap.jp/2022/07/05/rails-7-hotwire/

https://zenn.dev/shita1112/books/cat-hotwire-turbo/viewer/abstract

474 ：デフォルトの名無しさん：2023/12/31(日) 11:53:05.54 ID:bYYQOTA1.net

SSRていうやつけ？
Rails嫌いではないがすっかりオワコンイメージだなあ

いやほんとにファットなアプリケーションをHTML/JSで実装しようというアプローチ自体が間違ってたんだなぁとしか思えない
そんならアプレットやバイナリ配信してキャッシュさせるアプローチに戻したほうがいい

475 ：474：2023/12/31(日) 22:47:52.24 ID:zAD+40EH.net

Rails 7 のHotwire, Elixir のPhoenix もLiveView で、
websocket によるリアルタイム通信に変わった。
これはHTTP2 で通信速度が速くなったから

ここ数年、SPA でReact に奪われたシェアを回復すべき戦略。
JSON を送って、ブラウザ側で組み立てなくても良い

476 ：デフォルトの名無しさん：2024/01/02(火) 22:10:02.99 ID:dQstW7+J.net

Webフロントエンドは成熟しないねー
次々と新しい技術が登場してきて大変
いま最新技術を選択しても数年後には「まだそんなの使ってるの？」と言われちゃう

477 ：デフォルトの名無しさん：2024/01/06(土) 09:08:07.68 ID:vtQPKo7U.net

日本の客も開発者も要件整理苦手だから泥縄で作るじゃない？
そういうやり方の場合SPAは実装ぐちゃぐちゃで使い勝手も悪くメンテも困難になる

レガシーなページ遷移あったほうが自然とトランザクション整理されるからお似合いと思うけど

478 ：デフォルトの名無しさん：2024/01/06(土) 09:10:41.02 ID:vtQPKo7U.net

そういう意味ではswingとかスマホでスタンドアロンアプリ作るのも日本人向きじゃないと思う

479 ：474：2024/01/08(月) 21:38:29.96 ID:gJaMg8aw.net

>>477
>レガシーなページ遷移

Ruby on Rails では、turbolinks を使って、pjax になる

ajaxとhistoryAPI(popState, pushState)を利用して画面遷移する。
js, cssの読み込みを初回時に行い、次回以降の読み込み処理を省略することで高速化する

480 ：デフォルトの名無しさん：2024/04/19(金) 02:33:22.05 ID:uD5nyH4z.net

いまではPCのスペックが上がって、遅くもなんともない。

481 ：デフォルトの名無しさん：2024/04/21(日) 20:30:12.98 ID:MS9R2kFy.net

JAVA SWING のボタンはお洒落だからカワイイから
JAVA SWING はボタンはカワイイくてお洒落だ
https://o.5ch.net/23128.png

482 ：デフォルトの名無しさん：2024/04/22(月) 21:44:32.97 ID:Xbe0J1w7.net

swingアプリメンテしてて困るのは
最近は横4000ドット近くあるノートPCで
アイコンやフォントが小さすぎる問題

古いフレームワークだからそういうの想定したスケーリング機能がない

結局自分でcontainer内のフォントサイズを再帰的に設定するメソッドとか作ったが
何十個もあるダイアログ全部まで手が回ってない…

逆に>>480 の言うように、スピードは全く問題なくなったね

483 ：デフォルトの名無しさん：2024/04/22(月) 21:46:56.69 ID:Xbe0J1w7.net

>>481
かわいいっていうか
ちっさすぎて見えなくなったよ

484 ：デフォルトの名無しさん：2024/04/23(火) 01:08:28.22 ID:VsJUMcwZ.net

SwingってHiDPI対応してないの？
Swing で作られてるらしいIntelliJ IDEAはHiDPI対応してるっぽいけど？

485 ：デフォルトの名無しさん：2024/04/23(火) 08:28:06.05 ID:P83a14ex.net

>>484
標準のL&Fは対応してないよ
対応しているように見える実装は独自L&F実装してる
OS側の強制拡大スケーリングはうまくいかないこと多いし
やはり時代遅れ

486 ：デフォルトの名無しさん：2024/04/23(火) 09:50:21.78 ID:83Qb5OUf.net

そうなのか
ちなみにJavaFXはHiDPIに対応してた

487 ：デフォルトの名無しさん：2024/04/23(火) 23:01:45.01 ID:kXp8u5Dt.net

>>482
そんな高解像度のまま使っているのがおかしい

488 ：デフォルトの名無しさん：2024/04/24(水) 13:19:52.73 ID:21UOMqIs.net

jfxはmacOSで致命的ハングするから
代替にならないんだよなぁ

489 ：デフォルトの名無しさん：2024/04/25(木) 20:14:42.51 ID:WdrJmqqJ.net

ところでJavaFXにあるような
カレンダーによるdatechooserいいの無い？
名前忘れたけど有名どころのやつは
HiDPI対応してないうえにフォント拡大も
パネルサイズ変更も対応してないので
つかえないんですよ