Java低速GUI Swing 10

**デフォルトの名無しさん** · 2011/09/20(火) 23:23:15.82

ハードウェアの高スペック化、描画アルゴリズムの変更、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

**デフォルトの名無しさん** · 2022/09/17(土) 15:06:22.57

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

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

**デフォルトの名無しさん** · 2023/07/11(火) 07:46:05.23

男は黙ってJEditorPane

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

**451** · 2023/09/24(日) 22:24:00.15

>>451

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

**451** · 2023/09/24(日) 22:34:50.62

>>452
亀レスすまん

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

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

**デフォルトの名無しさん** · 2023/09/27(水) 23:34:40.13

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

**デフォルトの名無しさん** · 2023/09/28(木) 21:16:38.66

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

**デフォルトの名無しさん** · 2023/12/28(木) 23:54:02.59

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

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

**デフォルトの名無しさん** · 2023/12/29(金) 17:52:36.41

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

**デフォルトの名無しさん** · 2023/12/29(金) 22:00:11.69

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

**デフォルトの名無しさん** · 2023/12/30(土) 00:25:28.91

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

**デフォルトの名無しさん** · 2023/12/30(土) 00:55:38.23

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

**デフォルトの名無しさん** · 2023/12/30(土) 08:42:45.57

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

**デフォルトの名無しさん** · 2023/12/30(土) 09:17:16.16

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

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

**デフォルトの名無しさん** · 2023/12/30(土) 12:30:59.06

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

**デフォルトの名無しさん** · 2023/12/30(土) 13:40:32.71

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

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

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

**デフォルトの名無しさん** · 2023/12/30(土) 16:51:42.98

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

**デフォルトの名無しさん** · 2023/12/31(日) 11:53:05.54

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

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

**474** · 2023/12/31(日) 22:47:52.24

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

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

**デフォルトの名無しさん** · 2024/01/02(火) 22:10:02.99

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

**デフォルトの名無しさん** · 2024/01/06(土) 09:08:07.68

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

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

**デフォルトの名無しさん** · 2024/01/06(土) 09:10:41.02

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

**474** · 2024/01/08(月) 21:38:29.96

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

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

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

**デフォルトの名無しさん** · 2024/04/19(金) 02:33:22.05

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

**デフォルトの名無しさん** · 2024/04/21(日) 20:30:12.98

JAVA SWING のボタンはお洒落だからカワイイから
JAVA SWING はボタンはカワイイくてお洒落だ

**デフォルトの名無しさん** · 2024/04/22(月) 21:44:32.97

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

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

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

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

**デフォルトの名無しさん** · 2024/04/22(月) 21:46:56.69

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

**デフォルトの名無しさん** · 2024/04/23(火) 01:08:28.22

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

**デフォルトの名無しさん** · 2024/04/23(火) 08:28:06.05

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

**デフォルトの名無しさん** · 2024/04/23(火) 09:50:21.78

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

**デフォルトの名無しさん** · 2024/04/23(火) 23:01:45.01

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

**デフォルトの名無しさん** · 2024/04/24(水) 13:19:52.73

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

**デフォルトの名無しさん** · 2024/04/25(木) 20:14:42.51

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

**デフォルトの名無しさん** · 2025/06/13(金) 01:24:45.47

2024年は1月と4月しか書き込みがない
とはいえここ>>444>>445で丸2年あいてんだよな
どれだけ空いたとかは関係ないということだ

**デフォルトの名無しさん** · 2025/08/18(月) 21:35:36.19

java9からHiDPI対応してシステムDPI見て勝手にスケールするよ