News for hackers. Stuff that matters.
Re:Graphics for JVM by dimitar on Tuesday November 17, 2020 @06:53AM (#25122675)
There are lots of fast, usable JVM gui applications.

Some OSS examples:

http://www.sweethome3d.com - This one has been the one app I've recommended to people outside the tech bubble! It also focuses on graphics and 3d.. really deserves to be showed off more often

http://xmind.net

https://dbeaver.com/

http://www.mucommander.com/

http://www.jedit.org

What they have in common is that they are old project - often more than 10 years old and are not on Github. Goes to show how important hype and trendiness is in our industry.

edit: fixed formatting

Re:Graphics for JVM by bballer on Tuesday November 17, 2020 @08:14AM (#25123345)
The JetBrains suite (ie IntelliJ, Datagrip etc) while not open source, are a testament to what can be done with JVM based GUI applications.

Have you ever used the merge tools? So dang cool.

Re:Graphics for JVM by ubercow13 on Tuesday November 17, 2020 @09:42AM (#25124218)
IDEA still has a horrible GUI in my opinion. All sorts of weird subtle bugs relating to the very fundamental UI interactions that make the whole experience very frustrating. The main one I remember is that certain buttons in the UI are simply unreliable - depending on what processing is going on (sometimes if nothing heavy is being processed), certain buttons in the UI will not respond when clicked. I used IDEA for years and very often had to click a button 4-5 times until it would activate, especially while using the debugger.

If the UI toolkit can't get a button right, it is completely broken IMO. Even including intelliJ products, I have never used a Java GUI which was good.

Re:Graphics for JVM by chinhodado on Tuesday November 17, 2020 @10:11AM (#25124580)
I've never experienced anything like that in IntelliJ, and I've used it everyday for years now. Granted there are bugs especially around big releases, but I've never seen any UI bug like you described. Everything is always smooth and responsive.
Re:Graphics for JVM by ubercow13 on Tuesday November 17, 2020 @11:06AM (#25125337)
I just fired it up to see and it's still kind of there. For example when loading a project, there's a popup progress bar and the UI kind of janks around while it's loading. If you click anything in the UI while that's happening like a menu, the event is lost.

OK - it's loading so that's not unexpected. However my previous experience was that the same thing would happen to the UI at all sorts of surprising moments when other processes were ongoing, such as linting or using the debugger. Kind of hard to reproduce without a large project at hand though.

Then I had to stop testing and SIGKILL it because the whole application got into an infinite loop of NPEs in the UI event loop of all places!

I too experienced using intelliJ for many years and this seems largely in line with what I remember.

Re:Graphics for JVM by twic on Tuesday November 17, 2020 @02:31PM (#25128494)
The stop/run button in the Run pane often doesn't work for me - i mouse over, it doesn't highlight, and clicking it does nothing. Minimise and maximise the pane, and it works fine.
Re:Graphics for JVM by whizzter on Tuesday November 17, 2020 @10:05AM (#25124511)
Sounds more like an IDEA bug rather than a Swing bug. I've implemented an editing tool (realtime video generation parameter editing w/ feedback from the generator) that really has a lot of issues.

Part of them because i didn't fully understand Swing when i began the project and partly because synchronizing GUI's to another live process is a quite error prone task.

A debugger process is almost certainly not living in the same thread as the Swing UI of IDEA so this almost surely more of a thread synchroniztion issue rather than Swing issue. (You really don't watch to do any cross-thread touching with Swing apart from for a very limited set of components built for this).

Re:Graphics for JVM by ubercow13 on Tuesday November 17, 2020 @10:28AM (#25124850)
Yes it's certainly something to do with threads. Still the way it manifests is weird. For example sometimes in apps like Chrome or Firefox the tab bar will freeze momentarily while the UI is hung waiting for something, however if you click something like a tab close button during this period your click will be processed once the UI un-hangs.

In intelliJ it was like whenever the UI was not immediately responding to mouse events, it would often just lose the event instead of it being correctly processed once the UI thread was freed up.

Re:Graphics for JVM by whizzter on Tuesday November 17, 2020 @01:31PM (#25127601)
Chrome/FF in this case has an UI thread that becomes unresponsive for whatever reason and doesn't empty it's message-queue (that contains the mouse/keyboard/etc events).

In the case of IntelliJ there is probably some of their code accepting the event and then probably has some ad-hoc message passing by setting a field that is polled by the receiver thread under the assumption that the receiver always runs faster than a human can act, however as soon as that assumption is broken by some pause you get what you describe.

Re:Graphics for JVM by orybak on Tuesday November 17, 2020 @09:07AM (#25123851)
IDEA Community edition is opensource: https://github.com/JetBrains/intellij-community
Re:Graphics for JVM by fnord123 on Tuesday November 17, 2020 @08:38AM (#25123559)
Skija (the graphics library in TFA) is in the JetBrains organiation... https://github.com/JetBrains/skija/
Re:Graphics for JVM by anentropic on Tuesday November 17, 2020 @08:25AM (#25123442)
The JetBrains merge tools are the best ones I've found!

I have it configured as my git mergetool

The only problem is it takes absolutely ages to start up, which is maybe a JVM thing

I wish there was a way to have git pass all of the conflicting files in a merge to the mergetool at once. Instead of having to wait for JetBrains to load up for each individual file and close after each one :(

Re:Graphics for JVM by thu2111 on Tuesday November 17, 2020 @10:52AM (#25125153)
JVM apps can start in <100 msec, and IDEA has a 'lite' mode now where it's more like a text editor. That starts very fast.

IDEA is slow(ish) to start because it's an IDE so it's loading tons of plugins, a project database etc. Though actually recent versions only take a few seconds on my admittedly high end MacBook.

Re:Graphics for JVM by CountHackulus on Tuesday November 17, 2020 @01:10PM (#25127278)
There's also some AOT options for the JVM to get a faster startup, along with -Xquickstart. I definitely agree with the "you're loading an entire IDE" statement.
Re:Graphics for JVM by anentropic on Tuesday November 17, 2020 @11:59AM (#25126090)
I wish I could launch just the diff interface without all those plugins then

TBH I never got on with PyCharm and still use Sublime Text... but I keep PyCharm installed just for the mergetool!

Re:Graphics for JVM by thu2111 on Monday November 23, 2020 @05:27AM (#25185317)
That's what lite mode is. Check it out!
Re:Graphics for JVM by funcDropShadow on Tuesday November 17, 2020 @03:22PM (#25129252)
I do it the other way around, I let git write the default conflicting files. And then switch to IntelliJ, press Ctrl-a and type "resolve", press enter. And voila I am in IntelliJ's git resolution windows where each conflicting file is listed.
Re:Graphics for JVM by chrisseaton on Tuesday November 17, 2020 @08:42AM (#25123599)
> I have it configured as my git mergetool

How are you doing this? I haven't seen any merge tool, let alone a standalone one, in the JetBrains toolbox. What am I missing?

Re:Graphics for JVM by cataphract on Tuesday November 17, 2020 @09:46AM (#25124260)
You invoke it with "idea.sh merge <left> <right> <base> <out>". TBH, I don't think it's anything special; I've been using p4merge for years.
Re:Graphics for JVM by anentropic on Tuesday November 17, 2020 @10:11AM (#25124587)
Re:Graphics for JVM by scaladev on Tuesday November 17, 2020 @08:18AM (#25123384)
Re:Graphics for JVM by maynman on Tuesday November 17, 2020 @10:05AM (#25124500)
I use IntelliJ for work every day and I agree, so many of its features make work so much better.
Re:Graphics for JVM by dathinab on Tuesday November 17, 2020 @08:37AM (#25123552)
Yes, but they are also an example of why people don't like Java UIs.

I.e. the amount of UI problems you have with it when using a tiling wm or wayland (or both) are just sad and make it unusable. Other widely used UI's might also have problems but at least are somewhat usable under wayland and/or tiling wm.

Ironically many of this problems go back/are rooted in to AWT...

In the past Intellij did work if started directly by x (without a wm) which was pretty cool for some very very neach use cases, but sadly (through reasonably) this isn't the case anymore.

Re:Graphics for JVM by wtetzner on Tuesday November 17, 2020 @09:37AM (#25124163)
Just out of curiosity, what issues do you run into using them in a tiling WM?
Re:Graphics for JVM by dathinab on Tuesday November 17, 2020 @10:55AM (#25125209)
Context menues not being at the right position, directly closing after opening (so fast that you can't really see it) as well as menu items sometimes not being selectable.

Especially the quick command/search menues doesn't work at all and context menues sometimes don't work either.

(Edit: And context/popup menues not working is the main theme of problems with Java GUIs, hence my parent post, also setting the "magic" no-reparenting env variable doesn't fix it)

Re:Graphics for JVM by _bin on Tuesday November 17, 2020 @11:13AM (#25125448)
I can second these issues using i3 and arch. I've had subtle issues like these in Ghidra and when I once tried Armitage (I wanted the Hail Mary feature), it was so messy I've never used it since.
Re:Graphics for JVM by vijaybritto on Tuesday November 17, 2020 @08:28AM (#25123466)
Most of the hate towards electron is only because of its resource usage problems and not because of its capabilities. Vscode is it's testament for capabilities. Jetbrains suite is great but they're not resource efficient in any way!

If the JVM based apps do not yield a significant performance benefit then there is no point in going after that.

Re:Graphics for JVM by levosmetalo on Tuesday November 17, 2020 @09:07AM (#25123856)
It's not only resource usage, but performance in general. I can feel lagging when typing slowly in VSCode editor, even in plain text files without even trying autocomplete or any IDE feature. IntelliJ IDEA doesn't have any lag, Eclipse too, and both offer more IDE capabilities than VSCode.
Re:Graphics for JVM by barnacled on Tuesday November 17, 2020 @09:15AM (#25123936)
The article covered another factor:

>The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.”

As a user of electron apps there are clearly limitations on what the UI can do as a result and the style of rendering it is clearly webish.

Another issue I keep on seeing with web based apps, moreso on android, is they seem utterly incapable of dealing with the slightest network non-connectivity. The UI tends to freeze.

I do take your point entirely on the fact that perhaps java's inherent performance limitations might result in a fairly comparable poor experience however.

Re:Graphics for JVM by dathinab on Tuesday November 17, 2020 @08:43AM (#25123608)
And the DOM, and the size overhead and it's JS/TS and some other parts from dev (i.e. not user) perspective.

Through tbh. I don't see much reason to spend time for a Java UI framework, Java for desktop is just kinda annoying and somewhat even more dead then Java for servers (which isn't really dead tbh).

Through I guess idea/Intellij would love to replace the low level parts with something which works more reliable.

Re:Graphics for JVM by vijaybritto on Tuesday November 17, 2020 @08:49AM (#25123671)
Yeah the reasons for choosing JS/TS don't have to be stated from developers' perspective because its the goto tool for new products nowadays.

Also I don't think the desktop app market for java is small in any way. But if there's no difference between electron and JVM UIs then there is no incentive for teams to switch.

Re:Graphics for JVM by funcDropShadow on Tuesday November 17, 2020 @03:25PM (#25129292)
But what about the teams coming from classical desktop application development. Perhaps they don't want to switch to Electron-based web development.
Re:Graphics for JVM by darkwater on Tuesday November 17, 2020 @09:39AM (#25124184)
Big plus for SweetHome 3d, I designed my new bathroom with it (nothing fancy, just some render to get the idea of how various options could look like, but given how bad I am at those things it was a great success!)
Re:Graphics for JVM by jmnicolas on Tuesday November 17, 2020 @09:07AM (#25123849)
Dbeaver is certainly not fast. It requires several seconds to start on a machine with a Core i5, 32G ram and a NVME SSD!

In fact VSCode starts faster.

Re:Graphics for JVM by fayten on Tuesday November 17, 2020 @10:05AM (#25124505)
Start time is not a great measure of overall performance. Also you are comparing two very different types of applications.

A text editor that can be extended vs a platform application is the same argument we've been having about vim vs emacs for years.

DBeaver is an incredibly powerful application that had allowed me to work in Postgres, Teradata, and Oracle databases for years. Could I do the same kind of work in VSCode? Absolutely not, unless I wanted to build out an entirely new interface on top of VSCode. By the time that work is done it could be equally slow to start up. DBeaver has an absolutely massive feature set tailored for database work and it has to load all those plugins at some point.

Another counter point is VSCode with java-lsp could never handle the 300k loc code base we developed on, where intelij and eclipse do just fine. Yes, they startup slowly, but at least they provided meaningful and fast autocomplete without the need to wait for the language sever or VScode to unfreeze.

Again these are purely anecdote, but please don't purely judge an application by it's startup time if it saves you time in the end.

Re:Graphics for JVM by InfiniteRand on Tuesday November 17, 2020 @10:42AM (#25125015)
One thing I've noticed is I don't care about start time if I'm going to be in one app for several hours, but if I'm doing a lot of switching between apps, without one app taking my primary focus, I become very sensitive to start-up time.

I also think the optimizations for high performance with a relatively small amount of data are fundamentally different than the optimizations for high performance with a very large amount of data, I have not really seen any GUI approach that scales smoothly from small amounts of data to large amounts of data without some complexity on the back-end

Re:Graphics for JVM by jmnicolas on Tuesday November 17, 2020 @10:42AM (#25125018)
I talked about speed not usefulness or features since parent said:

> There are lots of fast, usable JVM gui applications.

I used VSCode as an example because it's touted as the fastest electron app.

Now I have no idea how to benchmark DBeaver once it's running but since my use case is to launch it once in while to run a quick SQL query, startup time is important for me.

For years I have said I need a kind of SQL pad: a native app, that launches ultra fast, directly shows me the tables once connected (hide all the complexity of the DB) and let me run some SQL immediately. I guess I'll probably have to scratch my own itch once I find the time.

Re:Graphics for JVM by e12e on Tuesday November 17, 2020 @05:34PM (#25130834)
I recently came across Beekeeper Studio in a comment here on hn, and I really like it so far.

I generally use pgcli for talking to postgres, and I occasionally need sql developer for Oracle - but with Bk i might standardize on it for ms sql server, postgres and sqlite.

It's foss and electron. That it's snappier than sql developerto start isn't saying much... I guess.

https://www.beekeeperstudio.io/

https://github.com/beekeeper-studio/beekeeper-studio

https://www.pgcli.com/

I tried ms azure data studio or what it's called, and I think Beekeeper is a good alternative. It doesn't do all that sql server mgmt studio does - but then it also doesn't need to run in a windows vm..

Re:Graphics for JVM by jmnicolas on Wednesday November 18, 2020 @09:04AM (#25136832)
> I recently came across Beekeeper Studio in a comment here on hn

me too :) I installed it but didn't connect to any DB yet. Startup time is certainly no better than DBeaver though.

Re:Graphics for JVM by fayten on Tuesday November 17, 2020 @11:42AM (#25125822)
A co-worker that lived in his terminal used jsqsh[1] for simple queries to an Oracle DB when he did not need DBeaver. Jsqsh appears to no longer be maintained and I'm not quite sure how fast it is, but it still might be worth looking into. There is also usql[2] that you might be able to build something on top of.

[1]https://github.com/scgray/jsqsh [2]https://github.com/xo/usql

Re:Graphics for JVM by nicoburns on Tuesday November 17, 2020 @11:46AM (#25125891)
Table Plus has native versions for macOs and windows https://tableplus.com/
Re:Graphics for JVM by tealpod on Tuesday November 17, 2020 @08:26AM (#25123451)
Tealpod Image Compresssor for MacOs is built using JavaFX. https://www.tealpod.com/compressor/ Windows version is built using .NET, C#.
Re:Graphics for JVM by wtetzner on Tuesday November 17, 2020 @09:38AM (#25124176)
Interesting that they have two versions, when the JavaFX version should be cross-platform. Is it because they built the .NET version first?
Re:Graphics for JVM by rodamaral on Tuesday November 17, 2020 @11:01AM (#25125300)
Dbeaver is really ugly, though. To the point of being unusable due to aesthetics, like many Java apps.
Re:Graphics for JVM by nevertoolate on Tuesday November 17, 2020 @03:39PM (#25129493)
How aesthetics make it unusable?
Re:Graphics for JVM by 0x445442 on Tuesday November 17, 2020 @09:46AM (#25124258)
mucommander is on Github
Re:Graphics for JVM by anthk on Tuesday November 17, 2020 @08:45AM (#25123636)
>There are lots of fast, usable JVM gui applications.

Debatible, argueable.