The decline and fall of Java on the desktop(jdeploy.substack.com)
jdeploy.substack.com
The decline and fall of Java on the desktop
https://jdeploy.substack.com/p/the-decline-and-fall-of-java-on-the
359 comments
I had to use OpenJFX for school recently, and while I still hate the Java language, I had to begrudgingly admit that JavaFX really wasn't that bad at all. It more or less did what I wanted it to do, the resulting GUI didn't look too bad, and it performed well enough. I ended up using it for a Clojure app a bit later.
It's good enough to where I think that if JavaFX had come out around the same time as Swing, the Java GUI would substantially more popular. As it stands, when I tell people I'm using JavaFX, they either don't know what I'm talking about, or they'll say "isn't that just Swing? Yuck!"
It's good enough to where I think that if JavaFX had come out around the same time as Swing, the Java GUI would substantially more popular. As it stands, when I tell people I'm using JavaFX, they either don't know what I'm talking about, or they'll say "isn't that just Swing? Yuck!"
In Clojure you can use JavaFX through cljfx
https://github.com/cljfx/cljfx/
I haven't used React, but I think it's very similar. You have a state atom and then a datastructure that represents the GUI and associated callbacks that modify the atom. So it ends up feeling very functional. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate/plumbing to setup but then it's very smooth sailing. It even has a very handy memoization structure that allows you to seamlessly have intermediary derived states that update automatically. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy.
My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. And as usual, buy default, the JVM gobbles up and doesn't release memory back to the OS which is annoying. But i think it's surmountable and In theory you could trim that all further with GraalVM. Just out of the box it's not the best for little hello-world apps
https://github.com/cljfx/cljfx/
I haven't used React, but I think it's very similar. You have a state atom and then a datastructure that represents the GUI and associated callbacks that modify the atom. So it ends up feeling very functional. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate/plumbing to setup but then it's very smooth sailing. It even has a very handy memoization structure that allows you to seamlessly have intermediary derived states that update automatically. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy.
My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. And as usual, buy default, the JVM gobbles up and doesn't release memory back to the OS which is annoying. But i think it's surmountable and In theory you could trim that all further with GraalVM. Just out of the box it's not the best for little hello-world apps
I’ve found cljfx very productive. Steep learning curve, and the abstractions are somewhat leaky, but it’s worth the pain around the edges for the core workflow. Wrapping controls like ControlsFX is trivial. We’ve written a wrapper for TestFX as well so we have full functional tests and everything gets built, tested, jlinked and jpackaged continuously. It’s been one of the least painful projects I’ve ever worked on tbh.
Do you have any good resources on how to use jlink/ jpackage with Clojure? Do you somehow embed it in a Uberjar or is the Uberjar part of the package besides the JRE?
You build your Clojure app as an uberjar, yes. Only gotcha here is to remember "-Dcljfx.skip-javafx-initialization=true" so the JFX thread doesn't get started during build, and I've had no problems using Clojure's direct linking either. You use jlink[1] to create a custom runtime JRE image (this isn't strictly necessary if you're deploying to machines with a JRE but it cuts down on moving parts and gives you more control). jpackage[2] then takes that runtime image and your uberjar and creates installers for Mac/Windows/Linux. Both are command line tools, and we just have GitHub Actions that cut new releases for each platform when we tag something with a new version.
Worth also keeping an eye on jDeploy[3] which adds extra goodies like auto updates, at the cost of some npm shenanigans. Not something I've played with yet though.
1: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jli...
2: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa...
3: https://www.jdeploy.com/
Worth also keeping an eye on jDeploy[3] which adds extra goodies like auto updates, at the cost of some npm shenanigans. Not something I've played with yet though.
1: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jli...
2: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa...
3: https://www.jdeploy.com/
"at the cost of some npm shenanigans"
jDeploy developer here. No shenanigans, I swear. npm just simplified things. Some have expressed interest in adding self-hosting options, so I'll likely add support for that. It's open source too, so others could potentially add other hosting options also.
jDeploy developer here. No shenanigans, I swear. npm just simplified things. Some have expressed interest in adding self-hosting options, so I'll likely add support for that. It's open source too, so others could potentially add other hosting options also.
Yeah sorry I didn't mean anything underhanded, it's just a complication that made me reluctant to try it out initially. Honestly if you wanted to offer a whole turnkey commercial service with hosting and analytics and stuff I could imagine being drawn to that.
Thank you for the tips! At OrgPad, we currently use the system-wide JRE since we control the whole VM, this is not a huge issue. We build & deploy by just copying the (uber)jar and restarting the systemd service. Quite simple but I like to keep up with some other approaches and we never know, when we have to do a desktop app or something.
I hate the old school way of writing Java more than any other language.
I love writing in "modern" Java more than any other language.
Lombok, RxJava/Reactor where possible, and monads everywhere. It is beautiful and succinct, though I totally appreciate it may not always be easy to introduce on older frameworks or legacy projects.
Lombok, RxJava/Reactor where possible, and monads everywhere. It is beautiful and succinct, though I totally appreciate it may not always be easy to introduce on older frameworks or legacy projects.
Can you link an example of a codebase written in this modern-Java style? I've seen parts of it here and there, but I don't think I've ever seen all this used together.
[deleted]
Lombok is too much magic for me, record class and the annotation generators libraries are a bit less magic
>Lombok is too much magic for me
If an object is just data, then @Data is all you need. If an object crunches numbers, then @Service with @RequiredArgsConstructor if you don't prefer to @Autowired things individually.
Any other usage of Lombok is possibly indicative of a questionable application design imo
If an object is just data, then @Data is all you need. If an object crunches numbers, then @Service with @RequiredArgsConstructor if you don't prefer to @Autowired things individually.
Any other usage of Lombok is possibly indicative of a questionable application design imo
Try Kotlin. Unlike Scala, it's not really a new language, it's more like syntactic sugar.
Haven't used Lombox, RxJava is great, but it just feel like bandaids on a language that wasn't really designed for it.
There's no accounting for taste, but I'll take either Scala or Clojure on the JVM any day of the week. Scala's monads don't feel like a library feature, they feel baked into the language...because they are.
There's no accounting for taste, but I'll take either Scala or Clojure on the JVM any day of the week. Scala's monads don't feel like a library feature, they feel baked into the language...because they are.
Lombok is indeed a band-aid that replaces IDE-autogenerated code, which in turn is a band-aid for language design choices on the one hand (e.g. equals and hashcode), and accepted Best Practices in Java world like setters/getters everywhere; for the latter, you can either do public final fields, just use public fields until you need an accessor method (java's refactorings are great), or on the other hand add language features like in C# and Scala where from a class consumer point of view, accessing a value or calling a setter/getter are the same.
That said, I did hear Java is getting value types soon, or something like that. A bit too little too late maybe, but welcome nevertheless.
If I had the choice I wouldn't use Java again; JVM is fine, but there's better languages for it than plain Java. Kotlin seems alright. Wouldn't use Scala again, that's a language for sadists.
That said, I did hear Java is getting value types soon, or something like that. A bit too little too late maybe, but welcome nevertheless.
If I had the choice I wouldn't use Java again; JVM is fine, but there's better languages for it than plain Java. Kotlin seems alright. Wouldn't use Scala again, that's a language for sadists.
> That said, I did hear Java is getting value types soon, or something like that.
Java has had records (the thing that's like Lombok) since Java 14.
What Java is soon getting is inline value types, i.e. datatypes that work like primitives (are pass-by-value; have no identity but rather structural equality; are freely copyable; can be held on the stack, or intrusively within a containing array; etc.)
Java has had records (the thing that's like Lombok) since Java 14.
What Java is soon getting is inline value types, i.e. datatypes that work like primitives (are pass-by-value; have no identity but rather structural equality; are freely copyable; can be held on the stack, or intrusively within a containing array; etc.)
Java designers chose the public method with the same name as the corresponding field policy as the preferred one (as per record’s design), this combined with the coming syntax for “copy the object but changing these fields” will make java quite good to use imo.
Scala definitely has its irritations but I’ve grown to accept it. It has enough cool features to justify its existence.
I’ve not used kotlin but people I respect say it’s great, maybe that’s better than Scala.
I’ve not used kotlin but people I respect say it’s great, maybe that’s better than Scala.
IME Kotlin is the worst of both worlds. It's like they took every cool one-liner example from Scala and said "see, you don't need a whole functional language to do that, we can just add this piece of syntax sugar and you can do the same thing while keeping that Java feel", but once you've done that a half-dozen times you end up with a language that's actually even more complicated since it doesn't have the underlying consistent core that Scala does.
I like Scala a lot more than I feel like I should. It’s weird to say that it’s a language that feels too academic while also being heavily used by enterprises. I used it a lot while working at BigCo and there were a lot of times that the language got in the way of getting things done due to the design. But it is really elegant once you understand it. It’s no Lisp, of course, but it feels somehow both pragmatic and academic in getting things done. And for writing Spark, it’s quite expressive.
Why use Lombok if you can use Groovy + CompileStatic? Does lombok do anything groovy can't do?
Scala is far ahead of its time. And has been since 2014.
[deleted]
Just to elaborate, we make heavy use of JNA to interface with platform-specific facilities such as Keychain, Notifications, etc.
JNA is an awesome piece of technology.
JNA is an awesome piece of technology.
JavaFX was pretty good when I evaluated it around the time of JDK7/8. At the time I was also looking into other Rich Client Platforms: Adobe AIR, MS Silverlight, Eclipse RCP, and (sort-of-not really) Netbeans. Any of them could techically be used but JavaFX was the most open and likely to be supported at that time. Used it for come proof-of-concepts and it worked fine, though it took some re-orientation for some devs.
The unbundling of JavaFx from JDK has made using JavaFx a bit of a chore in a new project. I think it was a bad move, and has made the future of JavaFx uncertain.
Question is can JavaFx be recommended for a new project, given the uncertainty of its future and lack of popularity.
Question is can JavaFx be recommended for a new project, given the uncertainty of its future and lack of popularity.
What's your product - if you don't mind sharing?
Not OP, but if you're looking for a quick look, I use AudioBookConverter [1] that uses OpenJFX to execute ffmpeg commands to build M4B files. It's very clunky, especially when you install updates and such. But it gets the job done.
[1] https://github.com/yermak/AudioBookConverter
[1] https://github.com/yermak/AudioBookConverter
Have you by chance had any experience with using Kotlin with JavaFX/OpenJFX? I've never been much of a fan of Java, but have had a fair amount of exposure to Kotlin via Android development and have found it fairly pleasant to work with, so if it meshes well with OpenJFX that may appeal to me as an option for cross-platform desktop dev.
I love kotlin and have messed around with javafx + kotlin. It works well once you have set it up.
Do you mean TornadoFX, or some other kind of JavaFX-with-Kotlin?
In Kotlin, you can use any Java library without a wrapper. That includes JavaFX of course.
TornadoFX is only a convenience skin on top of JavaFX to make Kotlin code more concise (but it's heavier also as it adds a lot of code to your application).
TornadoFX is only a convenience skin on top of JavaFX to make Kotlin code more concise (but it's heavier also as it adds a lot of code to your application).
I wouldn't use Tornado - it's effectively dead. Hasn't been a commit merged in for 5 months, and doesn't seem any forks have really picked up the mantle.
Last time I used jlink it produced a bunch of folders and a shell file to launch. Is it possible to make it a single binary executable instead (preferrably without GraalVM)?
Also I tried to get rid of unused classes using Proguard, but there are zero tutorials for non-Android java apps.
Also I tried to get rid of unused classes using Proguard, but there are zero tutorials for non-Android java apps.
You need jpackage for that, which will create a native executable (unfortunately only for the given platform)
I'm working on a personal project at the moment that uses a shared C++ core across Android and iOS. (It's an image processing plugin for Unity, no GUI, so cross platform frameworks aren't suitable). It was complicated to setup, but I'm glad I did. Only having to write 99% of the code once is a life saver.
Java apps can't be notarized for MacOS according to the developer agreement.
They surely can, it is a matter of using the right tools.
https://gluonhq.com/products/mobile/vm/
https://www.codenameone.com/
https://gluonhq.com/products/mobile/vm/
https://www.codenameone.com/
Can you expand on this? I know for a fact they can be _technically_ notarized, which developer agreement bans it?
IMO the real decline was Oracle.
Java used to be a slowly rising language and set of platforms with benevolent oversight from SUN and at least the outlook that it was one of a few things you might want to add after Microsoft's Windows or Apple's OS (Macintosh or later OSX).
Then Oracle bought SUN and everyone knew all of the good would eventually be strangled out by the lawyers and models that sought to dominate and extract for revenue control.
Java used to be a slowly rising language and set of platforms with benevolent oversight from SUN and at least the outlook that it was one of a few things you might want to add after Microsoft's Windows or Apple's OS (Macintosh or later OSX).
Then Oracle bought SUN and everyone knew all of the good would eventually be strangled out by the lawyers and models that sought to dominate and extract for revenue control.
Oracle certainly wasn't good for Java.
But Java-on-the-desktop had been struggling for years before that. You either bundled a complete JVM with your application (fine if you're making a 500MB IDE, not so good for anything smaller) or you had the embarrassment of directing your users to an installer that bundled the Ask toolbar. They might even end up with the security-hole-riddled java browser plugin. And even once the user has java installed, you can't just double-click a jar file to run it. And the performance isn't anything to write home about either, if Eclipse is anything to go by.
Java remains a fine choice for use on the server, of course.
But Java-on-the-desktop had been struggling for years before that. You either bundled a complete JVM with your application (fine if you're making a 500MB IDE, not so good for anything smaller) or you had the embarrassment of directing your users to an installer that bundled the Ask toolbar. They might even end up with the security-hole-riddled java browser plugin. And even once the user has java installed, you can't just double-click a jar file to run it. And the performance isn't anything to write home about either, if Eclipse is anything to go by.
Java remains a fine choice for use on the server, of course.
In fact Oracle saved Java. Sun was struggling and Java was stagnant at the time. There was hardly any big innovation in the last years under (the) Sun. Java Modules started in the Sun age, but they didn't get it out of the door. J2EE / Java EE was also kind of dozed off.
So, while Oracle is for sure not the most sympathetic company, it is good at execution.
So, while Oracle is for sure not the most sympathetic company, it is good at execution.
Google or IBM would have been better tjam Oracle. This seems like a false choice: Oracle or nothing.
Back when Java/Sun were up for grabs:
1) Google by far (they were less evil back then, I think). I mean, they would have saved money and headaches and probably a lot of distracting management meetings.
2) IBM, well ok: they did Eclipse, had their own JDK, and a lot of enterprise customers on locked platforms that could financially support the language and platform and were decent contributors to Linux.
... ....
3) Really? Oracle?
It's a miracle Oracle didn't completely kill Java.
Back when Java/Sun were up for grabs:
1) Google by far (they were less evil back then, I think). I mean, they would have saved money and headaches and probably a lot of distracting management meetings.
2) IBM, well ok: they did Eclipse, had their own JDK, and a lot of enterprise customers on locked platforms that could financially support the language and platform and were decent contributors to Linux.
... ....
3) Really? Oracle?
It's a miracle Oracle didn't completely kill Java.
Yes, really Oracle.
They were one of the first companies to jump into Java, in fact the first conference talk about Java that we had on the campus back in 1996 was sponsored by Oracle.
They also collaborated with Sun on the Network Computer thin clients for Java based computers.
In 1999, all Oracle GUIs for their software were converted into Java applications.
They also own J/Rockit and BEA, whose core technologies now live on OpenJDK (JFR, JIT Cache, GC) as free beer instead of enterprise prices.
IBM already has their own Java, and have done so since forever, including some extensions (AOT is supported since decades), so it is debatable what they would further do, kill OpenJDK and replace it with J9?
Given Dart and Go examples, and Android with outsourced everything (language, IDE, messy updates, forked language), thankfully Google doesn't own Java.
They were one of the first companies to jump into Java, in fact the first conference talk about Java that we had on the campus back in 1996 was sponsored by Oracle.
They also collaborated with Sun on the Network Computer thin clients for Java based computers.
In 1999, all Oracle GUIs for their software were converted into Java applications.
They also own J/Rockit and BEA, whose core technologies now live on OpenJDK (JFR, JIT Cache, GC) as free beer instead of enterprise prices.
IBM already has their own Java, and have done so since forever, including some extensions (AOT is supported since decades), so it is debatable what they would further do, kill OpenJDK and replace it with J9?
Given Dart and Go examples, and Android with outsourced everything (language, IDE, messy updates, forked language), thankfully Google doesn't own Java.
Don't try to gaslight me that Oracle is some benevolent company and the BEA / etc product suite of Oracle was some grandiose idealistic movement of software.
IBM and Oracle have a history of acquiring companies to acquire customers.
The difference between the two is that Oracle acquires software so it can sue them. IBM just wants to sell hardware and licenses. Um, yeah, I'll take IBM.
Oracle of course jumped on Java. What was the alternative? IBM had DB/2 at the time. Microsoft had SQLServer. That's not some great vision or buy-in with the Java ecosystem, it was just economic calculation.
And why did Oracle acquire Java? Oh that's right, they only cared about suing google. There are numerous stories of Oracle asking Sun officials specifically about that potential avenue of litigation, almost to the exclusion of any technical merits or other value to the Java assets.
Oracle bundled Ask.com toolbar. End of story.
Google would have simply outsourced everything. Win win win.
IBM and Oracle have a history of acquiring companies to acquire customers.
The difference between the two is that Oracle acquires software so it can sue them. IBM just wants to sell hardware and licenses. Um, yeah, I'll take IBM.
Oracle of course jumped on Java. What was the alternative? IBM had DB/2 at the time. Microsoft had SQLServer. That's not some great vision or buy-in with the Java ecosystem, it was just economic calculation.
And why did Oracle acquire Java? Oh that's right, they only cared about suing google. There are numerous stories of Oracle asking Sun officials specifically about that potential avenue of litigation, almost to the exclusion of any technical merits or other value to the Java assets.
Oracle bundled Ask.com toolbar. End of story.
Google would have simply outsourced everything. Win win win.
Gaslighting?!?
No one else bothered to buy Sun, or top Oracle's offer, that is how much the industry cared for Sun.
The amount of hate speech people can vomit against Oracle doesn't change that fact.
> And why did Oracle acquire Java? Oh that's right, they only cared about suing google. There are numerous stories of Oracle asking Sun officials specifically about that potential avenue of litigation, almost to the exclusion of any technical merits or other value to the Java assets.
Sun wanted to sue as well, they already lacked the funds to do that.
James Gosling on the matter, https://www.youtube.com/watch?v=ZYw3X4RZv6Y&t=3462s
> Oracle bundled Ask.com toolbar. End of story.
Learn your story, Sun did that not Oracle.
When Sun was acquired, Java was at version 6, and MaximeVM was a Sun Research Labs project.
Now we have Java 17 and MaximeVM graduated into GraalVM.
And to re-iterate, no one else, not a single company, bothered to top Oracle's bid.
It was definitly end of story for Sun's mismanagement.
No one else bothered to buy Sun, or top Oracle's offer, that is how much the industry cared for Sun.
The amount of hate speech people can vomit against Oracle doesn't change that fact.
> And why did Oracle acquire Java? Oh that's right, they only cared about suing google. There are numerous stories of Oracle asking Sun officials specifically about that potential avenue of litigation, almost to the exclusion of any technical merits or other value to the Java assets.
Sun wanted to sue as well, they already lacked the funds to do that.
James Gosling on the matter, https://www.youtube.com/watch?v=ZYw3X4RZv6Y&t=3462s
> Oracle bundled Ask.com toolbar. End of story.
Learn your story, Sun did that not Oracle.
When Sun was acquired, Java was at version 6, and MaximeVM was a Sun Research Labs project.
Now we have Java 17 and MaximeVM graduated into GraalVM.
And to re-iterate, no one else, not a single company, bothered to top Oracle's bid.
It was definitly end of story for Sun's mismanagement.
2005-2006 brought as generics and EJB3. Quite the opposite of stagnation.
But Oracle bought Sun (and Java) only in 2009. In the last 3 to 4 years there was not much going on.
Don't forget quite a few multithreading improvememts!
The hassle involved with needing multiple versions of Java on one system also impacts its viability on the desktop. Not a problem if you run your Java-based services in containers that can use their own JRE, but a huge annoyance for kids and budding hobbyists who try to run Spigot and god knows what else on the same computer.
There is not even a JRE anymore, current best practice is to create a platform-specific lean package with jpackage that will only contain the modules that is actually used (decreasing binary size as well startup time). So the current direction is very much away from the old ways.
You are right in that desktop Java aldready was a mess when Oracle took over. And I agree that distribution was a hassle. At the time it was hard to create standalone .exe or .msi for distribution. Webstart broke so often it was impossible to use outside strictly controlled corporate environments
But the bundling of Ask toolbar came about in 2013, so that was definitely Oracles doing.
But the bundling of Ask toolbar came about in 2013, so that was definitely Oracles doing.
Not good for Java?!? I guess you enjoy being stuck on Java 6 then.
...or you had the embarrassment of directing your users to an installer that bundled the Ask toolbar
....the Ask toolbar. Had happily forgotten about that.
shudder
....the Ask toolbar. Had happily forgotten about that.
shudder
> They might even end up with the security-hole-riddled java browser plugin
but at least this would let them play Ski Stunt Simulator...
but at least this would let them play Ski Stunt Simulator...
Basically, every growth figure of the language shows otherwise. Oracle is ain’t saints, but the amount of needless bashing it gets here is astonishing.
Regardless of what its other branches are doing, Oracle managed to do one of the smoothest language takeovers where the (stellar) core team is virtually unchanged, the language became completely open sourced and it underwent tremendous changes which resulted in huge growths after the slowdown at the end of the Sun era.
Note: I am not working at Oracle and never have.
Regardless of what its other branches are doing, Oracle managed to do one of the smoothest language takeovers where the (stellar) core team is virtually unchanged, the language became completely open sourced and it underwent tremendous changes which resulted in huge growths after the slowdown at the end of the Sun era.
Note: I am not working at Oracle and never have.
> but the amount of needless bashing it gets here is astonishing
I don't think it's needless. I'll bash Java as long as it's the language for AP computer science. Imagine a budding young programmer, bright eyed and bushy tailed, eager to get into computer science. They get to class and greet the teacher "Welcome class, let's learn about Java. There's a wide world of computers out there, but your perception of computing will be that Computing <-> Java until maybe the sophomore year of college. Have fun!"
Students come to me their sophomore year of college completely awestruck. "I had not idea! I thought programming was all Java!" they tell me. Imagine that. Close your eyes and picture a world where all of programming is Java programming. How quick did you open them and splash water on your face to wake rid yourself from that nightmare?
Java is singlehandedly responsible for snuffing the dream of so many young programmers. I've seen it in my own research, where kids in elemntary and middle school describe programming as fun, interesting, and challenging. That's because at this age they're using fun languages like Blockly, and they spend their time programming making and playing games.
Then they get to AP computer science and they are introduced to Java. Perceptions of programming fall through the floor, with more students calling it difficult, frustrating, and scary. It's tragic what Java is doing to young people.
Like, I understand we want students to have skills they will use in business, but we can't present programming to them as if all of programming is OOP enterprise development in Java. It's a crying shame.
I don't think it's needless. I'll bash Java as long as it's the language for AP computer science. Imagine a budding young programmer, bright eyed and bushy tailed, eager to get into computer science. They get to class and greet the teacher "Welcome class, let's learn about Java. There's a wide world of computers out there, but your perception of computing will be that Computing <-> Java until maybe the sophomore year of college. Have fun!"
Students come to me their sophomore year of college completely awestruck. "I had not idea! I thought programming was all Java!" they tell me. Imagine that. Close your eyes and picture a world where all of programming is Java programming. How quick did you open them and splash water on your face to wake rid yourself from that nightmare?
Java is singlehandedly responsible for snuffing the dream of so many young programmers. I've seen it in my own research, where kids in elemntary and middle school describe programming as fun, interesting, and challenging. That's because at this age they're using fun languages like Blockly, and they spend their time programming making and playing games.
Then they get to AP computer science and they are introduced to Java. Perceptions of programming fall through the floor, with more students calling it difficult, frustrating, and scary. It's tragic what Java is doing to young people.
Like, I understand we want students to have skills they will use in business, but we can't present programming to them as if all of programming is OOP enterprise development in Java. It's a crying shame.
Teaching Java in abstract, useless lessons about OOP and inheritance is definitely bad.
But I would say Java is as good a first language as python is.
The purpose of first programming language is teaching concepts - functions, structs / classes, abstraction, data structures (importantly lists and maps); And how to solve problems using that.
Python does well in intuitive syntax for lists/maps, handy standard library functions, and having an REPL; But it gives an illusion that types are redundant. The programmer picking up C++ or Java after python sees only ceremony.
You can also learn the modern java without all the OOP shoved in: Basic programs, functions, data types, arrays, using classes to create custom types, using HashMap, ArrayList, HashSet from standard library; then interfaces, inheritance / subtyping, lambda functions. Use jshell to try small snippets;
The problem with teachers teaching java is that they focus too much on inheritance, with mostly superficial examples like "dog extends animal" instead of something in real world. Inheritance is mostly about subtyping, and any CS student with enough math background should not struggle to understand that.
But I would say Java is as good a first language as python is.
The purpose of first programming language is teaching concepts - functions, structs / classes, abstraction, data structures (importantly lists and maps); And how to solve problems using that.
Python does well in intuitive syntax for lists/maps, handy standard library functions, and having an REPL; But it gives an illusion that types are redundant. The programmer picking up C++ or Java after python sees only ceremony.
You can also learn the modern java without all the OOP shoved in: Basic programs, functions, data types, arrays, using classes to create custom types, using HashMap, ArrayList, HashSet from standard library; then interfaces, inheritance / subtyping, lambda functions. Use jshell to try small snippets;
The problem with teachers teaching java is that they focus too much on inheritance, with mostly superficial examples like "dog extends animal" instead of something in real world. Inheritance is mostly about subtyping, and any CS student with enough math background should not struggle to understand that.
> "I thought programming was all Java!"
If students get this preconception, I think it's more an issue how they are taught, not an issue with Java itself. I mean the first language I learned and most of my classes were in Java, but that didn't prevent me from knowing there other existing languages and learning about them.
If students get this preconception, I think it's more an issue how they are taught, not an issue with Java itself. I mean the first language I learned and most of my classes were in Java, but that didn't prevent me from knowing there other existing languages and learning about them.
though, on retrospect, I can admit that Java might not be the best language to learn programming
Agree, but recently Minecraft mod (written in Java) is a popular way how to learn code with joy.
There are books like "Java in Two Semesters: Featuring JavaFX" [0], which appears in the series "Texts in Computer Science"! Now, that series used to be called "Graduate Texts in Computer Science", until they dropped the Graduate to allow for books like these, I guess. And even "Undergraduate" would have been an oversell. Actually, "Computer Science" still is.
[0]: https://link.springer.com/book/10.1007/978-3-319-99420-8
[0]: https://link.springer.com/book/10.1007/978-3-319-99420-8
That's not the fault of the language, though I'd say maybe Kotlin is a considerably better choice nowadays. If by blockly you mean the visual interface, what you said is going to be true for any language. If by blockly you mean javascript, maybe, but honestly if it's an exercise to build foundations (and not just for personal gratification), javascript (or python) isn't much easier for kids than Java, because it has more footguns. And if there's any fault in the language chosen for AP computer science, the blame should go to the designer of the curriculum.
> And if there's any fault in the language chosen for AP computer science, the blame should go to the designer of the curriculum.
Java was recommended for AP CS 22 years ago. At this point I lay less fault at their feet and I'm more interested in why it's still there at long last.
> If by blockly you mean the visual interface, what you said is going to be true for any language.
My research isn't published yet but I've found this is not necessarily true. This is a product of taking a thing not built for kids but rather professional programmers, and then forcing kids to use it. The problem with Java is that it's the kind of system where you need to know everything about it to use it all. Going from 0 to "hello world" requires over a dozen distinct Java concepts explained.
That's lesson one, and all it gets you is "Hello World". Most instructors handle this as "Ignore all the things you're writing down, we'll talk about them over the course of the next 3 months." Because that's how long it really takes.
This leaves students in a perpetual state of confusion, where they feel like they never really understand what's going on. Everything is a mysterious incantation and nothing really makes sense. Do wrong thing and it tells you it's wrong, but you won't understand why.
Students spend a lot of time memorizing "static void pub main()"... or was it public void static main? Or static public void class? I dunno, let's consult the spellbook. Because on day one their instructor said "ignore all of that, it's too complicated for you." Well students do ignore all of that, and it teaches exactly the wrong lesson -- they don't learn Java or programming, they learn that programming is hard and not for them yet. It's beyond them, but they're going to do it, and maybe one day they will understand, but not today. Today just write the code and run it.
At this point, most students give up. And I will say that yes, this is Java's fault. Not all programming languages require you to learn a dozen very deep and nuanced concepts to get to "Hello World".
Here's the ideal Hello World program for students and honestly for me too:
It's my contention that the design of the Java language frequently turns away all but the most technically minded students at precisely the time when they are the most impressionable when it comes to their perceptions of computing, and we're all worse off for it.
Java was recommended for AP CS 22 years ago. At this point I lay less fault at their feet and I'm more interested in why it's still there at long last.
> If by blockly you mean the visual interface, what you said is going to be true for any language.
My research isn't published yet but I've found this is not necessarily true. This is a product of taking a thing not built for kids but rather professional programmers, and then forcing kids to use it. The problem with Java is that it's the kind of system where you need to know everything about it to use it all. Going from 0 to "hello world" requires over a dozen distinct Java concepts explained.
public class MyFirstJavaProgram {
public static void main(String []args) {
System.out.println("Hello World");
}
}
That's lesson one, and all it gets you is "Hello World". Most instructors handle this as "Ignore all the things you're writing down, we'll talk about them over the course of the next 3 months." Because that's how long it really takes.
This leaves students in a perpetual state of confusion, where they feel like they never really understand what's going on. Everything is a mysterious incantation and nothing really makes sense. Do wrong thing and it tells you it's wrong, but you won't understand why.
Students spend a lot of time memorizing "static void pub main()"... or was it public void static main? Or static public void class? I dunno, let's consult the spellbook. Because on day one their instructor said "ignore all of that, it's too complicated for you." Well students do ignore all of that, and it teaches exactly the wrong lesson -- they don't learn Java or programming, they learn that programming is hard and not for them yet. It's beyond them, but they're going to do it, and maybe one day they will understand, but not today. Today just write the code and run it.
At this point, most students give up. And I will say that yes, this is Java's fault. Not all programming languages require you to learn a dozen very deep and nuanced concepts to get to "Hello World".
Here's the ideal Hello World program for students and honestly for me too:
"Hello World"
It's my contention that the design of the Java language frequently turns away all but the most technically minded students at precisely the time when they are the most impressionable when it comes to their perceptions of computing, and we're all worse off for it.
Well said! Java is the exact opposite of sane defaults: the programmer must explicitly choose defaults at every turn.
Furthermore, it constantly feels like the arcane minutiae required in Java is Java-specific, in a way that other languages (C-based, functional) aren't.
In Java, if I memorize an incantation, most of the information I've just learned is Java-specific.
In C or C++, it's more computing specific. Other languages will use different syntax, but I will be doing the same thing.
But I guess that's one of the weaknesses of reimplementing a computer in the JVM, and then writing a high-performance language to target that abstracted machine.
Furthermore, it constantly feels like the arcane minutiae required in Java is Java-specific, in a way that other languages (C-based, functional) aren't.
In Java, if I memorize an incantation, most of the information I've just learned is Java-specific.
In C or C++, it's more computing specific. Other languages will use different syntax, but I will be doing the same thing.
But I guess that's one of the weaknesses of reimplementing a computer in the JVM, and then writing a high-performance language to target that abstracted machine.
> In C or C++, it's more computing specific. Other languages will use different syntax, but I will be doing the same thing.
I think you’ve just internalised C-isms. The core Java language is as close to conventional OOP as it gets, and the model is not that different from most OOP languages. It certainly isn’t alien. We ended up conflating C and computing, but it is more an accident of history and because so many languages borrowed so heavily from it.
I think you’ve just internalised C-isms. The core Java language is as close to conventional OOP as it gets, and the model is not that different from most OOP languages. It certainly isn’t alien. We ended up conflating C and computing, but it is more an accident of history and because so many languages borrowed so heavily from it.
Java pass by reference vs pass by value vs C pass by reference vs pass by value?
Both languages are strictly pass by value. Java pretty much uses pointers (references in name only) and primitives only, and both languages copies these all by value. For actual reference you have to go to c++.
For intro computer science students, pointers-as-explicit-references are far easier to comprehend than Java's esoterica.
Said as someone who took intro computer science at 2 universities across 3 courses (C/C++, Python, Java), due engineering to art to computer science major switching.
I understand why Java did what they did, from a performance standpoint, but that's a poor highest value to hold for education use.
And in retrospect, was batshit user-hostile. F.ex. with a few more keywords and rules, C# smoothed off so many rough edges.
Said as someone who took intro computer science at 2 universities across 3 courses (C/C++, Python, Java), due engineering to art to computer science major switching.
I understand why Java did what they did, from a performance standpoint, but that's a poor highest value to hold for education use.
And in retrospect, was batshit user-hostile. F.ex. with a few more keywords and rules, C# smoothed off so many rough edges.
> pointers-as-explicit-references are far easier to comprehend than Java's esoterica.
What is esoteric about Java’s references? They are basically equivalent to C pointers without arithmetics and marketed as references. It is pretty much the same for most high level languages.
What is esoteric about Java’s references? They are basically equivalent to C pointers without arithmetics and marketed as references. It is pretty much the same for most high level languages.
The object/primitive distinction, which seems like something an intro CS student really shouldn't be wasting their time learning.
IMHO, the C-style */& was far clearer when I was first learning to program. Especially since you could just echo out the (virtual) memory address.
IMHO, the C-style */& was far clearer when I was first learning to program. Especially since you could just echo out the (virtual) memory address.
> For intro computer science students, pointers-as-explicit-references are far easier to comprehend than Java's esoterica.
C pointers are even worse as an introduction.
C pointers are even worse as an introduction.
> Java is the exact opposite of sane defaults
That honour belongs to C derived languages.
That honour belongs to C derived languages.
For just a lesson of writing code to achieve a specific functionality, you can streamline the process a lot by just starting with a template and let students fill in the gaps. So you don't necessarily make them spend time on "public static final void main", but setup a project in which students can type code, build and see results. To teach them to write robotics code, you can create a Robot class for them to play with, and then gradually
move into the more lower level details. That's certainly how it's done in many college courses too, where templates are setup and students are expected to incrementally add things to address the specific concepts they need to learn, but without worrying too much about details that don't relate to the fundamental concepts. Sure it requires some investment on your side, but your students benefit from being able to start picking up a more marketable skill. This also helps them see your code organization and existing implementation, which they can mimic if they want to extend beyond what's taught.
Matlab is really not a good example imo because if you start wanting to do a bit more, even if it's just to organize the code in better logical blocks, it bad design and lack of OOP gets in the way and makes further progress slower especially for the more talented students.
And finally, while I agree Java might not be the most optimal to teach at the AP level, what you said isn't worth bashing the language for in general terms. It's still sqaurely the AP curriculum's fault that it chooses Java and at the same time requires it to be taught in a way that's not fun or efficient, and not have updated it in 2 decades (while Java had many iterations)
Matlab is really not a good example imo because if you start wanting to do a bit more, even if it's just to organize the code in better logical blocks, it bad design and lack of OOP gets in the way and makes further progress slower especially for the more talented students.
And finally, while I agree Java might not be the most optimal to teach at the AP level, what you said isn't worth bashing the language for in general terms. It's still sqaurely the AP curriculum's fault that it chooses Java and at the same time requires it to be taught in a way that's not fun or efficient, and not have updated it in 2 decades (while Java had many iterations)
Matlab has a had OOP for a long time now. It's actually the language where first learned about classes and it provided a fine foundation to later learn more conventional OOP languages like python and c++. I'd say it's a fine language for exploring robotics or anything science related. Compared to pretty much all the competition, it just gets out of your way in anything math-adjecent.
Somewhat ironically, matlab the application is written in Java.
Somewhat ironically, matlab the application is written in Java.
> you can streamline the process a lot by just starting with a template and let students fill in the gaps. So you don't necessarily make them spend time on "public static final void main", but setup a project in which students can type code, build and see results.
By all means, if you think you can come up with a way to teach Java to children that's fun and efficient be my guest. We've been trying for decades and haven't cracked the code, so to speak. A lot of professional developers who have no interactions with children have "thoughts" about teaching programming to children, and when those thoughts meet reality, they often find out its not so easy as just writing a little class wrapper and that's all it's going to take. The abstractions of your template designed to hide all of the complexity are going to leak very quickly, I think you will find.
> Matlab is really not a good example imo because if you start wanting to do a bit more, even if it's just to organize the code in better logical blocks, it bad design and lack of OOP gets in the way and makes further progress slower especially for the more talented students.
I've gotta ask if you've actually taught any students using Matlab (or Java for that matter). By what metric do you say it's a bad design? Are you speaking from the perspective of a professional programmer who uses tools to write professional software? Or are you speaking from the perspective of someone who teaches children regularly and are critiquing its design from that perspective?
Because in my experience Matlab has a great design for teaching. It has a ubiquitous data structure, a table, which can store any kind of datatype without having to specify it. You don't have to know about ints, longs, floats, shorts and chars -- all you need to know are there are numbers, and sometimes strings, but mostly just numbers. And the tables/arrays start at index 1. That's a huge deal for teaching students but programmers hate it. They call starting at 1 bad design, but starting at index 0 is definitely an example of something that gets in the way and makes further progress slower for children. But I've gotta say your statements about "especially for the most talented students" rings especially untrue to me because the most talented students are really never slowed down IMO.
Moreover the REPL interface of Matlab allows them to play with their code as they develop it. JAVA doesn't have a REPL and the write-compile-run loops is too long that students lose interest in the coding and debugging phase. Kids love to pair program with a REPL. They are engaged as the interactivity gives them constant incremental feedback. The write-compile-test loop of Java is long enough that pair programming isn't fun for kids. I'll put it this way: for kids, pair programming in a REPL is like playing a game, pair programming in an IDE has all the fun and excitement of writing a book report. Exploratory programming is a sad story in Java, but it's Matlab's raison d'etre.
> Sure it requires some investment on your side, but your students benefit from being able to start picking up a more marketable skill.
Here's the thing, and this is the big problem with AP CS, and why I believe that Java is still taught in this class. People think that teaching kids Java is doing them a favor because they're "giving them a marketable skill" meaning that they will be able to apply to work at Java shops after high school. From my experience they still need a good 2+ semesters with programming before anything they learn is marketable. But developing marketable skills is not really what AP CS is about anyway. All AP classes are really about getting college credit and getting a 5.0 GPA for top colleges. So the skills kids learn there are not being marketed toward companies looking for OOP programmers, they're being marketed toward colleges looking for students. And from our perspective, the perspective of college admissions boards and professors, we don't care about what language they're learning or what "paradigm" they're using whether that's OOP or what have you.
> lack of OOP gets in the way
It floors me that you say a lack of OOP gets in the way, because from my experience it just doesn't. That's completely not what I have found. OOP concepts get in the way far more than anything else. Children just do not organize the world in their brains using class hierarchies (even though that's how their social world is arranged). The original conception of OOP as message passing is far more understandable to children. Like I said my research is still ongoing, but I've gotten middle school children writing more sophisticated asynchronous and parallel code than professional developers with years of experience just through smart language design. When the language gets out of the way and kids are just allowed to think, then they can do pretty amazing stuff. Seymour Papert had kids doing advanced physics with LOGO just by framing the program from the perspective of the turtle.
> what you said isn't worth bashing the language for in general terms.
I don't think I bashed it in general terms (although you won't catch me using it, I'll bash it for other reasons in general terms that are far beyond the scope of teaching children), I am bashing it in the context of teaching children. Sorry if I offended!
By all means, if you think you can come up with a way to teach Java to children that's fun and efficient be my guest. We've been trying for decades and haven't cracked the code, so to speak. A lot of professional developers who have no interactions with children have "thoughts" about teaching programming to children, and when those thoughts meet reality, they often find out its not so easy as just writing a little class wrapper and that's all it's going to take. The abstractions of your template designed to hide all of the complexity are going to leak very quickly, I think you will find.
> Matlab is really not a good example imo because if you start wanting to do a bit more, even if it's just to organize the code in better logical blocks, it bad design and lack of OOP gets in the way and makes further progress slower especially for the more talented students.
I've gotta ask if you've actually taught any students using Matlab (or Java for that matter). By what metric do you say it's a bad design? Are you speaking from the perspective of a professional programmer who uses tools to write professional software? Or are you speaking from the perspective of someone who teaches children regularly and are critiquing its design from that perspective?
Because in my experience Matlab has a great design for teaching. It has a ubiquitous data structure, a table, which can store any kind of datatype without having to specify it. You don't have to know about ints, longs, floats, shorts and chars -- all you need to know are there are numbers, and sometimes strings, but mostly just numbers. And the tables/arrays start at index 1. That's a huge deal for teaching students but programmers hate it. They call starting at 1 bad design, but starting at index 0 is definitely an example of something that gets in the way and makes further progress slower for children. But I've gotta say your statements about "especially for the most talented students" rings especially untrue to me because the most talented students are really never slowed down IMO.
Moreover the REPL interface of Matlab allows them to play with their code as they develop it. JAVA doesn't have a REPL and the write-compile-run loops is too long that students lose interest in the coding and debugging phase. Kids love to pair program with a REPL. They are engaged as the interactivity gives them constant incremental feedback. The write-compile-test loop of Java is long enough that pair programming isn't fun for kids. I'll put it this way: for kids, pair programming in a REPL is like playing a game, pair programming in an IDE has all the fun and excitement of writing a book report. Exploratory programming is a sad story in Java, but it's Matlab's raison d'etre.
> Sure it requires some investment on your side, but your students benefit from being able to start picking up a more marketable skill.
Here's the thing, and this is the big problem with AP CS, and why I believe that Java is still taught in this class. People think that teaching kids Java is doing them a favor because they're "giving them a marketable skill" meaning that they will be able to apply to work at Java shops after high school. From my experience they still need a good 2+ semesters with programming before anything they learn is marketable. But developing marketable skills is not really what AP CS is about anyway. All AP classes are really about getting college credit and getting a 5.0 GPA for top colleges. So the skills kids learn there are not being marketed toward companies looking for OOP programmers, they're being marketed toward colleges looking for students. And from our perspective, the perspective of college admissions boards and professors, we don't care about what language they're learning or what "paradigm" they're using whether that's OOP or what have you.
> lack of OOP gets in the way
It floors me that you say a lack of OOP gets in the way, because from my experience it just doesn't. That's completely not what I have found. OOP concepts get in the way far more than anything else. Children just do not organize the world in their brains using class hierarchies (even though that's how their social world is arranged). The original conception of OOP as message passing is far more understandable to children. Like I said my research is still ongoing, but I've gotten middle school children writing more sophisticated asynchronous and parallel code than professional developers with years of experience just through smart language design. When the language gets out of the way and kids are just allowed to think, then they can do pretty amazing stuff. Seymour Papert had kids doing advanced physics with LOGO just by framing the program from the perspective of the turtle.
> what you said isn't worth bashing the language for in general terms.
I don't think I bashed it in general terms (although you won't catch me using it, I'll bash it for other reasons in general terms that are far beyond the scope of teaching children), I am bashing it in the context of teaching children. Sorry if I offended!
I helped training for programming competitions at junior high to high school levels. I also TAed for CS students at a university level.
Admittedly both of these contexts correlate to more maturity and stronger motivation in the students, especially when CS wasn't so hot.
It's still hard for me to believe there's no way one can make a novice productive with templated Java compared to blank-slate Matlab. It's easy to get people off the ground with dynamic typing, I agree. But novices easily drown in the complexity they create, if they're ever allowed to go far without discipline, at which point it's also harder to grade and help them debug when things go wrong.
Templated exercises also provide more structure and predictability, and allow teachers to do more with the same amount of resources. That said, it wasn't necessarily my intention to advocate for using Java for pedagogy (I'd prefer something that's less verbose and has more novice-friendly I/O and GUI libraries), so I'll stop here.
Admittedly both of these contexts correlate to more maturity and stronger motivation in the students, especially when CS wasn't so hot.
It's still hard for me to believe there's no way one can make a novice productive with templated Java compared to blank-slate Matlab. It's easy to get people off the ground with dynamic typing, I agree. But novices easily drown in the complexity they create, if they're ever allowed to go far without discipline, at which point it's also harder to grade and help them debug when things go wrong.
Templated exercises also provide more structure and predictability, and allow teachers to do more with the same amount of resources. That said, it wasn't necessarily my intention to advocate for using Java for pedagogy (I'd prefer something that's less verbose and has more novice-friendly I/O and GUI libraries), so I'll stop here.
> It's still hard for me to believe there's no way one can make a novice productive with templated Java compared to blank-slate Matlab.
I don't meant to imply you can't make any novices productive with Java, because obviously that's not true. People go from novice to writing Java all the time, and not just a few. But I want more.
My essential point is that while this will work for some people, it's turning off a great deal many more at a time when they are especially impressionable. For example, a student I taught wanted to go to school to be an accountant. But after learning a bit about robots he fell in love with them and now he's going to be building planetary robots next year with the hope of sending them to Mars. Now, I have nothing against accountants, but I'm not trying to make accountants. I want to make programmers, and to do that I need passionate young people willing to give it a try.
There's a huge contingent of students who have fun playing with Logo, Blockly, Scratch et al. and then just nope out when they get to Java. You wouldn't believe how many students tell me they were inspired to code by Logo. Or maybe you would believe it because that's exactly what it was designed to do! But AP CS with Java is a filter, whereas I believe it should be a springboard. These are the students I'm worried about. These are students who were told they are bad at math at a very young age by parents, teachers, media, etc. ("You're not a math person you are a sports person. Or an art person. Or a music person"), so they have very low self esteem when it comes to their potential in this area. Our society is very anti-math, to the point that we create a perception that math isn't even used in every-day life. And maybe that's the root cause of this issue, but I can't solve that one. But I can ameliorate its effects with better language design.
When these students experience Scratch et al., they believe there is a glimmer of hope for them. It doesn't feel like math. It's technical but it's also fun and kind of like a game. And they can get it. They can make programs and games.
Then they get to Java and all they see is math, which they are sure that they're bad at. And it's a huge step backwards for them too, because it takes forever to get them as proficient with Java as they were with Scratch. Going from Scratch to Java is like being blasted back to the stone age for these students.
Programmers looooove the programming as mathematics metaphor. I think a lot of programmers have mathematician envy, and so the programming languages we create for one another drip with the trappings of mathematics.
So I want to reach the students who fell in love with programming early on, have a perception of themselves that they are bad at math, and then are scared away in AP CS. These students are disproportionately girls, not because girls are bad at math but because they are told they are bad at math more than boys. If anyone is here who wants to hire more women but says "I wish we could but they just aren't applying! It's up to the teachers to train more that we can hire!" well this is part of your problem right here.
I don't meant to imply you can't make any novices productive with Java, because obviously that's not true. People go from novice to writing Java all the time, and not just a few. But I want more.
My essential point is that while this will work for some people, it's turning off a great deal many more at a time when they are especially impressionable. For example, a student I taught wanted to go to school to be an accountant. But after learning a bit about robots he fell in love with them and now he's going to be building planetary robots next year with the hope of sending them to Mars. Now, I have nothing against accountants, but I'm not trying to make accountants. I want to make programmers, and to do that I need passionate young people willing to give it a try.
There's a huge contingent of students who have fun playing with Logo, Blockly, Scratch et al. and then just nope out when they get to Java. You wouldn't believe how many students tell me they were inspired to code by Logo. Or maybe you would believe it because that's exactly what it was designed to do! But AP CS with Java is a filter, whereas I believe it should be a springboard. These are the students I'm worried about. These are students who were told they are bad at math at a very young age by parents, teachers, media, etc. ("You're not a math person you are a sports person. Or an art person. Or a music person"), so they have very low self esteem when it comes to their potential in this area. Our society is very anti-math, to the point that we create a perception that math isn't even used in every-day life. And maybe that's the root cause of this issue, but I can't solve that one. But I can ameliorate its effects with better language design.
When these students experience Scratch et al., they believe there is a glimmer of hope for them. It doesn't feel like math. It's technical but it's also fun and kind of like a game. And they can get it. They can make programs and games.
Then they get to Java and all they see is math, which they are sure that they're bad at. And it's a huge step backwards for them too, because it takes forever to get them as proficient with Java as they were with Scratch. Going from Scratch to Java is like being blasted back to the stone age for these students.
Programmers looooove the programming as mathematics metaphor. I think a lot of programmers have mathematician envy, and so the programming languages we create for one another drip with the trappings of mathematics.
So I want to reach the students who fell in love with programming early on, have a perception of themselves that they are bad at math, and then are scared away in AP CS. These students are disproportionately girls, not because girls are bad at math but because they are told they are bad at math more than boys. If anyone is here who wants to hire more women but says "I wish we could but they just aren't applying! It's up to the teachers to train more that we can hire!" well this is part of your problem right here.
Java has a shell by default since forever now. You can start it by issuing jshell of any semi-modern JDK.
Also, are you sure matlab is a good language for learning? I only have experience with learning this language not teaching but to me it was a giant oddball compared to many many languages I have learnt.
Also, are you sure matlab is a good language for learning? I only have experience with learning this language not teaching but to me it was a giant oddball compared to many many languages I have learnt.
> Java has a shell by default since forever now. You can start it by issuing jshell of any semi-modern JDK.
Yes, I'm aware of Jshell. Jshell is what you get when you take a static strongly typed compiled language and you give it an interactive shell. It's not exactly coherent, and still doesn't solve the most salient issues. Using JShell is better than an IDE IMO, but if we're going that direction then why are we still using Java? There are far better interactive languages out there.
> to me it was a giant oddball
It is an oddball language, because most languages are written by developers for developers to do the things developers do. Matlab was written for scientists to do science, and because scientists are not developers, Matlab is designed in a way that is more friendly to them. Sure, learning Matlab is not going to help you in a job interview at an OOP shop, if only just because the interviewers there have an opinion about Matlab being an oddball language (although I've managed to get an interviewer to call in his colleagues to see my one liner Matlab solution to a whiteboard coding question, "We've certainly never gotten that answer before" they said). But the things that make it odd to professional programmers make it more understandable to children, I have found. 1 indexing is the best example. People here will complain about it endlessly, but children will consider it obvious and won't think twice about indexing an array with 1 as the first element.
Here's the difference.
> Also, are you sure matlab is a good language for learning?
I am not sure, that's why I'm doing research on it. But the reason I'm doing research here is because I saw a dramatic result from an experiment, and I want to pull on that thread. The experiment was teaching robotics to middle school students (11-13) using C++ and Matlab. Both groups with little to no computing experience. One was taught C++ in the context of making a robot do a task. The other was taught Matlab. The Matlab group finished the task with ample time to spare, while the C++ had barely gotten past the C++ preliminaries and needed extra time to finish the task. There's got to be something here, it's not like we were trying to make Matlab win. We thought maybe it would have a slight edge but it was just a blowout.
Yes, I'm aware of Jshell. Jshell is what you get when you take a static strongly typed compiled language and you give it an interactive shell. It's not exactly coherent, and still doesn't solve the most salient issues. Using JShell is better than an IDE IMO, but if we're going that direction then why are we still using Java? There are far better interactive languages out there.
> to me it was a giant oddball
It is an oddball language, because most languages are written by developers for developers to do the things developers do. Matlab was written for scientists to do science, and because scientists are not developers, Matlab is designed in a way that is more friendly to them. Sure, learning Matlab is not going to help you in a job interview at an OOP shop, if only just because the interviewers there have an opinion about Matlab being an oddball language (although I've managed to get an interviewer to call in his colleagues to see my one liner Matlab solution to a whiteboard coding question, "We've certainly never gotten that answer before" they said). But the things that make it odd to professional programmers make it more understandable to children, I have found. 1 indexing is the best example. People here will complain about it endlessly, but children will consider it obvious and won't think twice about indexing an array with 1 as the first element.
Here's the difference.
Matlab: To access the first element, do x(1).
Student: okay.
All other languages: To access the first element, do x[0].
Student: Wait, why? Why is the first thing 0? What can't the first thing be 1? That makes no sense whatsoever.
> Also, are you sure matlab is a good language for learning?
I am not sure, that's why I'm doing research on it. But the reason I'm doing research here is because I saw a dramatic result from an experiment, and I want to pull on that thread. The experiment was teaching robotics to middle school students (11-13) using C++ and Matlab. Both groups with little to no computing experience. One was taught C++ in the context of making a robot do a task. The other was taught Matlab. The Matlab group finished the task with ample time to spare, while the C++ had barely gotten past the C++ preliminaries and needed extra time to finish the task. There's got to be something here, it's not like we were trying to make Matlab win. We thought maybe it would have a slight edge but it was just a blowout.
Good luck with your research, but how are you going to discern the difference between high and low level languages? I really do believe that you would have found very similar results for C++/Rust/C vs Python/matlab/java/javascript, etc. given similar quality of third party libraries that the project depends on.
> I really do believe that you would have found very similar results for C++/Rust/C vs Python/matlab/java/javascript
Yes I believe you are on to something here.
> Good luck with your research, but how are you going to discern the difference between high and low level languages?
Thanks! I'll share my findings on HN when I get them, maybe they'll make it to the front page who knows. My research is focused on what features or design elements exactly made Matlab so much more understandable than C++. I think it comes down to
- single data structure that you can put anything in. The table is a very good general structure. Excel echoes this, as people find excel very approachable.
- single numerical type. Everything is basically a float, so you don't have to think about all the numerical nuance involved in choosing between ints, floats, doubles, longs etc.
- 1 indexing, because that's always such a sticking point to brand new programmers
- interactive IDE that allows you to see all of the variables and click into them to see their values. The Matlab REPL isn't great but it's a huge step up from the write-compile-run loop in C++.
Honestly I'd like to try Lua. It has a lot of these properties, so I think it could maybe have good success. But you're right, I'd like to rerun the experiment with all of the languages you listed.
Yes I believe you are on to something here.
> Good luck with your research, but how are you going to discern the difference between high and low level languages?
Thanks! I'll share my findings on HN when I get them, maybe they'll make it to the front page who knows. My research is focused on what features or design elements exactly made Matlab so much more understandable than C++. I think it comes down to
- single data structure that you can put anything in. The table is a very good general structure. Excel echoes this, as people find excel very approachable.
- single numerical type. Everything is basically a float, so you don't have to think about all the numerical nuance involved in choosing between ints, floats, doubles, longs etc.
- 1 indexing, because that's always such a sticking point to brand new programmers
- interactive IDE that allows you to see all of the variables and click into them to see their values. The Matlab REPL isn't great but it's a huge step up from the write-compile-run loop in C++.
Honestly I'd like to try Lua. It has a lot of these properties, so I think it could maybe have good success. But you're right, I'd like to rerun the experiment with all of the languages you listed.
Write LOGO first, or scratch then.
Java is a good intermediate step as a first serious programming language - it has good compile time messages, and even more importantly, it has pretty much full runtime safety, which is absent from python, c, javascript et alia. With these languages students will struggle with code that seem to work, yet are faulty - it is better to fail with an “ugly” but readable exceptions during development, than to not do anything just get wrong results (either type errors, non-intuitive conversions, or straight up memory corruption)
Also, java is a tiny language, I really don’t get your point. Sure, hello world requires 3 lines of boilerplate, but other than that you have pretty much listed every single java feature there is. How many languages’ feature list can you enumerate in a rant?
Java is a good intermediate step as a first serious programming language - it has good compile time messages, and even more importantly, it has pretty much full runtime safety, which is absent from python, c, javascript et alia. With these languages students will struggle with code that seem to work, yet are faulty - it is better to fail with an “ugly” but readable exceptions during development, than to not do anything just get wrong results (either type errors, non-intuitive conversions, or straight up memory corruption)
Also, java is a tiny language, I really don’t get your point. Sure, hello world requires 3 lines of boilerplate, but other than that you have pretty much listed every single java feature there is. How many languages’ feature list can you enumerate in a rant?
> Also, java is a tiny language, I really don’t get your point. Sure, hello world requires 3 lines of boilerplate, but other than that you have pretty much listed every single java feature there is. How many languages’ feature list can you enumerate in a rant?
I wasn't enumerating all of the features of the language, but by saying so you basically proved my point. I was enumerating all of the features of the language present in the very first "Hello World" program. It's not about 3 lines, it's about the density of over a dozen concepts packed into those three lines. That's what people mean when they say to do anything in Java you have to know everything about Java.
> Write LOGO first, or scratch then.
Logo and scratch are great first languages, and they spark joy and imagination in children. Then they move to Java and it sucks the inspiration right out of them. Honestly I think students, teachers, and everyone except Java shops would be better off if students started with Logo turtle graphics in elementary school and used it throughout middle and high school as the capable Lisp that it is. Yes we won't graduate as many object oriented Java programmers, but... well I guess there is no but, I really can't see the downside in what I just said.
I wasn't enumerating all of the features of the language, but by saying so you basically proved my point. I was enumerating all of the features of the language present in the very first "Hello World" program. It's not about 3 lines, it's about the density of over a dozen concepts packed into those three lines. That's what people mean when they say to do anything in Java you have to know everything about Java.
> Write LOGO first, or scratch then.
Logo and scratch are great first languages, and they spark joy and imagination in children. Then they move to Java and it sucks the inspiration right out of them. Honestly I think students, teachers, and everyone except Java shops would be better off if students started with Logo turtle graphics in elementary school and used it throughout middle and high school as the capable Lisp that it is. Yes we won't graduate as many object oriented Java programmers, but... well I guess there is no but, I really can't see the downside in what I just said.
Java ain’t having many more features. Besides primitives, everything is a class with fields and methods. The static keyword decides whether the field/method is per-class or per-instance, and you can create instances with the new keyword. Sure, there is some play here with OOP-features, but java is a really concise language. Feel free to compare it to C#, Python for example. Good luck explaining why an empty list as a default argument is problematic in the latter’s case. Let alone OOP features in Python.
Java, the language is on the order of complexity of C.
Java, the language is on the order of complexity of C.
> Besides primitives, everything is a class with fields and methods. The static keyword decides whether the field/method is per-class or per-instance, and you can create instances with the new keyword.
Are you a professional programmer or a teacher?
The perspective you are sharing with me tells me you're a professional programmer who already understands all of this and finds it obvious and easy. The quoted sentence would be absolute gibberish to students.
> Everything is a fleeb with blips and blops. The slorp rump decides whether the blip/blop is per-fleeb or per-glorm, and you can create glorms with the klob rump.
Simple right? How obvious! You say it as if it's all so easy, but it takes a long time to explain all of these concepts. Students are usually very confused about the difference between a field/variable and object and a class, a function versus a method versus a static method... these concepts are quite nuanced and the differences are subtle to students, yet you are breezing past them like they are nothing or obvious.
> Java is a really concise language.
Concise: giving a lot of information clearly and in a few words. Maybe not clearly, but a lot of information in a few words is accurate. And that's the problem. Kids need a little information followed by a lot of examples and explanation. Giving kids subtle nuanced concepts and expecting them to recognize the depth of those concepts without articulating it is a recipe for disaster.
Are you a professional programmer or a teacher?
The perspective you are sharing with me tells me you're a professional programmer who already understands all of this and finds it obvious and easy. The quoted sentence would be absolute gibberish to students.
> Everything is a fleeb with blips and blops. The slorp rump decides whether the blip/blop is per-fleeb or per-glorm, and you can create glorms with the klob rump.
Simple right? How obvious! You say it as if it's all so easy, but it takes a long time to explain all of these concepts. Students are usually very confused about the difference between a field/variable and object and a class, a function versus a method versus a static method... these concepts are quite nuanced and the differences are subtle to students, yet you are breezing past them like they are nothing or obvious.
> Java is a really concise language.
Concise: giving a lot of information clearly and in a few words. Maybe not clearly, but a lot of information in a few words is accurate. And that's the problem. Kids need a little information followed by a lot of examples and explanation. Giving kids subtle nuanced concepts and expecting them to recognize the depth of those concepts without articulating it is a recipe for disaster.
We switched to Python at my school.
Not sure how I feel about Python (or Java) as a first language. Something a bit lower like C would be a better foundation, IMO.
Not sure how I feel about Python (or Java) as a first language. Something a bit lower like C would be a better foundation, IMO.
Python is definitely simpler to start with but it doesn't expose the beginners to some concepts directly - interfaces are implicit because of duck typing (unless you use the ABC module), everything is public (underscores are just a convention), there is no method overloading etc.
I think it might be more valuable to expose beginners to static typing because it's much easier to transition from "objects have distinct types" to "pretty much everything is just a hashmap" than the other way around.
The thing about C as a first language is that you need to not only learn what programming is but you also need to learn manual memory management which raises the bar significantly and it's pretty easy to write code that fails for reasons which are difficult for a beginner to figure out (like segfaults).
I think it might be more valuable to expose beginners to static typing because it's much easier to transition from "objects have distinct types" to "pretty much everything is just a hashmap" than the other way around.
The thing about C as a first language is that you need to not only learn what programming is but you also need to learn manual memory management which raises the bar significantly and it's pretty easy to write code that fails for reasons which are difficult for a beginner to figure out (like segfaults).
I still have nightmares from back then.
Tell that to Google.
If people are afraid of programming languages, then they should go to the psychologist.
Sounds harsh? Not at all.
Programming languages are a letters on a digital paper, they don't steal and rape people on dark corners, or beat them to death.
Sounds harsh? Not at all.
Programming languages are a letters on a digital paper, they don't steal and rape people on dark corners, or beat them to death.
I feel like it's warranted. The calculus seems to be evaluation of positive impact on the world as a whole versus success of transition/acquisition.
People always love to invent mythic narratives about a golden age that was betrayed by its lesser descendents. It can be the Greeks mythologizing their ancestors, Marxists bemoaning how Stalin betrayed Lenin's legacy, or Java/Solaris partisans hating on Oracle.
The fact that the acquisition cast off a bunch of brilliant, distinguished, charismatic engineers who have every reason to further the mythmaking also plays into why we hear so much of it. But to give credit where it's due, it's given us this esteemable gem of a rant:
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=33m
The fact that the acquisition cast off a bunch of brilliant, distinguished, charismatic engineers who have every reason to further the mythmaking also plays into why we hear so much of it. But to give credit where it's due, it's given us this esteemable gem of a rant:
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=33m
Oh my God that was epic. Ellison as lawnmower is spot on.
I think Java's problems on the desktop started before Oracle. There were issues like the loooooonnnnnggg delay to get the "consumer JRE" out, a few too many high-profile security issues, lack of up-to-date support for various media formats (despite the existence of "JMF", Java struggled a bit in the media world back then. And probably still does). There were also shortcomings with regards to accessing peripherals as I recall, although my memory is admittedly a bit fuzzy on some of that now.
That said, Oracle's legal machinations certainly didn't help matters once they took over.
That said, Oracle's legal machinations certainly didn't help matters once they took over.
The JRE security horrorshow might have started before the Oracle aquisition, and we wanted rid of java on the desktop for the same reason we wanted rid of flash. Apple used to advertise that only Windows suffered from viruses until their own unpatched JRE was exploited widely. Oracle contributed by making updates burdensome to download, and now unavailable without a support agreement, but what stopped java GUI apps from succeeding is at least partly the truly endless stream of remote code execution vulns if the JRE was available to the browser.
I think you might be onto something. MS' C#, which is a near 1:1 copy of Java and what it aims to accomplish, has never suffered the same issues as Java's JRE. You have to wonder if that's because MS gets away with baking CLR updates quietly into Windows whereas JRE updates are more difficult to deploy.
The incentives were always misaligned for a third party framework like Java, even from someone as big as Sun, and now Oracle.
Java was never going to be able to keep up a reasonable native UI binding, because OS vendors were at best ambivalent and at worst actively hostile, because there was nothing in making it work that benefited them.
Security without centralized platform control (e.g. Windows Update, AppStore, Play) was likewise an excercise in futility.
Java was never going to be able to keep up a reasonable native UI binding, because OS vendors were at best ambivalent and at worst actively hostile, because there was nothing in making it work that benefited them.
Security without centralized platform control (e.g. Windows Update, AppStore, Play) was likewise an excercise in futility.
My understanding is that most of security defects in the JRE were related to the browser integration. The core Java sandbox was secure.
Most of the high profile security issues have been either sandbox escapes or serialization issues.
The sandbox escapes were made worse by having applets in the browser.
Now that applets are not a consideration any more the sandbox (SecurityManager) isn't used very much anymore and the Java devs are looking at deprecating and removing it, so most of the sandboxing features will go away.
The sandbox escapes were made worse by having applets in the browser.
Now that applets are not a consideration any more the sandbox (SecurityManager) isn't used very much anymore and the Java devs are looking at deprecating and removing it, so most of the sandboxing features will go away.
I remember when Java applets could prompt the user to accept "all or nothing" permissions and fine grained permissions wasn't supported.
Really it was the Chrome v8 engine paving the way for electron and Single Page Applications.
It's not because of V8.
It's because HTML+CSS (without even any JavaScript) is still the fastest, most effective way to build a compelling and coherent UX/UI for any platform right now.
WPF (nee Avalon) was a contender in the mid-2000s, but for some reason Microsoft put it on ice by 2007 leaving the community stuck with incredibly verbose and bloated XAML markup which only made development more tedious than WinForms, which WPF was slated to replace. Microsoft's effective abandonment of *their own desktop developer story* is what enabled Electron to come along and even prompt Microsoft to use Electron for Skype, Teams, Azure Storage, and VS Code - it's utterly bizzaro-land now: almost as if the Microsoft of the mid-1990s made their own website only work in Netscape.
I was at MSFT from 2012 through 2015, my observation was that the C-suite unintentionally kept OSG (Windows, etc) separate from DevDiv (Visual Studio, WPF, and all those nice cushy libraries), which led to OSG and DevDiv having to recreate each other's work and ending up with complete messes like "XAML Windows Store Apps" which turned into UWP, which no-one is took seriously because it was too limited, while Win32 is still the only real way to use Windows' "real" UI widgets. I can't explain the situation: things were dysfunctional like this long before the great layoff of 2014.
It's because HTML+CSS (without even any JavaScript) is still the fastest, most effective way to build a compelling and coherent UX/UI for any platform right now.
WPF (nee Avalon) was a contender in the mid-2000s, but for some reason Microsoft put it on ice by 2007 leaving the community stuck with incredibly verbose and bloated XAML markup which only made development more tedious than WinForms, which WPF was slated to replace. Microsoft's effective abandonment of *their own desktop developer story* is what enabled Electron to come along and even prompt Microsoft to use Electron for Skype, Teams, Azure Storage, and VS Code - it's utterly bizzaro-land now: almost as if the Microsoft of the mid-1990s made their own website only work in Netscape.
I was at MSFT from 2012 through 2015, my observation was that the C-suite unintentionally kept OSG (Windows, etc) separate from DevDiv (Visual Studio, WPF, and all those nice cushy libraries), which led to OSG and DevDiv having to recreate each other's work and ending up with complete messes like "XAML Windows Store Apps" which turned into UWP, which no-one is took seriously because it was too limited, while Win32 is still the only real way to use Windows' "real" UI widgets. I can't explain the situation: things were dysfunctional like this long before the great layoff of 2014.
> It's because HTML+CSS (without even any JavaScript) is still the fastest, most effective way to build a compelling and coherent UX/UI for any platform right now.
I would agree if you mean cross-platform, but other than for the web specifically, basically every platform has a much better way to create an app for it. The web is seriously so lacking on several trivial fronts that it is laughable, layouting being one example, but just creating a slightly modified version of a native widget like calendar require the recreation of the whole thing with quite bad primitives while goddamn WinForms could deal with it through inheritence.
I would agree if you mean cross-platform, but other than for the web specifically, basically every platform has a much better way to create an app for it. The web is seriously so lacking on several trivial fronts that it is laughable, layouting being one example, but just creating a slightly modified version of a native widget like calendar require the recreation of the whole thing with quite bad primitives while goddamn WinForms could deal with it through inheritence.
> basically every platform has a much better way to create an app for it
I accidentally spent 4 hours writing a reply to your point here and it ended up being too long for HN's comment length limit, but I posted it to pastebin: https://pastebin.com/n6AGB62L
> The web is seriously so lacking on several trivial fronts that it is laughable
That depends on your project's requirements. Speaking from personal experience, my main beef is that HTML web-forms still lacks a loit of widgets necessary for RAD that native UIs have had for decades, like comboboxes, true hierarchical menus, RTF or Markdown text editing (because `contenteditable` is horrible), and so on.
...however, if you're enthused enough it's very possible and quite straightforward now to create your own controls and widgets from scratch, which is what Electron apps like Slack do. Of course, when you do, you're condemned to having to maintain them for eternity, but that's a cost of doing business.
> layouting being one example
Actually I was going to say that's exactly where CSS outshines platforms like WPF, XAML, even Cocoa (not to mention Swing and AWT - I can't speak for JavaFX as I've never used it).
I agree that for most of the past 20 years CSS has been a pain for so many layout issues ("how do I vertically center a div?" is probably the #1 question repeatedly asked on StackOverflow), but CSS's flexbox and CSS grid have been supported by all major browsers for almost a decade now and I can confidently say that I can build an aesthetic design with a layout that adapts to changing window/screen dimensions and aspect-ratios in a fraction of the time it would take me to do in any native framework.
Consider that 1990s-era frameworks like VB6, WinForms, etc were all fixed-layout and required you to write your own repositioning logic in resize-event-handlers. WinForms didn't get anchored-layout until 2005! Post-2000s frameworks like Swing and WPF added layout containers, but they're far from perfect and don't support radical re-layouting. More modern frameworks that use constraint-based layout or support major relayouting (like SwiftUI and WinUI 3, to an extent) are appealing, but I find offer few real advantages over CSS's layout model.
A major personal win for CSS is the content/behaviour/presentation separation (<div>-itis, not withstanding). Compared to WPF where a single XAML file will mix content, behaviour, and presentation elements, attributes, and controls without any regard for separation-of-concerns or maintainability (WPF does have CSS-esque Styles, but despite the name suggesting they're strictly presentational they're not: they're invariably used to control behaviour (due to XAML's ugly and unusable template and trigger ceremony) and also content (due to how content-based templates are used).
> while goddamn WinForms could deal with it through inheritence.
But that's where the failures of inheritance becomes obvious: consider WinForm's own Checkbox control. Surprisingly, the Checkbox is actually a subclass of Button, and shares no relationship with the intuitively similar Radio control despite their very similar visual appearance and behaviour. WinForms' design (like most other OOP-based frameworks) shoehorn both UX behaviour and visual appearance into a single OOP inheritance tree. This only works up-to-a-point, then things quickly fall-apart.
I accidentally spent 4 hours writing a reply to your point here and it ended up being too long for HN's comment length limit, but I posted it to pastebin: https://pastebin.com/n6AGB62L
> The web is seriously so lacking on several trivial fronts that it is laughable
That depends on your project's requirements. Speaking from personal experience, my main beef is that HTML web-forms still lacks a loit of widgets necessary for RAD that native UIs have had for decades, like comboboxes, true hierarchical menus, RTF or Markdown text editing (because `contenteditable` is horrible), and so on.
...however, if you're enthused enough it's very possible and quite straightforward now to create your own controls and widgets from scratch, which is what Electron apps like Slack do. Of course, when you do, you're condemned to having to maintain them for eternity, but that's a cost of doing business.
> layouting being one example
Actually I was going to say that's exactly where CSS outshines platforms like WPF, XAML, even Cocoa (not to mention Swing and AWT - I can't speak for JavaFX as I've never used it).
I agree that for most of the past 20 years CSS has been a pain for so many layout issues ("how do I vertically center a div?" is probably the #1 question repeatedly asked on StackOverflow), but CSS's flexbox and CSS grid have been supported by all major browsers for almost a decade now and I can confidently say that I can build an aesthetic design with a layout that adapts to changing window/screen dimensions and aspect-ratios in a fraction of the time it would take me to do in any native framework.
Consider that 1990s-era frameworks like VB6, WinForms, etc were all fixed-layout and required you to write your own repositioning logic in resize-event-handlers. WinForms didn't get anchored-layout until 2005! Post-2000s frameworks like Swing and WPF added layout containers, but they're far from perfect and don't support radical re-layouting. More modern frameworks that use constraint-based layout or support major relayouting (like SwiftUI and WinUI 3, to an extent) are appealing, but I find offer few real advantages over CSS's layout model.
A major personal win for CSS is the content/behaviour/presentation separation (<div>-itis, not withstanding). Compared to WPF where a single XAML file will mix content, behaviour, and presentation elements, attributes, and controls without any regard for separation-of-concerns or maintainability (WPF does have CSS-esque Styles, but despite the name suggesting they're strictly presentational they're not: they're invariably used to control behaviour (due to XAML's ugly and unusable template and trigger ceremony) and also content (due to how content-based templates are used).
> while goddamn WinForms could deal with it through inheritence.
But that's where the failures of inheritance becomes obvious: consider WinForm's own Checkbox control. Surprisingly, the Checkbox is actually a subclass of Button, and shares no relationship with the intuitively similar Radio control despite their very similar visual appearance and behaviour. WinForms' design (like most other OOP-based frameworks) shoehorn both UX behaviour and visual appearance into a single OOP inheritance tree. This only works up-to-a-point, then things quickly fall-apart.
Thanks for the long and very informative answer! I recommend actually posting your full comment, so that it becomes longer-lived.
And I have to agree on the CSS part, I mostly meant the older times without flexbox et alia. Perhaps it is generally true of web technologies but they seem to have fixed many of their numerous mistakes in recent years (JS being quite okay as well nowadays).
And I have to agree on the CSS part, I mostly meant the older times without flexbox et alia. Perhaps it is generally true of web technologies but they seem to have fixed many of their numerous mistakes in recent years (JS being quite okay as well nowadays).
(This reply is PART 4 of 4, you'll need to scroll way down for Part 1)
Anyway, flash-forward a half-decade and Microsoft finally had some sense knocked into them and started to open-up UWP (or rather: export the nice(r) parts of UWP to the Win32 world, outside of the sandbox). There was more confusion (and popped blood-vessles) when "Windows UI Library 2" dropped. Fortunately no-one ever used it. "WinUI 3" is now meant to be the future: it's a XAML-based UI framework that can be used by native code, without the UWP sandbox - the only thing holding it back (imo) is the lack of many essential controls and widgets in the in-box library: it's still missing a data-grid, for example. The other major issue is that XAML is definitely not a RAD platform: XAML is still excessively verbose, wiring-up control events directly to event-handler functions is discouraged (as markup-based databinding is far superior in most cases), but XAML's data-binding system doesn't scale and relies on mutable viewmodel classes, side-effects, reentrancy, event-broadcasting, and other things that make people used to Redux/React's unidirectional flow of data scream and bash their head against the wall, just because XAML data-binding really is so backward.
So here we are, in 2022 - if you want to make a "native" GUI desktop app for Windows 10 then your options are:
* Win32/USER32/ComCtrl: too low-level to be practical for building applications today. VisualC++ comes with MFC, but that's like giving a glass of water to someone in hell.
* WinForms: poorly-disguised wrapper over GDI, USER32 and ComCtl32. Microsoft would prefer you pretended it didn't exist. The only thing going for it is that it's currently (still) the only way to do RAD desktop UI development.
* WPF: only suitable for greenfield programs built on .NET. Stock controls have been neglected since Windows 8 and have lost their sophisticated visual aesthetic from Windows 7 and are now hideous (solid grey buttons? not even inset borders?!), fortunately theme/resources like MahApps.Metro make WPF apps a pleasure to use again. WPF still remains the best option for building maintainable line-of-business applications, but I recommend avoiding two-way data-binding to your viewmodel: try to be at close to the Redux-pattern as possible. And here's to hoping there's a migration path to WinUI when it reaches feature-parity, especially w.r.t. datagrids, etc.
* Sandboxed UWP: ahahahah, no.
* WinUI 3+: Looks promising, but despite being available for a couple of years now, at least WinUI has the dignity of actually being used by some of Microsoft's own software unlike WPF and UWP (mostly things already built-in to Windows, like the Calculator app since Windows 11).
* Honorable mention HTA: HTAs (Hypertext Applications) were added to Windows 98: basically it was using MSHTML (Internet Explorer) to render the UI, with the DOM being fully scriptable with JS or VBScript and could interact with the rest of an application via COM. Basically exactly what Electron is today but 25 years ago (and without any sandboxing... erk!). This was a surprisingly well-designed and implemented platform option in Windows, and even used by many of Microsoft's own software - but Microsoft didn't really advertise it, and when Internet Explorer 11 came out it basically broke HTAs for good (HTAs used IE7 compatibility mode, if you wanted to use IE11 mode then it would break HTA-exclusive features like Win32/COM integration).
* So given those are today's options, it's no surprise that today's generation of developers, who invariably cut-their-teeth learning HTML and CSS as kids, instead of on VBA/VB6 Forms, are increasingly looking at Electron - especially if they want any kind of custom UI or branded themeing, even if they don't want cross-platform compatibility. Even with XAML-based WinUI 3, it's still absurdly difficult to do things that deviate from the stock themes, especially fonts/typefaces, colors/themes, etc.
[1] Technically, Windows 98 and Windows 2000 (which were completely separate OS codebases) did have built-in support for a very limited form of window compositioning named "layered windows"[3], which supported top-level alpha-blending effects and complex window shapes (While Windows 95 did support non-rectangular top-level windows it was only with indexed transparency without antialiasing) however opting-in to a layered hWnd required the user to have ample VRAM (for double-buffered windows) and a highly-capable 2D graphics chipset (for fast alpha-blending), and if you wanted per-pixel alpha-blending then your UI thread's performance sank like a stone - oh, and you had to use GDI too. Ultimately I think this was only used for UI gimmicks for desktop apps like Trillian which would turn semi-transparent when on-focused.
[2] Llate-1990s PC gamers will remember that running 3D games in a window (as opposed to in exclusive-mode) was awful for performance due to all the excessive frame blitting, I think XP did mitigate it somewhat, but I'm unsure how.
[3] https://docs.microsoft.com/en-us/windows/win32/winmsg/window...
[4] Win32's window/hWnd subclassing doesn't literally mean using an OOP language like C++ to subclass some class representing a USER32 widget or ComCtl button (as that's meaningless: C++-style classes don't exist in natively compiled programs), what it refers to is described here ( https://docs.microsoft.com/en-us/windows/win32/controls/subc... ) - and it's when an application, at runtime, creates a new Win32 hWnd or instantiates a widget like a button or checkbox, and uses owner-level overrides of certain OS-level window-messages, such as painting or how it responds to mouse and keyboard input - so it's more akin to message-passing OOP (i.e. Smalltalk-style OOP) than C++-style OOP.
[5] Consider this (somewhat contrived) scenario: an application that subclasses a Win32 button control hWnd class so that the button will now respond to a middle-mouse-button-click the same way as a left-button-click. This would be implemented by Things work fine until the next OS release where Microsoft suddenly decides that middle-clicking all Win32/USER32/ComCtl32 buttons will start a cheesy fireworks display on the user's desktop wallpaper.
[6] https://en.wikipedia.org/wiki/Referential_transparency
Anyway, flash-forward a half-decade and Microsoft finally had some sense knocked into them and started to open-up UWP (or rather: export the nice(r) parts of UWP to the Win32 world, outside of the sandbox). There was more confusion (and popped blood-vessles) when "Windows UI Library 2" dropped. Fortunately no-one ever used it. "WinUI 3" is now meant to be the future: it's a XAML-based UI framework that can be used by native code, without the UWP sandbox - the only thing holding it back (imo) is the lack of many essential controls and widgets in the in-box library: it's still missing a data-grid, for example. The other major issue is that XAML is definitely not a RAD platform: XAML is still excessively verbose, wiring-up control events directly to event-handler functions is discouraged (as markup-based databinding is far superior in most cases), but XAML's data-binding system doesn't scale and relies on mutable viewmodel classes, side-effects, reentrancy, event-broadcasting, and other things that make people used to Redux/React's unidirectional flow of data scream and bash their head against the wall, just because XAML data-binding really is so backward.
So here we are, in 2022 - if you want to make a "native" GUI desktop app for Windows 10 then your options are:
* Win32/USER32/ComCtrl: too low-level to be practical for building applications today. VisualC++ comes with MFC, but that's like giving a glass of water to someone in hell.
* WinForms: poorly-disguised wrapper over GDI, USER32 and ComCtl32. Microsoft would prefer you pretended it didn't exist. The only thing going for it is that it's currently (still) the only way to do RAD desktop UI development.
* WPF: only suitable for greenfield programs built on .NET. Stock controls have been neglected since Windows 8 and have lost their sophisticated visual aesthetic from Windows 7 and are now hideous (solid grey buttons? not even inset borders?!), fortunately theme/resources like MahApps.Metro make WPF apps a pleasure to use again. WPF still remains the best option for building maintainable line-of-business applications, but I recommend avoiding two-way data-binding to your viewmodel: try to be at close to the Redux-pattern as possible. And here's to hoping there's a migration path to WinUI when it reaches feature-parity, especially w.r.t. datagrids, etc.
* Sandboxed UWP: ahahahah, no.
* WinUI 3+: Looks promising, but despite being available for a couple of years now, at least WinUI has the dignity of actually being used by some of Microsoft's own software unlike WPF and UWP (mostly things already built-in to Windows, like the Calculator app since Windows 11).
* Honorable mention HTA: HTAs (Hypertext Applications) were added to Windows 98: basically it was using MSHTML (Internet Explorer) to render the UI, with the DOM being fully scriptable with JS or VBScript and could interact with the rest of an application via COM. Basically exactly what Electron is today but 25 years ago (and without any sandboxing... erk!). This was a surprisingly well-designed and implemented platform option in Windows, and even used by many of Microsoft's own software - but Microsoft didn't really advertise it, and when Internet Explorer 11 came out it basically broke HTAs for good (HTAs used IE7 compatibility mode, if you wanted to use IE11 mode then it would break HTA-exclusive features like Win32/COM integration).
* So given those are today's options, it's no surprise that today's generation of developers, who invariably cut-their-teeth learning HTML and CSS as kids, instead of on VBA/VB6 Forms, are increasingly looking at Electron - especially if they want any kind of custom UI or branded themeing, even if they don't want cross-platform compatibility. Even with XAML-based WinUI 3, it's still absurdly difficult to do things that deviate from the stock themes, especially fonts/typefaces, colors/themes, etc.
[1] Technically, Windows 98 and Windows 2000 (which were completely separate OS codebases) did have built-in support for a very limited form of window compositioning named "layered windows"[3], which supported top-level alpha-blending effects and complex window shapes (While Windows 95 did support non-rectangular top-level windows it was only with indexed transparency without antialiasing) however opting-in to a layered hWnd required the user to have ample VRAM (for double-buffered windows) and a highly-capable 2D graphics chipset (for fast alpha-blending), and if you wanted per-pixel alpha-blending then your UI thread's performance sank like a stone - oh, and you had to use GDI too. Ultimately I think this was only used for UI gimmicks for desktop apps like Trillian which would turn semi-transparent when on-focused.
[2] Llate-1990s PC gamers will remember that running 3D games in a window (as opposed to in exclusive-mode) was awful for performance due to all the excessive frame blitting, I think XP did mitigate it somewhat, but I'm unsure how.
[3] https://docs.microsoft.com/en-us/windows/win32/winmsg/window...
[4] Win32's window/hWnd subclassing doesn't literally mean using an OOP language like C++ to subclass some class representing a USER32 widget or ComCtl button (as that's meaningless: C++-style classes don't exist in natively compiled programs), what it refers to is described here ( https://docs.microsoft.com/en-us/windows/win32/controls/subc... ) - and it's when an application, at runtime, creates a new Win32 hWnd or instantiates a widget like a button or checkbox, and uses owner-level overrides of certain OS-level window-messages, such as painting or how it responds to mouse and keyboard input - so it's more akin to message-passing OOP (i.e. Smalltalk-style OOP) than C++-style OOP.
[5] Consider this (somewhat contrived) scenario: an application that subclasses a Win32 button control hWnd class so that the button will now respond to a middle-mouse-button-click the same way as a left-button-click. This would be implemented by Things work fine until the next OS release where Microsoft suddenly decides that middle-clicking all Win32/USER32/ComCtl32 buttons will start a cheesy fireworks display on the user's desktop wallpaper.
[6] https://en.wikipedia.org/wiki/Referential_transparency
(PART 3):
What I've written so far makes it sound like WPF should have saved the Windows desktop app development story and everything from Microsoft since then should have been based on WPF - but here we are, almost 20 years later, and Microsoft Office doesn't use WPF, very few in-box components in Windows use WPF, in fact, other than Visual Studio, I honestly cannot think of any WPF-based applications I use on a daily basis. So why isn't WPF being used if it's so great?
...it's because WPF could only be used if an application used the .NET Framework - and the .NET Framework for-all-intents-and-purposes is just "Microsoft's Java": if your a company like Adobe, Macromedia, Autodesk, a web-browser vendor like Netscape or Mozilla, or even Microsoft's own Office division, then you've got millions, perhaps billions, of dollars invested in your existing native C/C++/Ada/Delphi/etc applications that use Win32 and GDI directly. If you want your application to use WPF for its desktop GUI then you'll need to find a way to host the .NET CLR in-process and then start to rebuild your entire UI in WPF XAML. A small blessing is that WPF can co-exist in the same top-level window as other native/Win32 widgets (this is what Autodesk did when they added a tabbed-ribbon UI to 3ds Max: the ribbon was a WPF control while the rest of the UI was their existing UI). So in short, Microsoft was asking these independent software vendors, the same vendors Microsoft ultimately depends upon to legitimize the Windows desktop platform, to take a huge bet on the viability of WPF - and the .NET Framework - and to take-on both WPF and .NET as additional external dependencies with their own releases and versioning that were (and still are) completely separate from Windows OS releases (as .NET and WPF are "owned" by a completely separate division in Microsoft than the Windows org: the separation goes right-up to the highest level: there is no-one at Microsoft with the job-responsibility of ensuring that WPF and Windows stay coordinates - which explains a lot).
Secondarily: those companies above that I mentioned, like Adobe and Autodesk, have another huge reason to be reluctant to use WPF as the entire basis for their desktop app GUIs: industrial-grade tools like Photoshop and 3ds absolutely need high-performance, low-level access to the computer's GPU - but WPF only gets in the way. While you can do things like offscreen rendering and blit those surfaces into your WPF UI, that adds at least 1 frame of latency, even more with how the DWM works. Also, remember how I said there's no-one at Microsoft ultimately responsible for maintaining cohesion between WPF/Windows? That became a problem when WPF was effectively frozen around 2010 and stuck on DirectX 9 which means it's impractical to run any modern Direct3D code from the past 10 years in the same process as a WPF GUI. It's 2022, and WPF (even on .NET 6) is still stuck on Direct3D 9. It's insane: this is is holding back the platform and has irreparably damaged the Windows desktop developer story.
The end result today is that WPF is a very compelling UI framework for internal and line-of-business applications that now absolutely depend on the ability to embed treeviews inside datagrids inside other treeviews, it's still a huge blinking red no-go-area for major software vendors, legacy non-.NET codebases, and those needing to low-level hardware access for their top-level windows (e.g. deep-color in Photoshop).
Microsoft did add a largely unnoticed (but now utterly essential, IMO) feature in Windows 8 which improved on Longhorn/Vista's GDI-free top-level hWnds: WS_EX_NOREDIRECTIONBITMAP. Finally, any application (or, more likely: UI frameworks) can now have top-level windows with blazing fast performance, deep-color, and more without double-buffering in the DWM that (I understand) can even be used from OpenGL just as well as Direct3D... but Windows doesn't come with any UI framework or widget-library for it, much less anything like RAD tooling for it. At least this gives companies like Adobe and Autodesk an escape-hatch for Photoshop and AutoCAD, and it should be possible for them to port their own proprietary existing UI/widget libs over to it it's just another render target.
But while Windows 8 helped, it's also where things really went-off-the-rails: WPF had been frozen for at least a half-decade at this point and Microsoft was trying (and failing) to turn Windows into a touch-friendly OS experience to compete with Apple's iPad, which I honestly believe Microsoft saw as an major, if not existential threat (if it weren't for Apple keeping iPad OS dumbed-down, with siloed applications and continuing to make it unsuitable for true multitasking, then any iPad with a keyboard would likely suit 90% of the needs of 80% of existing (non-business) Windows PC users). As part of this strategy, Microsoft had this obsession with thinking having their own Apple-style App Store for Windows, which would only sell extremely restricted sandboxed applications was necessary to compete - rather than treating Windows' open-platform nature as an advantage. So Microsoft created a new platform-within-a-platform named "Universal Windows Platform" (UWP) which was a Frankenstein's monster comprised of a new, tightly-restricted and sandboxed execution-environment (which at least supported native x86/x64/ARM rather than being yet another .NET port), a COM-based platform API, and a WPF-derived XAML UI framework that didn't even have its own name). While this platform, including the XAML UI framework, no-longer required the use of .NET to work (hurrah!) it did require applications to be recompiled with a special C runtime lib (due to the sandboxing) and all UWP platform API calls had to go through Visual C++ language extensions named "C++/CX", so you were SOL if you were a gcc or Clang user. While the sandboxing made UWP an instant deal-killer for any "real" software (excepting yet another Netflix app), there was strong developer interest in getting to use UWP's new XAML-based UI framework (internally named "Jupiter") outside of the sandbox: by classic Win32 desktop software badly in need of a facelift. Inexplicably, Microsoft disregarded that interest and kept Jupiter only accessible to sandboxed applications and instead ploughed resources into the rest of the sandboxed UWP platform for the sake of the not-dead-yet Windows Phone platform. Even if a developer was willing to rework their application for UWP's sandbox to get to use Jupiter, the built-in widget/control library was still very anemic: all of the widgets and controls were clearly touch-first, mouse-second, keyboard-third (i.e. big and chunky, suited to only a 10-foot-UI or touch device experience) and clearly inappropriate for traditional desktop use-cases or anywhere when information-density is essential: anyone using UWP/Jupiter for those kinds of applications would need to invest in a third-party control library, or build their own. UWP/Jupiter still didn't come with any kind of data-grid control at this point, even though it should have been very straightforward to port it over from WPF, which shows you exactly where Microsoft's priorities lay.
What I've written so far makes it sound like WPF should have saved the Windows desktop app development story and everything from Microsoft since then should have been based on WPF - but here we are, almost 20 years later, and Microsoft Office doesn't use WPF, very few in-box components in Windows use WPF, in fact, other than Visual Studio, I honestly cannot think of any WPF-based applications I use on a daily basis. So why isn't WPF being used if it's so great?
...it's because WPF could only be used if an application used the .NET Framework - and the .NET Framework for-all-intents-and-purposes is just "Microsoft's Java": if your a company like Adobe, Macromedia, Autodesk, a web-browser vendor like Netscape or Mozilla, or even Microsoft's own Office division, then you've got millions, perhaps billions, of dollars invested in your existing native C/C++/Ada/Delphi/etc applications that use Win32 and GDI directly. If you want your application to use WPF for its desktop GUI then you'll need to find a way to host the .NET CLR in-process and then start to rebuild your entire UI in WPF XAML. A small blessing is that WPF can co-exist in the same top-level window as other native/Win32 widgets (this is what Autodesk did when they added a tabbed-ribbon UI to 3ds Max: the ribbon was a WPF control while the rest of the UI was their existing UI). So in short, Microsoft was asking these independent software vendors, the same vendors Microsoft ultimately depends upon to legitimize the Windows desktop platform, to take a huge bet on the viability of WPF - and the .NET Framework - and to take-on both WPF and .NET as additional external dependencies with their own releases and versioning that were (and still are) completely separate from Windows OS releases (as .NET and WPF are "owned" by a completely separate division in Microsoft than the Windows org: the separation goes right-up to the highest level: there is no-one at Microsoft with the job-responsibility of ensuring that WPF and Windows stay coordinates - which explains a lot).
Secondarily: those companies above that I mentioned, like Adobe and Autodesk, have another huge reason to be reluctant to use WPF as the entire basis for their desktop app GUIs: industrial-grade tools like Photoshop and 3ds absolutely need high-performance, low-level access to the computer's GPU - but WPF only gets in the way. While you can do things like offscreen rendering and blit those surfaces into your WPF UI, that adds at least 1 frame of latency, even more with how the DWM works. Also, remember how I said there's no-one at Microsoft ultimately responsible for maintaining cohesion between WPF/Windows? That became a problem when WPF was effectively frozen around 2010 and stuck on DirectX 9 which means it's impractical to run any modern Direct3D code from the past 10 years in the same process as a WPF GUI. It's 2022, and WPF (even on .NET 6) is still stuck on Direct3D 9. It's insane: this is is holding back the platform and has irreparably damaged the Windows desktop developer story.
The end result today is that WPF is a very compelling UI framework for internal and line-of-business applications that now absolutely depend on the ability to embed treeviews inside datagrids inside other treeviews, it's still a huge blinking red no-go-area for major software vendors, legacy non-.NET codebases, and those needing to low-level hardware access for their top-level windows (e.g. deep-color in Photoshop).
Microsoft did add a largely unnoticed (but now utterly essential, IMO) feature in Windows 8 which improved on Longhorn/Vista's GDI-free top-level hWnds: WS_EX_NOREDIRECTIONBITMAP. Finally, any application (or, more likely: UI frameworks) can now have top-level windows with blazing fast performance, deep-color, and more without double-buffering in the DWM that (I understand) can even be used from OpenGL just as well as Direct3D... but Windows doesn't come with any UI framework or widget-library for it, much less anything like RAD tooling for it. At least this gives companies like Adobe and Autodesk an escape-hatch for Photoshop and AutoCAD, and it should be possible for them to port their own proprietary existing UI/widget libs over to it it's just another render target.
But while Windows 8 helped, it's also where things really went-off-the-rails: WPF had been frozen for at least a half-decade at this point and Microsoft was trying (and failing) to turn Windows into a touch-friendly OS experience to compete with Apple's iPad, which I honestly believe Microsoft saw as an major, if not existential threat (if it weren't for Apple keeping iPad OS dumbed-down, with siloed applications and continuing to make it unsuitable for true multitasking, then any iPad with a keyboard would likely suit 90% of the needs of 80% of existing (non-business) Windows PC users). As part of this strategy, Microsoft had this obsession with thinking having their own Apple-style App Store for Windows, which would only sell extremely restricted sandboxed applications was necessary to compete - rather than treating Windows' open-platform nature as an advantage. So Microsoft created a new platform-within-a-platform named "Universal Windows Platform" (UWP) which was a Frankenstein's monster comprised of a new, tightly-restricted and sandboxed execution-environment (which at least supported native x86/x64/ARM rather than being yet another .NET port), a COM-based platform API, and a WPF-derived XAML UI framework that didn't even have its own name). While this platform, including the XAML UI framework, no-longer required the use of .NET to work (hurrah!) it did require applications to be recompiled with a special C runtime lib (due to the sandboxing) and all UWP platform API calls had to go through Visual C++ language extensions named "C++/CX", so you were SOL if you were a gcc or Clang user. While the sandboxing made UWP an instant deal-killer for any "real" software (excepting yet another Netflix app), there was strong developer interest in getting to use UWP's new XAML-based UI framework (internally named "Jupiter") outside of the sandbox: by classic Win32 desktop software badly in need of a facelift. Inexplicably, Microsoft disregarded that interest and kept Jupiter only accessible to sandboxed applications and instead ploughed resources into the rest of the sandboxed UWP platform for the sake of the not-dead-yet Windows Phone platform. Even if a developer was willing to rework their application for UWP's sandbox to get to use Jupiter, the built-in widget/control library was still very anemic: all of the widgets and controls were clearly touch-first, mouse-second, keyboard-third (i.e. big and chunky, suited to only a 10-foot-UI or touch device experience) and clearly inappropriate for traditional desktop use-cases or anywhere when information-density is essential: anyone using UWP/Jupiter for those kinds of applications would need to invest in a third-party control library, or build their own. UWP/Jupiter still didn't come with any kind of data-grid control at this point, even though it should have been very straightforward to port it over from WPF, which shows you exactly where Microsoft's priorities lay.
(PART 2):
...so WPF is (was) completely unlike almost all previous (invariably OOP-inspired) UI frameworks. For context: previously, Win32 applications would create a top-level hWnd and populate it with composed child hWnd-based widgets and let USER32 handle the actual painting via GDI. This has a nice 1:1 conceptual mapping to how Smalltalk-style message-passing OOP is meant to work: objects (controls) are composed by some parent/container object and all these objects exchange messages between themselves to direct their behaviour. OS-level messages are received by the parent window object and passed-down hierarchically to child controls, which works nicely for things like painting and input processing... except when it doesn't: while tight-integration with an OS's widgets and window-manager means applications get lots of features "for free", especially with OS version updates (e.g. built-in spellcheck in normal textboxes, animated buttons, applications' visual appearance automatically matches each OS releases' distinctive UI theme, etc), but it also means that applications should avoid subclassing[4] Win32 controls to avoid things breaking in future OS updates[5] - or depend on the OS providing an older version of the widget for compatibility's sake and miss-out on any new, cool, exciting (or godforbid: actually useful) new features. Thus, OOP hell meets binary library versioning hell. Today's kids with their NPM doohickeys dependency hell and padleft nonsense don't realize how nice they have it compared to native GUI developers.
...so WPF is different: while WPF still uses Win32 hWnds for the top-level window with its titlebar etc), WPF completely opts-out of having Windows manage child hWnds for things like buttons, checkboxes, and the like. WPF's widgets can still be composed by a container or parent, but WPF's design discourages control subclassing (or at least, it eliminates the necessity for subclassing in order to extend or subtly modify binary/library controls and widgets) - so far, this doesn't sound too different to other GUI frameworks that also do-their-own layout and painting of child widgets (like Java's Swing), but the biggest, most fundamental difference in WPF is that the actual layout and appearance of a control/widget (i.e. its painting) is no-longer performed by a natively-compiled machine-code painting function making use of GDI or some other 2D drawing API: instead all controls/widgets everything has its appearance defined in XAML, and when a WPF control/widget library is compiled (be it an end-user application, a redistributable library, or WPF (or OS-provided) default control library) the XAML is still available at runtime. This is what makes WPF far, far, far more flexible and extensible than anything else before. And this was all designed in the early 2000s, long before CSS could even be used for web-page-layout or when HTML+DOM gained "web components".
The 1990s way, of composed widgets/objects with subclassing, is OOP in a nutshell. In general programming we've seen OOP's limitations and the FP paradigm is now in-vogue, but FP depends on referential-transparency[6] (for things like function composition, not least for adequate runtime performance) - so if WPF can be compared to FP, it's that WPF's always-exported, always-reified, XAML is the GUI framework equivalent of referential-transparency. This is what allows applications to do previously-impossible things, like embed arbitrary controls inside a datagrid cells (e.g. checkboxes, picture boxes, numeric spinners, etc), whereas previously applications would depend on the datagrid control specifically supporting each of those input types, or resort to tedious hacks like owner-painting which would invariably break when updating dependencies.
...so WPF is (was) completely unlike almost all previous (invariably OOP-inspired) UI frameworks. For context: previously, Win32 applications would create a top-level hWnd and populate it with composed child hWnd-based widgets and let USER32 handle the actual painting via GDI. This has a nice 1:1 conceptual mapping to how Smalltalk-style message-passing OOP is meant to work: objects (controls) are composed by some parent/container object and all these objects exchange messages between themselves to direct their behaviour. OS-level messages are received by the parent window object and passed-down hierarchically to child controls, which works nicely for things like painting and input processing... except when it doesn't: while tight-integration with an OS's widgets and window-manager means applications get lots of features "for free", especially with OS version updates (e.g. built-in spellcheck in normal textboxes, animated buttons, applications' visual appearance automatically matches each OS releases' distinctive UI theme, etc), but it also means that applications should avoid subclassing[4] Win32 controls to avoid things breaking in future OS updates[5] - or depend on the OS providing an older version of the widget for compatibility's sake and miss-out on any new, cool, exciting (or godforbid: actually useful) new features. Thus, OOP hell meets binary library versioning hell. Today's kids with their NPM doohickeys dependency hell and padleft nonsense don't realize how nice they have it compared to native GUI developers.
...so WPF is different: while WPF still uses Win32 hWnds for the top-level window with its titlebar etc), WPF completely opts-out of having Windows manage child hWnds for things like buttons, checkboxes, and the like. WPF's widgets can still be composed by a container or parent, but WPF's design discourages control subclassing (or at least, it eliminates the necessity for subclassing in order to extend or subtly modify binary/library controls and widgets) - so far, this doesn't sound too different to other GUI frameworks that also do-their-own layout and painting of child widgets (like Java's Swing), but the biggest, most fundamental difference in WPF is that the actual layout and appearance of a control/widget (i.e. its painting) is no-longer performed by a natively-compiled machine-code painting function making use of GDI or some other 2D drawing API: instead all controls/widgets everything has its appearance defined in XAML, and when a WPF control/widget library is compiled (be it an end-user application, a redistributable library, or WPF (or OS-provided) default control library) the XAML is still available at runtime. This is what makes WPF far, far, far more flexible and extensible than anything else before. And this was all designed in the early 2000s, long before CSS could even be used for web-page-layout or when HTML+DOM gained "web components".
The 1990s way, of composed widgets/objects with subclassing, is OOP in a nutshell. In general programming we've seen OOP's limitations and the FP paradigm is now in-vogue, but FP depends on referential-transparency[6] (for things like function composition, not least for adequate runtime performance) - so if WPF can be compared to FP, it's that WPF's always-exported, always-reified, XAML is the GUI framework equivalent of referential-transparency. This is what allows applications to do previously-impossible things, like embed arbitrary controls inside a datagrid cells (e.g. checkboxes, picture boxes, numeric spinners, etc), whereas previously applications would depend on the datagrid control specifically supporting each of those input types, or resort to tedious hacks like owner-painting which would invariably break when updating dependencies.
> I recommend actually posting your full comment, so that it becomes longer-lived.
Alright, here goes...
PART 1:
> basically every platform has a much better way to create an app for it
Yes and no.
On macOS and iOS, using Apple's first-party, in-box UI frameworks/libraries like Cocoa, Cocoa Touch, SwiftUI is the best, and only, way to make a lovable user-experience on macOS and iOS. The downside is that if your application needs some ultra-specific widget that Apple hasn't already made in Cocoa then you've got a lot of legwork to do, especially w.r.t. painting in your NSView subclass. Despite Cocoa's very modern and sophisticated aesthetics, it's still fundamentally a very 1990s OOP widget library based around composing and subclassing opaque view objects.
On Linux (and in ancient-times: UNIX environments like CDE): the native desktop app UX story has always been a hot-mess simply due to UNIX specs like POSIX not getting involved in the GUI side, and despite some OS vendors trying to be consistent (rip SGI) the widget/library vendors never had any incentive for consistency. While GTK is considered Linux's "default" widget set today, there are still other equally-native but entirely separate widget toolkits (Motif, Xaw, etc) that developers are free to use - so there is no one true way to build a native GUI for Linux today, or at least, not one readily suitable for 1990s-style RAD, in my experience.
On Windows... well, that's where Microsoft has somehow taken Windows from being its (imo) Windows XP heydays: a platform with a (relatively nice) coherent and single widget set (i.e. USER32 and ComCtl32) - with occasional third-party libs like Delphi's VCL. (Other things, like MFC, ActiveX, .NET's WinForms, and so, were just slightly-more-usable wrapper libraries over Win32/USER32/ComCtl. The fundamental unit of a GUI in Win32 is the hWnd (Window Handle), which represents some rectangle on the screen managed by Windows' window-manager (which can be a top-level window with a titlebar etc, or a composed arbitrary rectangle for a composed widget, such as a button or checkbox: Windows has always supported this high-level composition of hWnds, but with severe limitations tied to its dependence on GDI (e.g. when you're using separate hWnds for separate controls then those controls can't have z-axis alpha-blending when overlapping - and you can't do deep-color painting as GDI is fundamentally limited to 32-bit ARGB). By the early 2000s it was to clear to everyone, including Microsoft, that a modern replacement was needed - which we saw in the original Windows Longhorn demos of 2003: Windows Longhorn (then Vista) now had a true compositing window-manager[1] which allowed applications to get top-level hWnds (and without any of GDI's legacy tentacles around them) which then could be used as a render-target directly from Direct3D for high-performance, yet windowed, 3D applications[2] (OpenGL support came later). This was crucial for the design of WPF (Avalon)...
Alright, here goes...
PART 1:
> basically every platform has a much better way to create an app for it
Yes and no.
On macOS and iOS, using Apple's first-party, in-box UI frameworks/libraries like Cocoa, Cocoa Touch, SwiftUI is the best, and only, way to make a lovable user-experience on macOS and iOS. The downside is that if your application needs some ultra-specific widget that Apple hasn't already made in Cocoa then you've got a lot of legwork to do, especially w.r.t. painting in your NSView subclass. Despite Cocoa's very modern and sophisticated aesthetics, it's still fundamentally a very 1990s OOP widget library based around composing and subclassing opaque view objects.
On Linux (and in ancient-times: UNIX environments like CDE): the native desktop app UX story has always been a hot-mess simply due to UNIX specs like POSIX not getting involved in the GUI side, and despite some OS vendors trying to be consistent (rip SGI) the widget/library vendors never had any incentive for consistency. While GTK is considered Linux's "default" widget set today, there are still other equally-native but entirely separate widget toolkits (Motif, Xaw, etc) that developers are free to use - so there is no one true way to build a native GUI for Linux today, or at least, not one readily suitable for 1990s-style RAD, in my experience.
On Windows... well, that's where Microsoft has somehow taken Windows from being its (imo) Windows XP heydays: a platform with a (relatively nice) coherent and single widget set (i.e. USER32 and ComCtl32) - with occasional third-party libs like Delphi's VCL. (Other things, like MFC, ActiveX, .NET's WinForms, and so, were just slightly-more-usable wrapper libraries over Win32/USER32/ComCtl. The fundamental unit of a GUI in Win32 is the hWnd (Window Handle), which represents some rectangle on the screen managed by Windows' window-manager (which can be a top-level window with a titlebar etc, or a composed arbitrary rectangle for a composed widget, such as a button or checkbox: Windows has always supported this high-level composition of hWnds, but with severe limitations tied to its dependence on GDI (e.g. when you're using separate hWnds for separate controls then those controls can't have z-axis alpha-blending when overlapping - and you can't do deep-color painting as GDI is fundamentally limited to 32-bit ARGB). By the early 2000s it was to clear to everyone, including Microsoft, that a modern replacement was needed - which we saw in the original Windows Longhorn demos of 2003: Windows Longhorn (then Vista) now had a true compositing window-manager[1] which allowed applications to get top-level hWnds (and without any of GDI's legacy tentacles around them) which then could be used as a render-target directly from Direct3D for high-performance, yet windowed, 3D applications[2] (OpenGL support came later). This was crucial for the design of WPF (Avalon)...
Now everyone's gone to pseudo-XAML with react JSX.
Plus ca change...
Plus ca change...
The rot set in way before Electron came along.
I think JavaFX could have been more successful if they would have managed it differently. I really liked it. The JavaFX developers were all great to deal with and would help you as much as they could.
One of the problems in my opinion is that once you went up the chain beyond the developers, it seemed like there were some people that didn't understand what they were doing or didn't care or possibly both. They had targets to meet (or something) and the health of the project was a secondary concern. Part of this could be seen by the messaging saying they were investing in JavaFX, mobile, etc., but most of the commits to the repo were done by a few people. I can't remember what the numbers were, but I remember being shocked and thinking that if one of the top two contributors disappeared the project would be in trouble.
However, the biggest mistake in my opinion was forcing JavaFX into the JDK way too quickly. You can tell that's the type of decision that comes from the top down. They wanted to be able to say the JDK had a next generation GUI toolkit and checking that box was more important than letting the project develop in a healthy manner.
Before JavaFX went into the JDK it was really easy to contribute to the project via the dedicated bug tracker and you could get quick, friendly, helpful feedback directly from the developers. Bugs were fixed and would land in the next release. After it was part of the JDK you had to use bugs.jdk.com and it became much harder to participate. Factor in JavaFX having to adhere to the JDK release schedule rather than iterating quickly like they had been and it was impossible to figure out what Oracle was trying to do. Was having JavaFX on the JDK marketing material really worth stalling the development and ruining any chance it had of becoming more popular? I still can't get my head around it.
The fixation on the browser plugin and applets always confused me too. It was obvious for years they'd eventually get locked out of browsers, so I don't know why they didn't push things like Web Start a lot harder. Web Start was a pretty decent distribution system and if they had improved it to fetch JREs, like OpenWebStart does now, it would have been one of the best options at the time.
To this day I'm convinced that JavaFX was a missed opportunity. I'd love to try to build an app that uses Gluon [1] stuff for direct framebuffer rendering on a Raspberry PI with Mender [2] for distribution. I think you could combine something like that with JxBrowser [3] to build a digital signage system that's much better than anything on the market, but the licensing is a huge pain and too expensive for a hobbyist project.
1. https://gluonhq.com/products/gluon-embedded/
2. https://mender.io
3. https://www.teamdev.com/jxbrowser
One of the problems in my opinion is that once you went up the chain beyond the developers, it seemed like there were some people that didn't understand what they were doing or didn't care or possibly both. They had targets to meet (or something) and the health of the project was a secondary concern. Part of this could be seen by the messaging saying they were investing in JavaFX, mobile, etc., but most of the commits to the repo were done by a few people. I can't remember what the numbers were, but I remember being shocked and thinking that if one of the top two contributors disappeared the project would be in trouble.
However, the biggest mistake in my opinion was forcing JavaFX into the JDK way too quickly. You can tell that's the type of decision that comes from the top down. They wanted to be able to say the JDK had a next generation GUI toolkit and checking that box was more important than letting the project develop in a healthy manner.
Before JavaFX went into the JDK it was really easy to contribute to the project via the dedicated bug tracker and you could get quick, friendly, helpful feedback directly from the developers. Bugs were fixed and would land in the next release. After it was part of the JDK you had to use bugs.jdk.com and it became much harder to participate. Factor in JavaFX having to adhere to the JDK release schedule rather than iterating quickly like they had been and it was impossible to figure out what Oracle was trying to do. Was having JavaFX on the JDK marketing material really worth stalling the development and ruining any chance it had of becoming more popular? I still can't get my head around it.
The fixation on the browser plugin and applets always confused me too. It was obvious for years they'd eventually get locked out of browsers, so I don't know why they didn't push things like Web Start a lot harder. Web Start was a pretty decent distribution system and if they had improved it to fetch JREs, like OpenWebStart does now, it would have been one of the best options at the time.
To this day I'm convinced that JavaFX was a missed opportunity. I'd love to try to build an app that uses Gluon [1] stuff for direct framebuffer rendering on a Raspberry PI with Mender [2] for distribution. I think you could combine something like that with JxBrowser [3] to build a digital signage system that's much better than anything on the market, but the licensing is a huge pain and too expensive for a hobbyist project.
1. https://gluonhq.com/products/gluon-embedded/
2. https://mender.io
3. https://www.teamdev.com/jxbrowser
It felt like that happened years before Oracle acquired Sun. Java on the desktop was a neat idea but after the early 2000s it seemed like they weren't seriously committed to it and basic needs continued to go unfilled.
Same happened to MySQL. People run away screaming from anything Oracle touches.
This article seems quite off. First, it conflates browser and desktop. Yes, applets died an early and deserved death. That is different from what happened with desktop apps.
A univeral GUI (e.g. Swing) was wrong-headed. I don't actually know what happened after people moved away from Swing. But even in the time range TFA discusses, Intellij IDEA, an IDE written in Java, was a success. It has always been multi-platform, and never had worse than acceptable performance in my experience. It has grown into a large suite of products, and I think it is widely considered to be the best IDE, for pretty much any language you can name, by a wide margin.
Java has become the new COBOL -- the language for business applications, which means backend development. But the continuing success and improvement, and broadening of the JetBrains products pretty much demolishes the argument that Java has declined and fallen on the desktop. JetBrains is an existence proof that it is a very capable platform for anyone who chooses to use it there.
A univeral GUI (e.g. Swing) was wrong-headed. I don't actually know what happened after people moved away from Swing. But even in the time range TFA discusses, Intellij IDEA, an IDE written in Java, was a success. It has always been multi-platform, and never had worse than acceptable performance in my experience. It has grown into a large suite of products, and I think it is widely considered to be the best IDE, for pretty much any language you can name, by a wide margin.
Java has become the new COBOL -- the language for business applications, which means backend development. But the continuing success and improvement, and broadening of the JetBrains products pretty much demolishes the argument that Java has declined and fallen on the desktop. JetBrains is an existence proof that it is a very capable platform for anyone who chooses to use it there.
The article glosses over a couple of points I recall from living through the same period:
- JBuilder was performant (and as I recall, for GUI development, awesome). Not sure if it was Swing-based, but it was a counterpoint to the idea that you couldn't build performant Java GUI apps.
- Applets were stifled by Microsoft refusing to include a contemporary Java runtime in IE, which was still dominant around 2000. My recollection is a bit vague now, but I seem to recall that Java applets in IE were stuck on a 1.0 JVM when Java 1.2 was contemporary.
It's worth noting that I was developing on Linux and Windows. The author's experience would have been coloured by his use of the Mac platform. Up until quite recently, Macs were stuck on Java 6 while the rest of us were using Java 8, at least. I can't help but wonder if Apple considered Java to be a second class citizen.
- JBuilder was performant (and as I recall, for GUI development, awesome). Not sure if it was Swing-based, but it was a counterpoint to the idea that you couldn't build performant Java GUI apps.
- Applets were stifled by Microsoft refusing to include a contemporary Java runtime in IE, which was still dominant around 2000. My recollection is a bit vague now, but I seem to recall that Java applets in IE were stuck on a 1.0 JVM when Java 1.2 was contemporary.
It's worth noting that I was developing on Linux and Windows. The author's experience would have been coloured by his use of the Mac platform. Up until quite recently, Macs were stuck on Java 6 while the rest of us were using Java 8, at least. I can't help but wonder if Apple considered Java to be a second class citizen.
I believe Microsoft went all out on "extinguishing" applets after Sun sued the Microsoft Java project out of existence. Hence the contemporaneous beginnings of C# and the CLR.
> the JetBrains products pretty much demolishes the argument that Java has declined and fallen on the desktop. JetBrains is an existence proof that it is a very capable platform
Your counterpoint doesn't apply to the article because the author's use of "decline & fall" is about market share and dev mindshare and not about any declining technical capabilities. (Notice that the author already agreed with you about Java's capable platform when he wrote: "Despite the ominous tone of this article’s title, I believe that Java is a compelling platform for modern desktop applications.")
Jetbrains releasing new products doesn't change the fact Java lost popularity as a tool for desktop apps in comparison to its 1995 hype. Even during Java's late 1990s peak hype cycle, its usage for desktop apps was never adopted by programmers to the same degree as Electron/Javascript is today.
Your counterpoint doesn't apply to the article because the author's use of "decline & fall" is about market share and dev mindshare and not about any declining technical capabilities. (Notice that the author already agreed with you about Java's capable platform when he wrote: "Despite the ominous tone of this article’s title, I believe that Java is a compelling platform for modern desktop applications.")
Jetbrains releasing new products doesn't change the fact Java lost popularity as a tool for desktop apps in comparison to its 1995 hype. Even during Java's late 1990s peak hype cycle, its usage for desktop apps was never adopted by programmers to the same degree as Electron/Javascript is today.
On the contrary.
Jetbrains IDE's prove the fact that no matter how much you engineer, a java based desktop application will always be slow and eat huge amounts of resources.
Jetbrains IDE's prove the fact that no matter how much you engineer, a java based desktop application will always be slow and eat huge amounts of resources.
I think I have already answered you regarding it, but Jetbrains IDE’s are not resource-hungry because of Java but because they index/cache the code base. You can’t draw meaningful conclusions from that.
As opposed to the Electron-based editors which modern web developers use and heat Starbucks with?
"Software is getting slower more rapidly than hardware is becoming faster."
https://en.wikipedia.org/wiki/Wirth%27s_law
https://en.wikipedia.org/wiki/Wirth%27s_law
VSCode is Electron-based and it's quite efficient and not such a memory hog.
I can't disagree with anything you say here, except the thing about "the article seems quite off". lol.
This piece covers the state of the technology at that time. In the early 2000's Java was slow. I wasn't familiar with IntelliJ at that time, so can't comment on their performance then. I wouldn't expect it to be dramatically better than other Java apps on the market at that time.
Moore's law has steadily changed the landscape. So have improvements in JIT technology.
This piece covers the state of the technology at that time. In the early 2000's Java was slow. I wasn't familiar with IntelliJ at that time, so can't comment on their performance then. I wouldn't expect it to be dramatically better than other Java apps on the market at that time.
Moore's law has steadily changed the landscape. So have improvements in JIT technology.
The exception doesn’t prove the rule.
It’s ridiculous that I have to modify Java VM arguments so IntelliJ can use more ram and actually index my projects.
The IDE is great, but Java undoubtedly makes it worse.
It’s ridiculous that I have to modify Java VM arguments so IntelliJ can use more ram and actually index my projects.
The IDE is great, but Java undoubtedly makes it worse.
That’s the fault of jetbrains, not java. They release it with way too old JRE with custom patches and quite shitty default arguments, while it works eons better with no argument at all on an up-to-date jdk, but even more so with the single setting of a low-latency GC, ZGC.
The JVM is a beast, why do you think a good deal of all serious web applications run on top of it?
The JVM is a beast, why do you think a good deal of all serious web applications run on top of it?
> The JVM is a beast, why do you think a good deal of all serious web applications run on top of it?
When I run a Java app-server I'm happy to, in fact it's unwise not to, allocate it the maximum possible RAM the underlying server has. That's because I know for sure JVM is the only thing that's going to be running on a server.
On a desktop it's a totally different story. IntelliJ has to compete with other applications for RAM because I'm constantly multi-tasking between browser tabs, Apple Music, Slack app and what not. So allocating RAM to JVM apps on desktop is a world of pain because I, as a desktop user, just don't (want to) know how to fine-tune hardware resources for different apps. I don't allocate heap to Safari, why should it be the case with IntelliJ? Why can't they figure out? Or maybe there should be a desktop version/mode of JVM that'll figure out ideal RAM size and work with it and expand/shrink as needed?
When I run a Java app-server I'm happy to, in fact it's unwise not to, allocate it the maximum possible RAM the underlying server has. That's because I know for sure JVM is the only thing that's going to be running on a server.
On a desktop it's a totally different story. IntelliJ has to compete with other applications for RAM because I'm constantly multi-tasking between browser tabs, Apple Music, Slack app and what not. So allocating RAM to JVM apps on desktop is a world of pain because I, as a desktop user, just don't (want to) know how to fine-tune hardware resources for different apps. I don't allocate heap to Safari, why should it be the case with IntelliJ? Why can't they figure out? Or maybe there should be a desktop version/mode of JVM that'll figure out ideal RAM size and work with it and expand/shrink as needed?
Minecraft on modern JVMs still requires setting memory usage based on how much free RAM you have (though not GC tuning
to the same extent as before).
> The JVM is a beast, why do you think a good deal of all serious web applications run on top of it?
The JVM sacrifices latency for throughput, which is good for servers but not for desktops.
The JVM sacrifices latency for throughput, which is good for servers but not for desktops.
Look at ZGC GC. It has less latency due to stop-the-words than what the OS scheduler causes. (Of course at the price of throughput). But also the default GC, while on default being more throughput preferring can be tuned by a single paramater.
> Look at ZGC GC.
I did, it caused huge pauses with my application (I think probably a bug).
> But also the default GC, while on default being more throughput preferring can be tuned by a single paramater.
Sure, but how many people will do even that much tuning? Defaults are important, and IMO Java chooses a bad one; responsive by default and tuneable when you need maximum throughput is better than the reverse. (I suspect they picked the defaults they did to be competitive against C++ in benchmarks, but we're well past the time where that's what you're competing with).
Same as how Go and Electron have been very successful - not because they're great to work in per se, but because they have so much less friction between writing a hello world program and getting an executable you can distribute.
I did, it caused huge pauses with my application (I think probably a bug).
> But also the default GC, while on default being more throughput preferring can be tuned by a single paramater.
Sure, but how many people will do even that much tuning? Defaults are important, and IMO Java chooses a bad one; responsive by default and tuneable when you need maximum throughput is better than the reverse. (I suspect they picked the defaults they did to be competitive against C++ in benchmarks, but we're well past the time where that's what you're competing with).
Same as how Go and Electron have been very successful - not because they're great to work in per se, but because they have so much less friction between writing a hello world program and getting an executable you can distribute.
That’s not how it works. It’s not like Java’s GCs in the last decade had any sort of huge pauses unless the program did some stupid shit like allocation in a hot loop. (G1GC, the default since 9 promises by default a 10ms max pause time and it can uphold that under crazy conditions even — and even after that it will get progressively slower instead of a huge increase)
Java’s GCs are the state of the art, if they struggle with a workload then it is pretty much guaranteed that other GCs have already broken down completely at the fraction of that.
Regarding your application, did you check how many objects have you allocated? VisualVM and the like can show you precisely the statistics of your allocations.
Java’s GCs are the state of the art, if they struggle with a workload then it is pretty much guaranteed that other GCs have already broken down completely at the fraction of that.
Regarding your application, did you check how many objects have you allocated? VisualVM and the like can show you precisely the statistics of your allocations.
> That’s not how it works. It’s not like Java’s GCs in the last decade had any sort of huge pauses unless the program did some stupid shit like allocation in a hot loop.
Or there's a bug. There's a reason ZGC is marked as experimental. G1GC handled the application in question fine, we reverted to that and it wasn't worth our time investigating further.
Or there's a bug. There's a reason ZGC is marked as experimental. G1GC handled the application in question fine, we reverted to that and it wasn't worth our time investigating further.
While there is a possibility of a bug, I really doubt it. G1GC is just a beast and likely has just no problem with the allocation-rate your program uses while ZGC has quite a tradeoff for really low latency.
JetBrains literally has to ship its own fork of the JRE for things like decent font rendering: https://github.com/JetBrains/JetBrainsRuntime
In its success it shows how badly Java has failed.
In its success it shows how badly Java has failed.
Because JetBrains is shipping a JDK11 runtime, and huge improvements have been made (including font rendering) in the past three years, ironically making it a pain for JB to update to JDK17.
What happened in the years leading up to 2005, or perhaps in 2005 specifically that caused this blackout? Where did all of the Java desktop developers go?
Before 2004, there was a much wider perception that web applications were fundamentally limited by their latency, and if you wanted a really rich, interactive user experience, like Winamp or Outlook, you had to make a desktop application.
Then Gmail launched in 2004 and Google Maps launched in 2005. At that point, if you wanted to make a web-enabled experience with a high-quality user interface, it became more and more clear that you should build the client side in HTML + JavaScript and the server side in whatever you wanted, possibly Java.
Before 2004, there was a much wider perception that web applications were fundamentally limited by their latency, and if you wanted a really rich, interactive user experience, like Winamp or Outlook, you had to make a desktop application.
Then Gmail launched in 2004 and Google Maps launched in 2005. At that point, if you wanted to make a web-enabled experience with a high-quality user interface, it became more and more clear that you should build the client side in HTML + JavaScript and the server side in whatever you wanted, possibly Java.
Google Maps was the first widespread use of Ajax outside Microsoft, and its near-realtime interactivity blew people away. Prior to that, few developers believed this level of interactivity was possible. After Google Maps, everybody learned Ajax and a thousand interactive flowers bloomed.
My recollection is that nobody really had wifi or cable internet before about 2005.
Webapps over dialup was a complete non-starter, so you had to have desktop apps.
Webapps over dialup was a complete non-starter, so you had to have desktop apps.
As a C# developer I remember the first time I developed a GUI java application. In C# you have a code-behind file with your own code and event handlers, and a "designer file" with the generated code to set-up the GUI itself.
Then I used Netbeans for a Java app, and the code file contained weird sections of artificially not editable code, and event handlers were so much more complex and cumbersome - with inner classes etc. Felt really like a step back.
Then I used Netbeans for a Java app, and the code file contained weird sections of artificially not editable code, and event handlers were so much more complex and cumbersome - with inner classes etc. Felt really like a step back.
Sure but for those who remember history C# was Microsoft's answer to the incredible success that Java was clearly becoming.
Being years late to the party and basically creating a (back then) Windows-only copy of Java, it's quite normal that they managed to do a few things better.
Regarding UI editors: back in the days IntelliJ was already amazing and allowed to hide all that boilerplate Java code. This boilerplate code was still there, but hidden by the IDE.
Being years late to the party and basically creating a (back then) Windows-only copy of Java, it's quite normal that they managed to do a few things better.
Regarding UI editors: back in the days IntelliJ was already amazing and allowed to hide all that boilerplate Java code. This boilerplate code was still there, but hidden by the IDE.
I mean, C# only got created because Microsoft wasn't allowed to add native GUI features to Java. I feel like you might have missed all the critical history with J++ and the lawsuit from Sun.
Yea, it's kinda hard to say how things would have shaken out. I think Sun was reasonably wary about J++. Microsoft's way of operating at the time was "embrace, extend, extinguish."
Microsoft brought out Internet Explore (embrace), added ActiveX (extend), and pretty much extinguished Netscape. All websites could run in IE, but not Netscape - and users are going to use the browser that works for all sites.
Sun's lawsuit against Microsoft wasn't quite about adding native GUI features to Java as much as Microsoft breaking Java compatibility. Microsoft removed JNI (Java Native Interface) and replaced it with J/Direct. Microsoft wanted Java programs to be platform-specific with Java being "just the latest, best way to write Windows applications" (according to documents from the trial).
It's not like Microsoft was trying to create MAUI back in 2000 (the new C#/.NET multi-platform app UI). Microsoft was trying to make it so that Java apps wouldn't be cross-platform by both breaking Java programs that used JNI and making sure that new programs would be made with J/Direct and their Windows-only GUI.
Today, we see a much friendlier Microsoft. It's wonderful. They're happy to coexist with lots of people and ecosystems, lots of Microsoft employees use MacBooks, and Azure is one of the largest operator of Linux servers in the world - and they've made a wonderful business out of this coexistence. Back then, Microsoft would kill everything it could find to keep its dominance. There was no friendly help. There was no "oh, we're just trying to make the GUI better." It was "if we make the UX better via a proprietary native UI, we can get developers using our UI toolkit from Java which means that users are still locked into Windows, it means that the Mac will still be starved for applications, and it means that new operating systems like BeOS won't get a library of applications to bootstrap from if they just add Java support."
It can be hard to remember how much Microsoft tried to break your toys - especially when today they seem like the company that's trying to make cool toys for me and make my current toys better. Proprietary Microsoft Office formats to keep people locked in, telling PC makers that if they offered alternative operating systems as an option they'd lose access to Windows, and taking anything that showed promise and adding something to it to break compatibility with cross-platform implementations (Java, the web, etc)
C# got created because Microsoft got locked out of their embrace, extend, extinguish strategy with Java. Their Java license mandated that they maintain compatibility and they didn't - and to be frank, it seems that they didn't break compatibility with good intentions.
Microsoft brought out Internet Explore (embrace), added ActiveX (extend), and pretty much extinguished Netscape. All websites could run in IE, but not Netscape - and users are going to use the browser that works for all sites.
Sun's lawsuit against Microsoft wasn't quite about adding native GUI features to Java as much as Microsoft breaking Java compatibility. Microsoft removed JNI (Java Native Interface) and replaced it with J/Direct. Microsoft wanted Java programs to be platform-specific with Java being "just the latest, best way to write Windows applications" (according to documents from the trial).
It's not like Microsoft was trying to create MAUI back in 2000 (the new C#/.NET multi-platform app UI). Microsoft was trying to make it so that Java apps wouldn't be cross-platform by both breaking Java programs that used JNI and making sure that new programs would be made with J/Direct and their Windows-only GUI.
Today, we see a much friendlier Microsoft. It's wonderful. They're happy to coexist with lots of people and ecosystems, lots of Microsoft employees use MacBooks, and Azure is one of the largest operator of Linux servers in the world - and they've made a wonderful business out of this coexistence. Back then, Microsoft would kill everything it could find to keep its dominance. There was no friendly help. There was no "oh, we're just trying to make the GUI better." It was "if we make the UX better via a proprietary native UI, we can get developers using our UI toolkit from Java which means that users are still locked into Windows, it means that the Mac will still be starved for applications, and it means that new operating systems like BeOS won't get a library of applications to bootstrap from if they just add Java support."
It can be hard to remember how much Microsoft tried to break your toys - especially when today they seem like the company that's trying to make cool toys for me and make my current toys better. Proprietary Microsoft Office formats to keep people locked in, telling PC makers that if they offered alternative operating systems as an option they'd lose access to Windows, and taking anything that showed promise and adding something to it to break compatibility with cross-platform implementations (Java, the web, etc)
C# got created because Microsoft got locked out of their embrace, extend, extinguish strategy with Java. Their Java license mandated that they maintain compatibility and they didn't - and to be frank, it seems that they didn't break compatibility with good intentions.
> Today, we see a much friendlier Microsoft. It's wonderful
> It's not like Microsoft was trying to create MAUI back in 2000
Today, in 2022, Microsoft still tries to uses the MAUI name even though it is directly the name of a pre-existing unrelated GUI toolkit (https://mauikit.org/). Much friendlier my arse.
> It's not like Microsoft was trying to create MAUI back in 2000
Today, in 2022, Microsoft still tries to uses the MAUI name even though it is directly the name of a pre-existing unrelated GUI toolkit (https://mauikit.org/). Much friendlier my arse.
Now Google is doing the same with Kotlin, creating their own version of ".NET" on Android.
That's more NetBeans than Java- the GUI builder really didn't want you messing with it's generated code directly.
While Java was designed to be multi-platform, C# was designed specifically to create software that could run only on Microsoft platforms. Any advantage provided by C# is negated by tying your work to a platform that could be abandoned by MS as they did to Visual Basic.
From the start C# was designed to run on any platform, which is why it compiled to IL and didn't use Win32 as the basis for the library.
It didn't take long for JIT compilers to exist for other platforms.
It didn't take long for JIT compilers to exist for other platforms.
You're just believing in MS propaganda. Yes, people created compilers and virtual machines for other platforms, but MS never considered this important. Their goal is to have only Windows as first class citizen in the .net world. If you write C# code you're tying yourself to a closed product that is restricted to a single platform.
>If you write C# code you're tying yourself to a closed product that is restricted to a single platform.
I've been using C# on Linux for well over a decade. And on embedded systems. Mono has shipped on various Linuxes for well over 15 years at this point. I've been able to write a single binary that runs on windows and on Linux, no recompile needed, for this long.
>You're just believing in MS propaganda.
Yes, one of us certainly has drank the koolaid.
I've been using C# on Linux for well over a decade. And on embedded systems. Mono has shipped on various Linuxes for well over 15 years at this point. I've been able to write a single binary that runs on windows and on Linux, no recompile needed, for this long.
>You're just believing in MS propaganda.
Yes, one of us certainly has drank the koolaid.
No, he is right though. .NET was not only on Windows, but Windows CE as well. Later also via Silverlight.
You think of cross-platform as cross-vendor.
You think of cross-platform as cross-vendor.
Not really. A single vender can be multi platform, for example Oracle. MS wants to propel their Windows platform. Windows can run on several types of hardware, but these are variations of the same thing.
These days MS makes way more from Azure, hurting Linux support will hurt Azure, and they can't afford it.
Early C# didn't have partial classes and had the generated code in the same file as all of the rest of your code, as well. They put it in regions that VS would automatically collapse for you, but it was still directly there. I think it was C# 2.0 that added partial class support and they started moving the designer generated code into separate files which was truly helpful.
I don't think C# was ever as bad as MFC was with true magic generated code that you had better not change lest you inadvertently broke everything beyond repair (unless you really understood cryptic C++ error messages & preprocessor usage). MFC of the same era was not beginner friendly, even C# 1.0 was.
I've never had the (dis)pleasure of doing java UI work, though, so I can't really comment on the state of things there.
I don't think C# was ever as bad as MFC was with true magic generated code that you had better not change lest you inadvertently broke everything beyond repair (unless you really understood cryptic C++ error messages & preprocessor usage). MFC of the same era was not beginner friendly, even C# 1.0 was.
I've never had the (dis)pleasure of doing java UI work, though, so I can't really comment on the state of things there.
I started from the other side of that fence, and I remember feeling jealous of how smooth the GUI editor was in Visual Studio. Even in 2022, I still don't think I've seen any Java GUI builders that are as easy to use as Visual Studio circa 2001/2.
SceneBuilder is nice though.
Java Swing still lets you make native-looking-and-feeling apps (with some care). I don't know of any new GUI frameworks that let you do the same. I consider this a killer-feature of the framework. It's also very fast, backed by OpenGL and DirectX. It also ships with source code and isn't declarative, so it's trivial to step into as a means to debug why your code isn't working.
> native-looking-and-feeling apps
Who are you kidding?
> (with some care)
No. Even if you were to give it more care than required to rewrite the GUI natively in each major platform, you still wouldn't be close.
Look, I get it, there are plenty of applications where a bit of clunk in the GUI is beneath other things on the priority list. That's fine. But the number of java devs who think clobbering together a few native widgets means they have constructed a native experience is... disconcertingly high. There's a whole GUI world out there beyond the lowest-common-denominator, and Swing isn't even the best at that.
Your priorities might still be perfectly rational. I might even make the same decisions under the same constraints. Just... be aware of what you're trading away
Who are you kidding?
> (with some care)
No. Even if you were to give it more care than required to rewrite the GUI natively in each major platform, you still wouldn't be close.
Look, I get it, there are plenty of applications where a bit of clunk in the GUI is beneath other things on the priority list. That's fine. But the number of java devs who think clobbering together a few native widgets means they have constructed a native experience is... disconcertingly high. There's a whole GUI world out there beyond the lowest-common-denominator, and Swing isn't even the best at that.
Your priorities might still be perfectly rational. I might even make the same decisions under the same constraints. Just... be aware of what you're trading away
Certainly the default L&F is not native looking, nor are any of the popular community L&Fs. Though one can simply set the L&F to the native look and feel with essentially one line of code. The little care I'm referring to is around polish to get beyond the lowest-common-denominator. Regardless, system L&F with Swing is still worlds better than any Electron app, which is now a common technique to build cross platform apps.
Windows LnF hasn't looked native since WinXP and never felt native.
Lots off things are off by few pixels, there are no animations or shadows, no context menus etc.
At least in Electron textboxes have standard context menu and drag and drop.
At least in Electron textboxes have standard context menu and drag and drop.
> the number of java devs who think clobbering together a few native widgets means they have constructed a native experience is... disconcertingly high.
It's absolutely a psyop cover for the number of webkit-in-a-box projects that don't even bother with the first step. Normalized deviance.
It's absolutely a psyop cover for the number of webkit-in-a-box projects that don't even bother with the first step. Normalized deviance.
No they aren't, provided that the developers actually bother to read books like "Filthy Rich Clients".
https://www.amazon.com/Filthy-Rich-Clients-Developing-Applic...
https://www.amazon.com/Filthy-Rich-Clients-Developing-Applic...
Swing's platform look and feel does not get a convincing native experience, as you'll find out the first time you open a JFileChooser on Mac and see a clone of the windows XP file picker with widgets made to look like mac OS widgets circa Snow Leopard.
The FileDialog is the only AWT widget I still use regularly. It gives you the native file chooser. Unfortunately it isn't terribly flexible when it comes to, for example, only selecting directories. In those cases, I have been known to use JNI to use the truly native dialog.
Some of those dialogs are indeed not great and a weak point. There are a few options to get a native picker though.
It was not impressive when this documentation was written, but it's for sure not impressive today.
I do not know whether the Java GUIs that I encounter from time to time are made with Swing or with other frameworks.
What I know is that since the beginning of Java and until now, on every occasion when I use for the first time some program and I am surprised that its GUI is ugly, slow and impossible to customize, then, without exception, I always discover that the GUI is written in Java.
Since around 8 years I use only 4k monitors. While on Windows I have encountered some programs which had problems on high-resolution screens, on Linux I never had any problems, except with all professional programs written in Java, which, unlike the native GUI applications, do not honor any system configurations and they do not seem aware of which is the monitor dpi, to adjust their GUI. Moreover, for some reason the programmers who write such Java programs are almost always morons who do not provide any means for changing the fonts which are used by the GUI.
Just a few months ago, I have still encountered some expensive professional programs, which used a Java GUI installer. The Java GUI installer crashed on any computer which used monitors with 10-bit color components. When investigating the problem the conclusion was that it is a well-known Java bug that had not been solved for some years and which causes such Java GUI installers to work only on low-quality monitors with 8-bit color components.
So much for the supposed benefit of Java being able to run anywhere.
What I know is that since the beginning of Java and until now, on every occasion when I use for the first time some program and I am surprised that its GUI is ugly, slow and impossible to customize, then, without exception, I always discover that the GUI is written in Java.
Since around 8 years I use only 4k monitors. While on Windows I have encountered some programs which had problems on high-resolution screens, on Linux I never had any problems, except with all professional programs written in Java, which, unlike the native GUI applications, do not honor any system configurations and they do not seem aware of which is the monitor dpi, to adjust their GUI. Moreover, for some reason the programmers who write such Java programs are almost always morons who do not provide any means for changing the fonts which are used by the GUI.
Just a few months ago, I have still encountered some expensive professional programs, which used a Java GUI installer. The Java GUI installer crashed on any computer which used monitors with 10-bit color components. When investigating the problem the conclusion was that it is a well-known Java bug that had not been solved for some years and which causes such Java GUI installers to work only on low-quality monitors with 8-bit color components.
So much for the supposed benefit of Java being able to run anywhere.
Yes, that's totally annoying since it really isn't very hard to get right... Swings layout managers are just made to deal with this stuff.
I will freely admit that Java Swing remains the only GUI toolkit I've used that I actually felt comfortable using to write a GUI, rather than something that feels like having to pull out teeth to get things working in a somewhat coherent manner.
Absolutely agree, provided you use a layout manager that isn't brain damaged.
Anyone remember this video? https://www.youtube.com/watch?v=UuLaxbFKAcc - Totally Gridbag
Anyone remember this video? https://www.youtube.com/watch?v=UuLaxbFKAcc - Totally Gridbag
I don't do a lot of GUI programming, but I always found the Swing layouting to be very frustrating and counterintuitive.
As others have said, JavaFX is really pretty good. People who use JavaFX generally seem to be satisfied, it's not often I see a substantive criticism of it, but unfortunately it seems to be widely regarded as too little too late and doesn't get given a chance. The Ada of the GUI toolkit world.
As others have said, JavaFX is really pretty good. People who use JavaFX generally seem to be satisfied, it's not often I see a substantive criticism of it, but unfortunately it seems to be widely regarded as too little too late and doesn't get given a chance. The Ada of the GUI toolkit world.
For a while I thought GTK was great hope for a good toolkit. I remember about this time period in this article (early 2000's) messing around with Perl/GTK to write simple desktop apps.
Unfortunately had issues with new version breaking backwards compatibility etc. which killed it.
QT also had similar hype but never took off.
Unfortunately had issues with new version breaking backwards compatibility etc. which killed it.
QT also had similar hype but never took off.
You haven't tried AppKit, WinForms, or WPF.
Winforms is dead, as in not cross platform and WPF...the same. WPF is declarative XML as is Xamarin Forms (both slightly different XML oddly). Not fun.
Microsoft's refusal to port WinForms is truly the most disappointing part of its cross-platform efforts, in my opinion. They have Mono, they can get it working, they just choose not to.
I wouldn't build a production application in WinForms, WPF and friends are much better for that. But, for quick&dirty or even moderately complex tools for experts, VS + WinForms simply has no equal. Some Python-based designers come close, but they definitely suffer when it comes to distribution.
With modern dotnet tech, Microsoft could allow us to build a (rather sizable) single, statically linked binary for any architecture, with the impressive performance of the dotnet JIT and native controls.
After working on Android designs, I've got to say, XML is fine for UI design. You need previews and visual inspectors to get an accurate idea of what you're doing, but describing what control lives where and what properties it has is a perfectly sensible use case for XML.
I wouldn't build a production application in WinForms, WPF and friends are much better for that. But, for quick&dirty or even moderately complex tools for experts, VS + WinForms simply has no equal. Some Python-based designers come close, but they definitely suffer when it comes to distribution.
With modern dotnet tech, Microsoft could allow us to build a (rather sizable) single, statically linked binary for any architecture, with the impressive performance of the dotnet JIT and native controls.
After working on Android designs, I've got to say, XML is fine for UI design. You need previews and visual inspectors to get an accurate idea of what you're doing, but describing what control lives where and what properties it has is a perfectly sensible use case for XML.
It wouldn’t make much sense to port Winforms any more, as it is CPU-renderer only. It would be disappointingly slow for anything more complex than, well, forms.
XML is actually pretty good at declaring UI. It's the sort of thing the language was designed for - a UI is a tree of attributed nodes, and that's also what XML gives you.
Winforms is undead.
We'll be writing WinForms applications in the 22nd century.
We'll be writing WinForms applications in the 22nd century.
Interesting, I'm not aware of any Java app that truly feels or looks native. I guess that there is definitely some selection biais, but do you have any examples of native-like Java Swing apps?
IDEA looked near-native (aside from docking/windowing that doesn't have system L&F anywhere) before they forced users away from system L&F.
SWT apps look native last time I used them.
It doesn't really matter. The users don't care and who the hell would want a native looking experience on windows anyway? I haven't tried my UI on a Mac recently but I doubt anyone would notice a difference. I have used Intellij IDEA on Mac recently and I appreciated the custom theme.
> who the hell would want a native looking experience on windows anyway?
I would. People who use accessibility tools that work best with native controls would as well.
I would. People who use accessibility tools that work best with native controls would as well.
The only way to achieve native-looking and feeling apps is to use the native UI toolkit of each platform. There is no such thing as a cross-platform toolkit that doesn't introduce jank and inaccuracy.
Do you mean specifically for Java? The Qt framework widgets look pretty dang native on my Mac.
Qt applications that try to look native are a bit weird for me. They are like a counterfeit product. I prefer an Electron app with a non native look that looks good.
> Java Swing still lets you make native-looking-and-feeling apps (with some care). I don't know of any new GUI frameworks that let you do the same.
That's the whole raison d'être of the (C++) wxWidgets toolkit. [0] It fully commits to using native GUI widgets, rather than impersonating them. (That is, it wraps various other toolkits.)
As others have pointed out, the other major cross-platform toolkits (Qt, GTK) also do a pretty good job.
[0] https://wxwidgets.org/
That's the whole raison d'être of the (C++) wxWidgets toolkit. [0] It fully commits to using native GUI widgets, rather than impersonating them. (That is, it wraps various other toolkits.)
As others have pointed out, the other major cross-platform toolkits (Qt, GTK) also do a pretty good job.
[0] https://wxwidgets.org/
Racket's GUI library comes pretty close, although the memory consumption needs work:
https://news.ycombinator.com/item?id=28512406
https://news.ycombinator.com/item?id=28512406
As a member of the Swing/JavaFX/Netbeans teams during the 2005-2010 period (I left the day before Oracle took over), I can tell you that this story is broadly correct, but with many missing subtleties. At the time we thought of Silverlight and Flash and Adobe Air as our mortal enemies. We were all wrong. After AJAX and HTML Canvas the web essentially killed desktop app development. All of those internal corporate apps (which were 95% of the desktop Java apps written) migrated to the web. We certainly all made mistakes and could have done some things differently (I begged to write the Applet plugin from scratch), but in the end none of those changes would have mattered. The future of desktop was the web.
Yet it's 2022 and I literally don't use web-based desktop apps for my day-to-day work ? Likewise, the SteamDeck just released with a desktop UI built entirely in Qt? I feel we are living in alternate realities
Its likely that you and HN are different from the majority. Web is the de-facto targets for the vast majority of development. The vast majority of users use apps on the web with a few exception. I'm pretty sure most people I know use mail in the browser. Even a lot of the Office Suite is being used in the web.
I'm sure there are a small group of people who use native apps for everything but the rest of the population is using the browser most of the time.
I'm sure there are a small group of people who use native apps for everything but the rest of the population is using the browser most of the time.
How does your statement contradict anything? What you use is entirely anecdotical, and the Deck is a niche gaming platform. Except for niche usages like utilities and the creative industry, classical desktop apps are dead for both consumer and enterprise users.
> Except for niche usages like utilities and the creative industry, classical desktop apps are dead for both consumer and enterprise users.
I don't even understand what you mean by "niche usages like utilities". Utilities aren't "niche".
And I literally don't know anyone who uses a computer and does not use some form of "creative" / authoring apps. Some drawing apps, some music production or maybe just the occasional recording with Audacity, trying to make games, editing ebooks with Calibre, etc. That's what human beings use computers for (and we're here to do things for human beings before anything).
I don't even understand what you mean by "niche usages like utilities". Utilities aren't "niche".
And I literally don't know anyone who uses a computer and does not use some form of "creative" / authoring apps. Some drawing apps, some music production or maybe just the occasional recording with Audacity, trying to make games, editing ebooks with Calibre, etc. That's what human beings use computers for (and we're here to do things for human beings before anything).
IMO the real reason why Java never took off on the desktop is because making a cross platform Java app is pretty easy but distributing a cross Java platform app is super hard. There’s all these situations that you have to account for, there’s no de facto way of doing anything, and you’re basically on your own finding a solution that fits your app. On top of that, you have to distribute the JVM and licensing for that used to not be that clear cut.
Literally the only obstacle to any language being on the desktop is the lack of someone creating a reliable, well-supported, cross platform, and easily licensed distribution method for that language.
Literally the only obstacle to any language being on the desktop is the lack of someone creating a reliable, well-supported, cross platform, and easily licensed distribution method for that language.
100% agree. The "distribution" step has always taken way more time than I expected. And, I almost always had to compromise on certain platforms just because it couldn't get the square peg in to the round hole.
The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.
The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.
Now we've got jlink to bundle your application with the neccessary runtime modules into one custom runtime image... a bit late to the game, but still...
I've been coding Java since 1.2, mainly UI. 20 years we built a really complex control system visualizing thousands of graphical states on six monitors on a Pentium, quietly ticking away at 20% CPU usage... all in Swing. Which I still find very impressive.
Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. And then there were the UI builders where anybody could draw up something mediocre.
Real strength were the lightweight components where you could about change everything in your Look&Feel. Hexagonal radiobuttons? No problem. Want the drop down button of that combobox a bit larger? There you go.
SWT... wouldn't really categorize that as an UI toolkit. SWT is mainly driven by eclipse, not developed independently. All controls commonly used by eclipse run reasonably well. Using anything else, especially cross platform is risky. 2D graphics is especially slow. So it's only a reasonable choice if you want to build something that looks and behaves like eclipse. There's some styling of components via CSS, but it's not complete...
Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. And then there were the UI builders where anybody could draw up something mediocre.
Real strength were the lightweight components where you could about change everything in your Look&Feel. Hexagonal radiobuttons? No problem. Want the drop down button of that combobox a bit larger? There you go.
SWT... wouldn't really categorize that as an UI toolkit. SWT is mainly driven by eclipse, not developed independently. All controls commonly used by eclipse run reasonably well. Using anything else, especially cross platform is risky. 2D graphics is especially slow. So it's only a reasonable choice if you want to build something that looks and behaves like eclipse. There's some styling of components via CSS, but it's not complete...
"Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. And then there were the UI builders where anybody could draw up something mediocre."
Agreed. Also, the IDEs would typically give you too much rope - enough for a novice to hang himself. When you create a new project with Xcode, you get a default project with all of the essentials for a native app. The menus, a window, an "About" window. Etc. In most java IDEs you get an empty main() method. Making an app that feels like a first-class citizen requires a lot of work and attention to detail.
Agreed. Also, the IDEs would typically give you too much rope - enough for a novice to hang himself. When you create a new project with Xcode, you get a default project with all of the essentials for a native app. The menus, a window, an "About" window. Etc. In most java IDEs you get an empty main() method. Making an app that feels like a first-class citizen requires a lot of work and attention to detail.
Oh, yes, the details are critical.
Once inherited a 2D graphic editor... so slow it was totally useless. After tinkering a bit I noticed coordinates were sometimes 'long', sometimes 'Long'... gazillions of automatic boxing and unboxing operations resulted in a severe performance penalty. But the original developer didn't figure this out, tried to fix the problem by adding some multithreading on top... and of course botching it.
Introduced some sensible data types, got rid of the multithreading and it really got smooth...
Once inherited a 2D graphic editor... so slow it was totally useless. After tinkering a bit I noticed coordinates were sometimes 'long', sometimes 'Long'... gazillions of automatic boxing and unboxing operations resulted in a severe performance penalty. But the original developer didn't figure this out, tried to fix the problem by adding some multithreading on top... and of course botching it.
Introduced some sensible data types, got rid of the multithreading and it really got smooth...
I played with Swing a bit and really liked the control it provides. Is there any book that you recommend other than Filthy Rich Clients by Chet Haase to develop complex Swing application or to pick up good habits?
Is swing still developed and is there any reason I should pick JavaFX over Swing?
Is swing still developed and is there any reason I should pick JavaFX over Swing?
Funny you mention that. I co-wrote Swing Hacks for O’Reilly in 2005 and I still get about 50$ A year in royalties. So someone must still be writing Swing Apps.
Code signing killed Web Start for anything but big $$$ projects. And asking people to download an application and run it with full privileges is a huge barrier to entry.
Contrast with the web deployment model:
* Deploy with a free SSL certificate
* Click Once, Run Anywhere (CORA)
Luckily for Java fans, you can make great Java apps for the modern web. Tools like TeaVM (and its Flavour toolkit for SPAs) make it possible. Code in Java, bind to real HTML templates, compose your app out of reusable HTML components, style with CSS. All the benefits of the modern web, with a single strongly-typed language top-to-bottom.
* TeaVM: https://teavm.org
* Real 5-letter word app made with TeaVM/Flavour: https://frequal.com/wordii/
* Migration Guide from Swing to TeaVM: https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV...
* Java Magazine article on TeaVM: https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
Contrast with the web deployment model:
* Deploy with a free SSL certificate
* Click Once, Run Anywhere (CORA)
Luckily for Java fans, you can make great Java apps for the modern web. Tools like TeaVM (and its Flavour toolkit for SPAs) make it possible. Code in Java, bind to real HTML templates, compose your app out of reusable HTML components, style with CSS. All the benefits of the modern web, with a single strongly-typed language top-to-bottom.
* TeaVM: https://teavm.org
* Real 5-letter word app made with TeaVM/Flavour: https://frequal.com/wordii/
* Migration Guide from Swing to TeaVM: https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV...
* Java Magazine article on TeaVM: https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
Bottom line today if you can't deliver your app on the web only, you will most likely end up at best with:
- An Electron (Desktop) app
- An React Native Mobile app (that needs to be delivered through both Google & Apple proprietary channels)
Whether you loved or hated Java the language, it is hard to deny we ended up in a terrible place:
- We lost all freedom on mobile
- We rely way too much on Blink & Webkit
- We traded Java for Javascript
- It's still relatively slow
- We haven't fixed the security problem on desktop
- Devs now have to manage a lot more technologies & moving parts
- An Electron (Desktop) app
- An React Native Mobile app (that needs to be delivered through both Google & Apple proprietary channels)
Whether you loved or hated Java the language, it is hard to deny we ended up in a terrible place:
- We lost all freedom on mobile
- We rely way too much on Blink & Webkit
- We traded Java for Javascript
- It's still relatively slow
- We haven't fixed the security problem on desktop
- Devs now have to manage a lot more technologies & moving parts
On the other hand Minecraft is the best-selling PC video game of all time and it was originally written in Java and the Java client is the definitive experience of the game.
There's also Project Zomboid. Which doesn't really come close to Minecraft, but it's also developed in Java with a Lua engine on top.
Why? Well, I have absolutely no clue...
Why? Well, I have absolutely no clue...
Heh, thanks for bringing that to my attention; based on the video alone, I think that'd be right up my alley (linky-linky: https://www.gog.com/game/project_zomboid and it's on Steam, too, if you're into that)
> Why?
From the GOG page:
Works on: Windows (10, 11), Linux (Ubuntu 16.04, Ubuntu 18.04), Mac OS X (10.9.0+)
is almost certainly "why," and I'd guess the lua part is because it seems to be the lingua franca of game modding, so meet folks where they are
> Why?
From the GOG page:
Works on: Windows (10, 11), Linux (Ubuntu 16.04, Ubuntu 18.04), Mac OS X (10.9.0+)
is almost certainly "why," and I'd guess the lua part is because it seems to be the lingua franca of game modding, so meet folks where they are
Lua is very common - the OpenComputers mod for Minecraft exposes a Lua machine.
not really a desktop app though, is it?
And Minecraft is also a notable outlier. Outside of mobile, there are very few games written in java on PC or consoles.
And Minecraft is also a notable outlier. Outside of mobile, there are very few games written in java on PC or consoles.
Minecraft is an application which runs on the desktop... I don't see what you mean.
It's a game. It's UI is full screen and completely divorced from "standard" UI elements (WIMP, etc).
You can call it a desktop app, and you'd be correct in the most pedantic sense, but then every web app is also a desktop app since you run it on a desktop.
You can call it a desktop app, and you'd be correct in the most pedantic sense, but then every web app is also a desktop app since you run it on a desktop.
Chrome the browser is a desktop application, websites you visit in it are not.
That's right let's not forget about the famous Ruby and Javascript desktop games that have outsold Minecraft...
Limewire tho
How is it not a desktop app? Millions play it on their desktop.
Still, not really in the sense of the article - he's talking about desktop apps like word processors or email clients: Minecraft's GUI is just a big canvas that the 3D renderer renders into. It's not using any windowing components - IIRC, even the menu and buttons were custom.
Minecraft can pop up GUI windows but even mods rarely do it.
Running a server without nogui gets a window also.
Running a server without nogui gets a window also.
Let's not exclude Runescape, when it was a java applet back in the early 2000's.
Many things you don't know are Java are and they are VERY widely used.
Java simply wont go away because it works.
For serverside it's a nobrainer, but also for client if you have a niche consumer base.
Average joes don't understand the overhead of writing native applications and they are paying for it without knowing.
Here is my only contribution to the "desktop" Java eco system: http://move.rupy.se/file/logic.html
It has worked flawlessly on Windows, Linux and Macs for over 15 years.
Java simply wont go away because it works.
For serverside it's a nobrainer, but also for client if you have a niche consumer base.
Average joes don't understand the overhead of writing native applications and they are paying for it without knowing.
Here is my only contribution to the "desktop" Java eco system: http://move.rupy.se/file/logic.html
It has worked flawlessly on Windows, Linux and Macs for over 15 years.
Java is an amazing platform and language. If not Java itself then Kotlin and the JVM. I think it’s underrated and I wish people would bring back web and mobile support so it can be truly cross-platform.
Web support... I think there may be WASM compilers for Java, but there's still going to be a lot of overhead.
Mobile, there's Android... or did you not realize that's Java?
Mobile, there's Android... or did you not realize that's Java?
There is TeaVM which runs java byte code as efficient javascript or wasm. But Google also has j2cl which can compile java to very efficient javascript code.
As for android, well, let’s just say that android java is not real java.
As for android, well, let’s just say that android java is not real java.
My desktop text editor[1] is written using JavaFX and leans on Warp Packer[2] to create installer-free, multi-platform executable binaries (without jlink). A user contributed a new dark theme[3], which blends nicely with the desktop.
The JavaFX-based WebView (an HTML rendering component) is lauded, but has no direct API to control the scroll position and is itself a memory hog. Scrolling must be handled through JavaScript, and that indirection is as unwieldy as you can probably imagine. FlyingSaucer is a workable alternative to WebView, but comes with numerous technical issues that rear themselves when embedding a Swing widget inside a JavaFX application---as I discovered during development.
Were I to start from scratch, I would definitely seek out alternative cross-platform programming languages for desktop application development. The JavaFX event-based model is top-notch, but there are too many technical gremlins to make implementation a smooth ride. (Such as improper handling of Alt+Tab, which leaves focus on the menu bar when returning to the application[4].)
[1]: https://github.com/DaveJarvis/keenwrite
[2]: https://github.com/dgiagio/warp
[3]: https://i.ibb.co/QpqS0NS/screenshot.png
[4]: https://stackoverflow.com/q/65765656/59087
The JavaFX-based WebView (an HTML rendering component) is lauded, but has no direct API to control the scroll position and is itself a memory hog. Scrolling must be handled through JavaScript, and that indirection is as unwieldy as you can probably imagine. FlyingSaucer is a workable alternative to WebView, but comes with numerous technical issues that rear themselves when embedding a Swing widget inside a JavaFX application---as I discovered during development.
Were I to start from scratch, I would definitely seek out alternative cross-platform programming languages for desktop application development. The JavaFX event-based model is top-notch, but there are too many technical gremlins to make implementation a smooth ride. (Such as improper handling of Alt+Tab, which leaves focus on the menu bar when returning to the application[4].)
[1]: https://github.com/DaveJarvis/keenwrite
[2]: https://github.com/dgiagio/warp
[3]: https://i.ibb.co/QpqS0NS/screenshot.png
[4]: https://stackoverflow.com/q/65765656/59087
Wow, someone is still using Flying Saucer? That brings back such memories. I'm glad to know it helped some people.
The issue with java was users don't care about write once/run anywhere. They care about the program running perfectly on their OS of choice i.e. the java program better look and perform just like a native program (and who can blame them?!).
I run tuxguitar once in awhile and it still gets multiple monitors wrong which makes reading music sheets awful by default. (the "fix" is to hard code a resolution in a startup config file which is awful ux).
I run tuxguitar once in awhile and it still gets multiple monitors wrong which makes reading music sheets awful by default. (the "fix" is to hard code a resolution in a startup config file which is awful ux).
I don't think so. In reality people don't care about native feel, they care about it looking good, working well and doing what they want.
Sure, the problem is - Java apps did neither.
Looking good? The default Swing metal theme was truly awful. It was possible to switch to Windows-like theme, but it was even more awful - it had plenty of visual glitches and things misplaced by a few pixels it couldn't even use the native file selector window.
Working well? Startup times and performance was terrible compared to native apps, and memory usage is still abysmal. And you got occasional GC pauses even in well optimised apps. I still sometimes run into occasional lags in Idea, even though Jetbrains did a lot of great work to polish the user experience.
Doing what they want? That depends on the programmer, but, besides developer utilities like IDEs, I can't think of a Java app that didn't have a better looking and more polished native competition.
Looking good? The default Swing metal theme was truly awful. It was possible to switch to Windows-like theme, but it was even more awful - it had plenty of visual glitches and things misplaced by a few pixels it couldn't even use the native file selector window.
Working well? Startup times and performance was terrible compared to native apps, and memory usage is still abysmal. And you got occasional GC pauses even in well optimised apps. I still sometimes run into occasional lags in Idea, even though Jetbrains did a lot of great work to polish the user experience.
Doing what they want? That depends on the programmer, but, besides developer utilities like IDEs, I can't think of a Java app that didn't have a better looking and more polished native competition.
I didn't claim they did ...
Yep, I have loads of stuff running atm and most native looking thing on my Windows desktop are Notepad++ and FreeCommander. VScode - no, Intellij IDEA - no, any of the chat apps - no, Firefox - no, Lightroom - no.
Does it bother me - also no.
Native look has lost its meaning long time ago.
Native look has lost its meaning long time ago.
Java on desktop in 2022 seems like a lost cause. It's always slow and hogs resources like crazy. A good example is all the Jetbrains IDE's. Try running any of them on a low powered laptop and you end up having a bad time.
Luckily there seems to be a push for fully native.
Luckily there seems to be a push for fully native.
How is that a relevant benchmark? It’s like claiming that c++ is “slow” because look at the memory consumption of this program calculating some big-ass weather model on a cluster of machines..
Intellij does a shit load of thing, caches your files, constantly monitors for changes, etc. It is not vim written in java.
Intellij does a shit load of thing, caches your files, constantly monitors for changes, etc. It is not vim written in java.
Like everything, IntelliJ got increasingly bloated, at a faster rate than the progress in CPU performance.
I've got a desktop machine from around 2010 with 32-bit OS, Core i5 760 (510 / 1611 point in geekbench single/multithreaded) and 4 Gb RAM, runs my current Java code in IntelliJ from those times at blazing speed. Modify a line of code and run in debug, it's up an running in less than a second.
Same code on a 2018-ish laptop, 64-bit OS, 16 Gb RAM, i7 6700 HQ (798 / 3073 in geekbench) and latest IntelliJ takes up to 10 seconds to start.
It's not "Java", it's bloat.
I've got a desktop machine from around 2010 with 32-bit OS, Core i5 760 (510 / 1611 point in geekbench single/multithreaded) and 4 Gb RAM, runs my current Java code in IntelliJ from those times at blazing speed. Modify a line of code and run in debug, it's up an running in less than a second.
Same code on a 2018-ish laptop, 64-bit OS, 16 Gb RAM, i7 6700 HQ (798 / 3073 in geekbench) and latest IntelliJ takes up to 10 seconds to start.
It's not "Java", it's bloat.
C++ ides do cache files and monitor for changes too but they are much more useable on low-end hardware than anything Java.
Citation and meaningful comparative ananlysis needed here. I would want to be certain you are not making a comparison with powerful text editors like Slickedit or Emacs - these are not the same.
At the scale that something like IntelliJ or your favourite C++ based IDE operate at, Java is not the bottleneck. It’s all down to the system complexity involved in doing all that code crunching in near real time and the integration with various back ends and plugins that causes the lag.
I have used many a native IDE in my time and they’ve all been pretty horrid, and to me Intellij is probably the best of them. At this scale of complexity I think the tightly structured and predictable environment provided by Java actual helps performance as it’s easier to maintain and design a cohesive scalable application.
At the scale that something like IntelliJ or your favourite C++ based IDE operate at, Java is not the bottleneck. It’s all down to the system complexity involved in doing all that code crunching in near real time and the integration with various back ends and plugins that causes the lag.
I have used many a native IDE in my time and they’ve all been pretty horrid, and to me Intellij is probably the best of them. At this scale of complexity I think the tightly structured and predictable environment provided by Java actual helps performance as it’s easier to maintain and design a cohesive scalable application.
I'm mainly using Qt Creator, which has integrated on-the-fly code analysis with clangd for instance and I guess most of what you'd expect from a modern IDE, many refactorings, various unit test system integrations, SSH support...
When trying CLion on the exact same projects everything is just so much slower with no major value-add, like, even opening UI menus feels sluggish. And let's not even talk about typing text, I feel like I'm fighting my keyboard whenever I try to use it. (My computer is an Intel 6900k with 64 GB of RAM to give a point of reference)
When trying CLion on the exact same projects everything is just so much slower with no major value-add, like, even opening UI menus feels sluggish. And let's not even talk about typing text, I feel like I'm fighting my keyboard whenever I try to use it. (My computer is an Intel 6900k with 64 GB of RAM to give a point of reference)
QtCreator does a tiny fraction of what Intellij is capable of though. Also, clion is not nearly as used as intellij, which is (only slightly arguably ) the best ide hands down for java and many other languages.
> Luckily there seems to be a push for fully native.
Really? I thought there was a push for Electron/Chromium everywhere (which seems comparable or worse than desktop Java...)
Really? I thought there was a push for Electron/Chromium everywhere (which seems comparable or worse than desktop Java...)
I think Electron is neither here nor there. It is the "stroad" of software distribution: the sluggishness and poor performance of a web interface, coupled with the difficulty to upgrade of a desktop package.
Personally I push for either native apps or web apps, to regain at least one of the benefits lost by packaging web apps.
Personally I push for either native apps or web apps, to regain at least one of the benefits lost by packaging web apps.
> coupled with the difficulty to upgrade of a desktop package
Huh? Two Electron apps that I use are Github Desktop and VSC. Neither is sluggish and both have streamlined automatic updates.
Huh? Two Electron apps that I use are Github Desktop and VSC. Neither is sluggish and both have streamlined automatic updates.
> streamlined automatic updates
Sure, from the user's perspective. But from the provider's perspective, there is a lot of infrastructure needed to reliably and automatically update on various platforms.
Compiling files per-platform, hosting them securely, checking checksums, binary self-replacement, settings migration for many possible settings...
Compare with deploying the server code, migration only for one data set (the one on the server), and then hitting refresh in a web browser.
Sure, from the user's perspective. But from the provider's perspective, there is a lot of infrastructure needed to reliably and automatically update on various platforms.
Compiling files per-platform, hosting them securely, checking checksums, binary self-replacement, settings migration for many possible settings...
Compare with deploying the server code, migration only for one data set (the one on the server), and then hitting refresh in a web browser.
Is slowness of intelliJ IDEs attributable to Java alone? Android studio feels more sluggish than vanilla IntelliJ.
I had to write an app in JavaFX for a course project. Compared to most desktop apps written using electron, it was fine. But by default it looks like an old desktop app, for which you'd expect some more performance. It maybe still good for enterprise apps where you have some Java programmers.
Also, startup time; It had some noticeable delay.
I tried flutter recently; If you ignore that apps look like mobile apps, flutter desktop apps feel more responsive.
As for paradigm, recent UI-in-code frameworks like flutter seem superior. In JavaFX you can write Widgets in code or in FXML, but java the language or APIs don't fit into that paradigm like Flutter does.
I had to write an app in JavaFX for a course project. Compared to most desktop apps written using electron, it was fine. But by default it looks like an old desktop app, for which you'd expect some more performance. It maybe still good for enterprise apps where you have some Java programmers.
Also, startup time; It had some noticeable delay.
I tried flutter recently; If you ignore that apps look like mobile apps, flutter desktop apps feel more responsive.
As for paradigm, recent UI-in-code frameworks like flutter seem superior. In JavaFX you can write Widgets in code or in FXML, but java the language or APIs don't fit into that paradigm like Flutter does.
changing the garbage collector to G1GC and / or not using JDK11 as the boot java improves matters. JetBrains seems refuse to admit there is a problem. Hopefully things get better when they move to JDK17.
But yes, for the past few years, the experience latency-wise is garbage.
But yes, for the past few years, the experience latency-wise is garbage.
IIRC, Java had difficulties during the late 90's and early 2000's for advanced desktop applications mostly because of performance. As time passed, although jvm implementation's performance improved, so did C++, multi-platform frameworks and other programming languages. Other phenomenons also occurred: Linux continued with a very small fraction and the desktop effectively turned into a duopoly of windows and mac and new developers shifted to web and mobile. You can clearly see that there are very few examples of new desktop packages that thrived recently, specially compared to mobile and web equivalents.
The development of the described scenario strongly devalued java's most advertised advantage, which was portability.
The development of the described scenario strongly devalued java's most advertised advantage, which was portability.
I am not sure that was the problem, The way I recall it:
The apps were typically pretty ugly and Windows had a near monopoly at the time. If either of those were not true, it might have fared better.
The apps were typically pretty ugly and Windows had a near monopoly at the time. If either of those were not true, it might have fared better.
Swing default appearance may look alien on windows, but I remember a demonstration from a friend of mine where he turned it to native appearance with a few clicks. You can see some successful java desktop apps with native UI, one I remember is utorrent. Also, windows users are very used, specially at the time, to inconsistent appearance. So, I don't think default appearance on windows had anything to do with java's decline there.
uTorrent is definitely NOT Java --- the binary itself is a few orders of magnitude smaller than a JVM! You might be thinking of Azureus (since renamed Vuze)?
Hell, windows has like 6 actually native looks at the same time still running next to each other, often with duplicated functionality..
I've made a few desktop apps in https://github.com/cljfx/cljfx (e.g., https://www.chronos-desk.com/), and cljfx (JavaFX + Clojure) is amazing and makes for rapid development, not to mention fun. I'm keeping an eye on https://github.com/HumbleUI/HumbleUI, which promises to be a step up.
Neat. I hadn't heard of either of those before (though I'm not a Clojure developer). Thanks for sharing.
>> This history is neither meant to be comprehensive, nor necessarily chronological. I’m recounting my own journey through the Java desktop landscape, and it will be biased towards Mac
This paragraph should really be right in the beginning of the post, instead of in the conclusion.
This paragraph should really be right in the beginning of the post, instead of in the conclusion.
So that must be why he didn't mention microsft, windows, C# and .Net. Hard to take the article seriously when he ignored 95% of the actual desktop market.
Not to mention Sun's failure with their java based OS and its own eventual collapse.
https://www.wsj.com/articles/SB891383840659892000
Java is still a major language worth learning, but yeah, it never lived up to its hype. When I was young, I remember asking in one of the forums whether I should learn Java or C#, perl or python. The answers were overwhelmingly java and perl. So java and perl were the first two languages I learned on my own. No regrets, but man the internet at the turn of the century/millenia really got that spectacularly wrong.
Not to mention Sun's failure with their java based OS and its own eventual collapse.
https://www.wsj.com/articles/SB891383840659892000
Java is still a major language worth learning, but yeah, it never lived up to its hype. When I was young, I remember asking in one of the forums whether I should learn Java or C#, perl or python. The answers were overwhelmingly java and perl. So java and perl were the first two languages I learned on my own. No regrets, but man the internet at the turn of the century/millenia really got that spectacularly wrong.
The company I work for is happily delivering Java Swing desktop apps every day.
Works great, easy to debug, tons of open-source components to plug in when we need, sufficiently performant, thoroughly battle tested.
And these are medium update rate apps, not games, but not static forms either.
Works great, easy to debug, tons of open-source components to plug in when we need, sufficiently performant, thoroughly battle tested.
And these are medium update rate apps, not games, but not static forms either.
I think Java had a bad reputation on desktop for a long time. Every application I remember using back in the day was extremely sluggish, felt like a skinwalker with regards to UI, and hogged memory.
Wasn't that bittorrent client early mid-2000s with the blue frog logo written in Java? I think I remember the author back then saying something like, "it's just a project I started to try out [some new java gui library]". I don't seem to remember speed issues using it.
You mean Vuze (back then it was called Azureus).
https://en.m.wikipedia.org/wiki/Vuze
https://en.m.wikipedia.org/wiki/Vuze
Not just Java, there's been a decline of desktop apps in general.
It's kind of ironic, because most of our apps are now running in an even slower language with "Java" in the name (JavaScript)
It's kind of ironic, because most of our apps are now running in an even slower language with "Java" in the name (JavaScript)
I find this such a shame. I think this reflects an increasingly consumer versus producer aspect of culture. I find that desktop apps support and foster creativity, and producing readily manipulable creative artifacts - with speed. Sass/webapps/etc tend to foster consumer-oriented, indeed mobile, usage, creation and creative operations are often subtly high-latency and subsequently & so are tacitly discouraged while consumption is encouraged.
I love the pitch found in https://www.inkandswitch.com/local-first/, but it doesn't seem like it's resonated much in the large - so far, at least.
I love the pitch found in https://www.inkandswitch.com/local-first/, but it doesn't seem like it's resonated much in the large - so far, at least.
In a way, desktop apps themselves declined - right now, besides the browser I'm using, I only have an IDE and an email client open (and I'm a bit of an oddball for not using the webmail client as well). Most of the corporate desktop apps that would have been written in Java in the 90's have long since been migrated to the web.
A Steve Jobs quote: "We want to bring Java back to the desktop in a really big way. I'm here today to personally tell you we are working hard to make Mac the best Java delivery vehicle on the planet. The biggest thing we are doing is we are going to bundle Java 2 SE into every single copy of Mac OS X the upcoming Macintosh operating system that we ship later on this year."
Apparently, he changed his mind around OSX 10.5 and just removed it.
Apparently, he changed his mind around OSX 10.5 and just removed it.
Apple went all in on Java, but the developers didn't follow.
The unusual syntax of Objective-C was always seen as a hinderance to OpenStep/Cocoa adoption, and Java was seen as the solution to that problem.
But Java wasn't a perfect fit for AppKit development, and once developers wrapped their heads around Objective-C most of them stuck with it rather than deal with Java/Cocoa idiosyncrasies. With few developers, the Java/Cocoa bridge died.
The unusual syntax of Objective-C was always seen as a hinderance to OpenStep/Cocoa adoption, and Java was seen as the solution to that problem.
But Java wasn't a perfect fit for AppKit development, and once developers wrapped their heads around Objective-C most of them stuck with it rather than deal with Java/Cocoa idiosyncrasies. With few developers, the Java/Cocoa bridge died.
I never really understood why, but I can guess. Could have been political/strategic, to try to force developers onto Objective-C. Or his keen attention to detail might have just bristled at some of the performance an UI issues that many of the Java apps had at the time.
The article ends right where my knowledge drops off, so I'm waiting for part two.
The piece did remind me of the poor Java performance at the turn of the century. If you thought it was bad on a Sun or Wintel, you would have really enjoyed the SGI Irix port I tried to make use of at the time. It was even more unoptimized than the common platforms. :D
I remember typing into a Swing? text field and the keystrokes not registering for a second or three, basically unusable. Made me stick with AWT for a chat client/server I'd created for learning purposes, which was not quite so bad. Shortly after that I found Python, which was a breath of fresh air at the time and didn't write another line of Java for about 15 years, never again for Perl.
The piece did remind me of the poor Java performance at the turn of the century. If you thought it was bad on a Sun or Wintel, you would have really enjoyed the SGI Irix port I tried to make use of at the time. It was even more unoptimized than the common platforms. :D
I remember typing into a Swing? text field and the keystrokes not registering for a second or three, basically unusable. Made me stick with AWT for a chat client/server I'd created for learning purposes, which was not quite so bad. Shortly after that I found Python, which was a breath of fresh air at the time and didn't write another line of Java for about 15 years, never again for Perl.
Lately I've been working on improving the performance of an open-source HD graphics plugin for the 21 year old Java game oldschool runescape. I have to say it's completely amazing what this ancient Java code has achieved. Reflection allowed the community to build the client they wanted without needing the company to open source the vanilla client and it runs natively on Windows, Linux, and Mac (Intel and M1). It's also ridiculously fast considering how many layers of abstraction we have piled on top of one another. The only thing that sucks is the way parallelism/concurrency works. It's clunky, race conditions are common and hard to manage, there's a ton of overhead, etc.
A little off topic -> I was reading the comments about learning to code through Java.
A lot of people are against C/C++ and majority of schools uses Java/Python nowdays.
Ofc the language at the end doesn't really matters, but I am conviced ( mostly because I only embrace MY learning experience ) that using a language like C helps you get into the programming mindset better.
I mean, you don't need to understand what a smart pointer is, but once you seen that the object you have created in your own implementation of a vector got copied over and over, you will think twice every time you write a function with a return statement in every language for the rest of your life.
Ofc the language at the end doesn't really matters, but I am conviced ( mostly because I only embrace MY learning experience ) that using a language like C helps you get into the programming mindset better.
I mean, you don't need to understand what a smart pointer is, but once you seen that the object you have created in your own implementation of a vector got copied over and over, you will think twice every time you write a function with a return statement in every language for the rest of your life.
For its time, Java Swing was a really nice toolkit, and really impressive in its cross platform capabilities. That you could develop a UI directly with code without having to rely on a design file, IDE, or separate tool was very impressive to me.
From a dev perspective, absolutely.
From a user perspective, no. Every Swing app I've ever used has been ugly, slow and painful. Now, that might be the fault of the developer, but at some point, you have to wonder if either all Swing devs are terrible or Java UIs are just very difficult to get right.
From a user perspective, no. Every Swing app I've ever used has been ugly, slow and painful. Now, that might be the fault of the developer, but at some point, you have to wonder if either all Swing devs are terrible or Java UIs are just very difficult to get right.
My experience with many Swing apps is the same. I think a large part of the problem lay with the development tools. When you create a new Cococa project in Xcode, it generates a full app with all the necessary parts to feel native. You build it, you have a functioning hello world app with your "File" menu, etc...
In Java, when you create a new Swing app, the IDE (by default) just creates an empty main() method for you. You're expected to create your own menus and windows. Trying to make the app "native" requires a significant amount of work.
In Java, when you create a new Swing app, the IDE (by default) just creates an empty main() method for you. You're expected to create your own menus and windows. Trying to make the app "native" requires a significant amount of work.
I still rate the layout managers in Swing above anything I've ever experienced with .NET: made it super-easy to build resizeable GUIs compared to, for example, the absolute positioning dumbassery of something like Windows Forms. Flexbox nailed it for the web but it was something like 18 years later before it was consistently implemented across all browsers.
Java's only claim to fame is that's the granddaddy of C#, a far superior language and IMHO one of the greatest computer languages ever created.
In addition, Java was ahead of its time, with mid-1990's computing power not up to the job of letting it run smoothly on lower and mid-tier PC's. It also required, for that time, an egregious amount of RAM memory.
In addition, Java was ahead of its time, with mid-1990's computing power not up to the job of letting it run smoothly on lower and mid-tier PC's. It also required, for that time, an egregious amount of RAM memory.
I've spent 3 years with C# professionally and greatly enjoyed them. That being said "one of the greatest computer languages ever created" is a bit of a stretch. Yes, it has a lot of nice features, relatively good ergonomy and in recent years, its openness has increased its viability a lot, but still. It's neither particularly innovative, nor does it allow you to do things you otherwise couldn't. It's no Erlang, Haskell, Assembly or something like that. It didn't pave the way for something like PHP did for the web backend or JS for the web frontend.
Also, I really apologize for nitpicking, but "RAM memory" is a tautology.
Also, I really apologize for nitpicking, but "RAM memory" is a tautology.
C# is a "standing on the shoulders of giants" kinda language IMO; they learned a lot from Java and evolved on it, mainly in terms of developer ergonomics and features that makes their life easier and less tedious. They had less of a design-by-committee team behind it as well, making development a LOT faster than Java, which feels like it's run by ancient, slow moving behemoth companies like Oracle and IBM. I mean I get it, they have tens if not hundreds of millions of LOC and thousands of developers working with it, they had to be conservative, but it didn't do the language much good, and after a few years, IMO C# raced past Java in terms of 'fun to work with'.
The downside is that until .NET Core, C# was a closed shop; by Microsoft, for Windows, and everything needs to be licensed. Whereas Java embraced more of the open source and freedom of choice mentality.
The downside is that until .NET Core, C# was a closed shop; by Microsoft, for Windows, and everything needs to be licensed. Whereas Java embraced more of the open source and freedom of choice mentality.
> C# raced past Java in terms of 'fun to work with'.
I agree that language-wise, C# is definitely ahead. But just a heads up that I think it is also dangerously going towards the fate of C++ (or even already there) where no one person can hold the whole language in their head, and new but not learnt features might introduce problems down the line. For a language, what gets implemented is an important question but perhaps what doesn’t get is even more important, and Java (after the stagnation at the end of Sun) is a slow-mover but when they do, it is usually the best direction/approach. For an example, C# chose (even created afaik) async which is a good feature, but arguably a runtime language could have got away without any new feature and implement it in the runtime alone, a la project loom in java.
I agree that language-wise, C# is definitely ahead. But just a heads up that I think it is also dangerously going towards the fate of C++ (or even already there) where no one person can hold the whole language in their head, and new but not learnt features might introduce problems down the line. For a language, what gets implemented is an important question but perhaps what doesn’t get is even more important, and Java (after the stagnation at the end of Sun) is a slow-mover but when they do, it is usually the best direction/approach. For an example, C# chose (even created afaik) async which is a good feature, but arguably a runtime language could have got away without any new feature and implement it in the runtime alone, a la project loom in java.
Many .NET tools are still Windows only to this day.
.NET is only open source up to the point that Azure related workloads, and iOS/Android development can be done from non-Windows platforms.
Even for basic stuff like visualizing trace files, you still need to reach out to either Visual Studio proper or Perfview.
.NET is only open source up to the point that Azure related workloads, and iOS/Android development can be done from non-Windows platforms.
Even for basic stuff like visualizing trace files, you still need to reach out to either Visual Studio proper or Perfview.
Java was open-source, but not free. Oracle tries everything to squeeze every last penny out of a company if they use Java or MySQL, including threatening with litigation.
If Oracle can't make humongous profits from a product they simply drop it or run it into the ground.
If Oracle can't make humongous profits from a product they simply drop it or run it into the ground.
That’s why they completely open-sourced it and recently made even LTS-support of OracleJDK free of charge until the next LTS?
Sure, they do make plenty of money from huge corporations still going with paid support for java 8 (I believe it will be supported till 2030 at least?!), like banks. But it ain’t a crime to ask money for proper services.
Sure, they do make plenty of money from huge corporations still going with paid support for java 8 (I believe it will be supported till 2030 at least?!), like banks. But it ain’t a crime to ask money for proper services.
C# is Java done right.
Nothing special really, it shines only when compared to other mediocre scripting language we use nowadays.
Performance wise it's still on the heavy side.
As a user I hate both Java e C# desktop app.
Nothing special really, it shines only when compared to other mediocre scripting language we use nowadays.
Performance wise it's still on the heavy side.
As a user I hate both Java e C# desktop app.
I only hate it because there's no support for AOT (ahead of time) compilation and it needs a runtime.
A native code compiled, statically linked Java or C# desktop app would be the ultimate C++ killer. It would also lessen the need for languages such as Rust.
A native code compiled, statically linked Java or C# desktop app would be the ultimate C++ killer. It would also lessen the need for languages such as Rust.
Some of the new LookAndFeels for Swing are really slick. Take a look, for instance, at FlatLaf:
https://github.com/JFormDesigner/FlatLaf
https://github.com/JFormDesigner/FlatLaf
The ability to switch LookAndFeels is one of my favourite features of Swing. Lately I've found myself using the Motif one a lot for my tiny personal projects, although copy&paste doesn't seem to work on its text boxes and that's very annoying. I usually make it so I can configure it an change it on the fly. Trying all the possibilities is kind of satisfying.
Java gets a lot of hate but it's a language I really like. The only real issue I had with it is its memory consumption. As a developer, it still has some warts like the absence of actual generics (autoboxing is an ugly hack), but when I compare it with other languages' warts, they are usually uglier. Although my preferred usage of Java is mostly reduced to mathematical or algorithmic stuff, with little to no external libraries, and it certainly doesn't include Spring or any other annotation-heavy framework.
As a user I also definitely prefer Java to Electron and most modern frameworks. Then again I hate most modern design trends...
Java gets a lot of hate but it's a language I really like. The only real issue I had with it is its memory consumption. As a developer, it still has some warts like the absence of actual generics (autoboxing is an ugly hack), but when I compare it with other languages' warts, they are usually uglier. Although my preferred usage of Java is mostly reduced to mathematical or algorithmic stuff, with little to no external libraries, and it certainly doesn't include Spring or any other annotation-heavy framework.
As a user I also definitely prefer Java to Electron and most modern frameworks. Then again I hate most modern design trends...
The main problems with Java on the desktop were:
- Obviously non-native look and feel. For many years Java apps didn't even use the system font. At a time when everything was on Windows and its UI was actually reasonably coherent, Java apps stood out as out of place and clunky.
- Deployment. Each user needed to first install the Java runtime from Sun. This was a deliberate strategy by Sun to get the runtime in place on as many desktops as possible, but it failed colossally. It would have been better to just bundle the whole thing with each app, as Electron does today.
- Obviously non-native look and feel. For many years Java apps didn't even use the system font. At a time when everything was on Windows and its UI was actually reasonably coherent, Java apps stood out as out of place and clunky.
- Deployment. Each user needed to first install the Java runtime from Sun. This was a deliberate strategy by Sun to get the runtime in place on as many desktops as possible, but it failed colossally. It would have been better to just bundle the whole thing with each app, as Electron does today.
> At a time when everything was on Windows and its UI was actually reasonably coherent
Hmm... no. Even ms software on windows had different appearance and behavior. Actually, being a mostly proprietary ecosystem, apps tried to be different from one another to get attention. An xp machine running winamp, corel draw, ms office, windows messenger and internet explorer had 5 different themed apps at the same time and it was common at the time; it was the rule.
Consistency on windows was always a problem.
Hmm... no. Even ms software on windows had different appearance and behavior. Actually, being a mostly proprietary ecosystem, apps tried to be different from one another to get attention. An xp machine running winamp, corel draw, ms office, windows messenger and internet explorer had 5 different themed apps at the same time and it was common at the time; it was the rule.
Consistency on windows was always a problem.
Cross platform used to mean, windows, mac, and linux. These days it is web, ios, android, windows, mac, and linux. In that order. And that's before you consider TVs, cars, and other equipment where apps are also relevant.
These days web is the new cross platform technology. It works everywhere. And mobile is where people focus for native apps. Windows is an afterthought at best. Mac even more. And Linux oddly is now a main source of open source applications that also work on windows and mac. But it's not a big market.
Unless you consider Android a linux distribution. In that case it's absolutely huge. And Java/Kotlin are the languages of choice on that platform. But they are compiled to native ahead of time so don't require a JVM.
Otherwise, Applet support for browsers died a long time ago so that blocked Java from being useful on the web. The JVM as distributed by Oracle (and other openjdk packagers) only really covers the traditional three desktop platforms. And it's not really native there and kind of heavy weight. That limits the appeal. Java is not really that cross platform anymore. Sun failed to anticipate and survive the move to smartphones. Up until then J2ME was a thing. These days almost no phone comes with Java support. That's the real reason Java usage on the desktop declined. It did not cover new platforms from about 2007 onwards.
Despite this there's a new JVM framework on the block: compose desktop. It uses skia (like flutter) and there's a mobile variant supported by Google called jetpack compose. And a web variant called compose web. IOS support is missing. But that looks like it might be addressed at some point.
These days web is the new cross platform technology. It works everywhere. And mobile is where people focus for native apps. Windows is an afterthought at best. Mac even more. And Linux oddly is now a main source of open source applications that also work on windows and mac. But it's not a big market.
Unless you consider Android a linux distribution. In that case it's absolutely huge. And Java/Kotlin are the languages of choice on that platform. But they are compiled to native ahead of time so don't require a JVM.
Otherwise, Applet support for browsers died a long time ago so that blocked Java from being useful on the web. The JVM as distributed by Oracle (and other openjdk packagers) only really covers the traditional three desktop platforms. And it's not really native there and kind of heavy weight. That limits the appeal. Java is not really that cross platform anymore. Sun failed to anticipate and survive the move to smartphones. Up until then J2ME was a thing. These days almost no phone comes with Java support. That's the real reason Java usage on the desktop declined. It did not cover new platforms from about 2007 onwards.
Despite this there's a new JVM framework on the block: compose desktop. It uses skia (like flutter) and there's a mobile variant supported by Google called jetpack compose. And a web variant called compose web. IOS support is missing. But that looks like it might be addressed at some point.
> And that's before you consider TVs, cars, and other equipment where apps are also relevant.
Are TV apps really relevant anymore? Chromecast and other similar technologies killed TV apps for me for good.
Are TV apps really relevant anymore? Chromecast and other similar technologies killed TV apps for me for good.
> That said, we’re roughly circling around the year 2005, which, arguably was a turning point for Java on the desktop. Before 2005, there are lots of questions and answers in online forums about Java desktop technologies like Swing, Cocoa bridge, etc…. After 2005, there really isn’t much. What happened in the years leading up to 2005, or perhaps in 2005 specifically that caused this blackout? Where did all of the Java desktop developers go? Likely many of them moved to the server-side, and the ones who stayed on the client likely shifted their attention to the web, or to native development.
Could it be the release of Gmail (2004) and Google Maps (2005) showing that you could actually make really great apps written in HTML and JavaScript? For me, these two webapps were turning points in how the web was looked at. As I remember it, things didn't really take off until frameworks like AngularJS were released around 2010.
Could it be the release of Gmail (2004) and Google Maps (2005) showing that you could actually make really great apps written in HTML and JavaScript? For me, these two webapps were turning points in how the web was looked at. As I remember it, things didn't really take off until frameworks like AngularJS were released around 2010.
> Could it be the release of Gmail (2004) and Google Maps (2005) showing that you could actually make really great apps written in HTML and JavaScript?
For the mass consumer market, these apps definitely demonstrated what was possible with web-technologies.
Ironically, Google Maps' dataset is curated in no small part by a powerful Java-based desktop app called Atlas, which was presented at Google I/O 2013:
https://youtu.be/FsbLEtS0uls?t=443
Perhaps today it would be created with web based technologies, but at this point, it's so powerful that it's doubtful it will ever be ported. I suspect there are a lot of powerful internal tools like that across many industries.
For the mass consumer market, these apps definitely demonstrated what was possible with web-technologies.
Ironically, Google Maps' dataset is curated in no small part by a powerful Java-based desktop app called Atlas, which was presented at Google I/O 2013:
https://youtu.be/FsbLEtS0uls?t=443
Perhaps today it would be created with web based technologies, but at this point, it's so powerful that it's doubtful it will ever be ported. I suspect there are a lot of powerful internal tools like that across many industries.
As I see it, Java succeeded where it was needed, and in the mid-late 90's, that was on the server. When the web emerged, there was no well established development environment for server based applications. The tools for doing much beyond static web pages were pretty limited. Java and a whole bunch of Java based tools emerged to fill this need, and satisfy the needs of corporate customer for intranet solutions.
On the desktop, Microsoft and C++ were already well established. In the browser, Sun did not offer a browser of their own, so Java depended on support from Netscape, Microsoft and eventually Google. Those companies all had their own technologies for browser development tools, and never tried very hard to support Java. Also Java was a little too much for many 90's era PC's connecting to the internet over dial-up connections, so it was slow.
On the desktop, Microsoft and C++ were already well established. In the browser, Sun did not offer a browser of their own, so Java depended on support from Netscape, Microsoft and eventually Google. Those companies all had their own technologies for browser development tools, and never tried very hard to support Java. Also Java was a little too much for many 90's era PC's connecting to the internet over dial-up connections, so it was slow.
> I recall a quote from Steve Jobs around that time that "Java is a giant ball and chain"
The story I've heard from people who were in the room is slightly different. Jobs acknowledged that Java had its place on the server, but on the client-side: "Java is a big fat pig."
The story I've heard from people who were in the room is slightly different. Jobs acknowledged that Java had its place on the server, but on the client-side: "Java is a big fat pig."
Maybe the story is not finished yet. New approaches like JetBrain's Compose (https://www.jetbrains.com/de-de/lp/compose-mpp/) with a React inspired programming model might bring some new interest to the platform. Then there is a Java binding library for Skia (https://github.com/JetBrains/skija), and JavaFX is also alive and high quality.
As everyone is used to fat Electron apps now, Java applications (especially compiled and packed with new JDK features) might be refreshing.
As everyone is used to fat Electron apps now, Java applications (especially compiled and packed with new JDK features) might be refreshing.
Nice to see that Java works pretty well for indie games these days -it's a more pleasant language & ecosystem to work with than C++, and you don't need to deal with Unity's bullshit. Slay The Spire and Mindustry were written in it.
I heard Slay the Spire was also ported to Nintendo Switch. Any idea how they did it?
Nope, I dunno. If I was them I would have just developed the game in Defold or GMS2, tbh, since both of those engines can target mobile and Switch as well as desktop. I would be curious to know why they chose not to do that.
I used to love Java. Although I think they ruined it with the concept of "Enterprise Java" which only complicating how they were delivering the software. Many good things came out of this work that has been ported to many other frameworks (although, not with the enterprise branding)
Java is not slow, I use a couple of high quality desktop applications and these will most likely have a future as long as the language is developed. These are not slow apps. Bad developers make bad software regardless of language.
One of the main things that I always struggled with was the IDE of java. Buggy, slow and overly complicated. I saddens me profoundly that java lost its "je ne sais quoi"
Java is not slow, I use a couple of high quality desktop applications and these will most likely have a future as long as the language is developed. These are not slow apps. Bad developers make bad software regardless of language.
One of the main things that I always struggled with was the IDE of java. Buggy, slow and overly complicated. I saddens me profoundly that java lost its "je ne sais quoi"
Enterprise Java was almost entirely an IBM creation. IBM had a whole bunch of code that had no real path to money (San Francisco framework with roots back to Taligent). Sun was headed into a firefight with MS; they knew it and knew that they didn't have the resources to go it alone: Sun needed a Gorilla partner.
And so a deal was struck and the world was lumbered with the dumpster-fire that was J2EE, against which Spring Framework was a logical (maybe even sensible at the time) reaction but which ended up becoming it's very own brand of behemothic monster.
And so a deal was struck and the world was lumbered with the dumpster-fire that was J2EE, against which Spring Framework was a logical (maybe even sensible at the time) reaction but which ended up becoming it's very own brand of behemothic monster.
Yeah, I used to make some simple games for Java, like for J2ME, and for that it was a pretty good experience. But then I had to use enterprise Java for work and while I could use it, it was such an overcomplicated mess I stopped wanting to use it. I much prefer C#/.Net.
Which IDE do you mean?
Also, fortunately java really doesn’t have to be written in EnterpriseTM way, hell, the language designers actually agree on this one not making properties and the like native, but instead choosing records.
Also, fortunately java really doesn’t have to be written in EnterpriseTM way, hell, the language designers actually agree on this one not making properties and the like native, but instead choosing records.
I'd disagree on the "faith in the power of Moore’s law" part. It was closer to faith in Sun. There were big performance jumps each version from Java 1.3 to 1.6. Some apps became suddenly not terrible.
I've been developing Java desktop app for more than 25 years. I think the problem of the early days was the start up time of Java and the fact that reflection and (de)serialization was causing too much security problems for Applets.
Once the applications started, I don't remember them being slow. Hotjava (1995), JDK applets (1996) or Forte (2001).
The fact that it doesn't look exactly like the OS is not I think a big problem for users. Applications like Google Chrome, Discord and Electron apps don't look native and nobody complains about it.
The fact that it doesn't look exactly like the OS is not I think a big problem for users. Applications like Google Chrome, Discord and Electron apps don't look native and nobody complains about it.
Java's demise on Windows was sealed in 1997 when Sun sued Microsoft. Java remained cross-platform in a technical sense, but couldn't achieve much success on the desktop afterwards.
The only Java desktop app I use regularly is Bitwig, a DAW for music production. At least the UI is written in Java and it's fantastic.
If you want to learn more about its background story,
https://dawbench.libsyn.com/episode-10-daw-evolution-iii-bit...
https://dawbench.libsyn.com/episode-10-daw-evolution-iii-bit...
Thanks! I will listen to it for sure!
It's interesting to note that probably the best selling Java application for desktop is owned and maintained by Microsoft: Minecraft. It's a testament to the technology that they still after all these years have not managed to make a definitive non-Java version that replaces the Java edition outright.
> As new versions of Java were released, and Internet Explorer entered the scene, the HTML code required to embed your applet became increasingly complex, with different tags used for different browsers and versions or Java. The <applet> tag was advertised as the correct way to embed an applet in a “multi-browser” environment, but Internet Explorer used the <object> tag and Mozilla used the <embed> tag.
In the time I was playing around with applets (largely after the dates mentioned in this article, mind you), I don't think I came across any site using applets that didn't stick with <applet>. Using <object>/<embed> might have been more "correct," but this is also fervently an era where trying to enforce "correct" HTML usage was at best an attempt to whip the tide into submission.
In the time I was playing around with applets (largely after the dates mentioned in this article, mind you), I don't think I came across any site using applets that didn't stick with <applet>. Using <object>/<embed> might have been more "correct," but this is also fervently an era where trying to enforce "correct" HTML usage was at best an attempt to whip the tide into submission.
I always found this very confusing. I still do. At one point in time I think I could have explained why there were three tags. But I don't remember the specifics anymore.
> The decline and fall of Java on the desktop
What is this even referring too? Java is everywhere, especially on the desktop. I wouldn't completely contradict and claim "more than ever", but it sure is not on a decline and/or fall. Applets are gone for good, but that's about it.
What is this even referring too? Java is everywhere, especially on the desktop. I wouldn't completely contradict and claim "more than ever", but it sure is not on a decline and/or fall. Applets are gone for good, but that's about it.
In late 00s I've worked on a pretty big system using C++ and Qt3 for desktop ui.
For various reasons we moved to Java SWT. It was so much worse it's not even funny.
Part of it was the absurdly overengineered architecture we used. We moved from 2-layer PL/SQL + C++ app to 3-layer PL/SQL + J2EE + SWT but on SWT there were like 5 additional layers and most of the code was XML configuration on the UI side. That's not Java fault.
But part of it was just SWT API being so much worse than Qt. Signals and slots make observers and listeners look like ancient technology. The graphical design tools were so much better in Qt. The layouts in SWT sucked. Everything was worse and took more work.
For various reasons we moved to Java SWT. It was so much worse it's not even funny.
Part of it was the absurdly overengineered architecture we used. We moved from 2-layer PL/SQL + C++ app to 3-layer PL/SQL + J2EE + SWT but on SWT there were like 5 additional layers and most of the code was XML configuration on the UI side. That's not Java fault.
But part of it was just SWT API being so much worse than Qt. Signals and slots make observers and listeners look like ancient technology. The graphical design tools were so much better in Qt. The layouts in SWT sucked. Everything was worse and took more work.
SWT never was a part of Java. It was (as I recall) an IBM/Eclipse invention.
Basically everything on the desktop is dying. We still have a heavy C# gui and everyone thinks we're weird. We're due to be replaced with an SPA - good luck with that.
imagine an article about the decline of desktop java not mentioning the role of the microsoft bundled jre that basically broke most applications by default. the java ecosystem took a couple years to get out of that issue properly in ways that non techie coulod follow, but the bad experience stuck in the collective user minds up till this day.
Yeah, webstart was an unusable shit-show.
I remember writing a first SWT app (with embedded JRE) ~2004 and it looked nice and worked fast enough.
I think if Sun/Oracle didn't legally ban JRE trimming, added offical Swing browser widget and added a free cross-platform good-looking and developer/user-friendly installer - the story would've been different.
I remember writing a first SWT app (with embedded JRE) ~2004 and it looked nice and worked fast enough.
I think if Sun/Oracle didn't legally ban JRE trimming, added offical Swing browser widget and added a free cross-platform good-looking and developer/user-friendly installer - the story would've been different.
In 2020:
Admin: Wow, just look at our new 4 CPU server with 1TB super-fast DDR4 RAM! Its capacity is almost infini-
Java: Pf-f-f-f! (9_9)
Jokes aside, the only thing I remember about java on desktop is constantly downloading and installing frmeworks. And lags, lots of lags. Terrible lags. And flickering windows.
Jokes aside, the only thing I remember about java on desktop is constantly downloading and installing frmeworks. And lags, lots of lags. Terrible lags. And flickering windows.
Java's so efficient, it makes my laptop battery meter run backwards!
Sadly, it only does that when the machine is trying to charge.
Sadly, it only does that when the machine is trying to charge.
What other runtime needs more updates than an OS? Python never asks for updates and breaks my workflow.
Java is a great language. But it failed to become the universal "write-once" VM that everyone dreamed of in the 90's. Instead, the web browser did that. So there's really no reason to bother with native Java development anymore when browsers can do everything.
Java is a great idea, but the language is miserable. From the nullable concerns to the failed object model to the horrific runtime on runtime Spring (DI) monstrosity. Testing in Java is painful enough to signal that Java has a kong way to go. Statics ensure you can have pure functions but Java testing all but eschews their usage without complex setups. Booting up Spring in tests just to run methods that depend on opaque interactions is considered cursory.
A generix UI/UX (OS) model is the most complex and difficult type of software that exists. Games are hard, but not in the sane league. There is no Java OS because the language is insufficient, which is to say, it is suitable enoigh for other things, but I wouldnt say its great.
A generix UI/UX (OS) model is the most complex and difficult type of software that exists. Games are hard, but not in the sane league. There is no Java OS because the language is insufficient, which is to say, it is suitable enoigh for other things, but I wouldnt say its great.
I'm definitely biased but I think Kotlin for Desktop apps (https://www.jetbrains.com/lp/compose-desktop/) will take a lot of the energy in this space.
The biggest reason for the decline and fall of Java on the desktop is that better alternatives came up that succeeded. Somewhat ironic that Java on the desktop failed, but JavaScript has been wildly successful (despite the handwringing about Electron on HN).
The headline presumes Java ever actually went anywhere on the desktop in the first place.
Flutter is what replaced it. I'm working on server-based API for Flutter that comes with an easy-to-use SDK: https://nexusdev.tools/
I just wish it'd go away entirely. I'm not a dev. But an admin.
And I despise supporting or troubleshooting Java applications.
Unfortunately that's my life these days.
From an admin perspective, python, php, hell.. Even ruby. All fine. But Java is a nightmare.
And I despise supporting or troubleshooting Java applications.
Unfortunately that's my life these days.
From an admin perspective, python, php, hell.. Even ruby. All fine. But Java is a nightmare.
That's absurd, the ops tooling is top notch and claiming python deployments are better is laughable.
FlightRecorder, single jar deployables, the JDK cli utils to get stacktraces and heap dumps etc are good.
No npm getting a zillion files. Just get some jvm, point it at your jar and done.
If you are talking 2001 servlet container and so on, sure terrible, but if you are running those, switch jobs, thats not java's fault.
FlightRecorder, single jar deployables, the JDK cli utils to get stacktraces and heap dumps etc are good.
No npm getting a zillion files. Just get some jvm, point it at your jar and done.
If you are talking 2001 servlet container and so on, sure terrible, but if you are running those, switch jobs, thats not java's fault.
Working on a successful Java shop with thousands of deployments per month.
Curious about what's so hard about Java.
Curious about what's so hard about Java.
having to run several Java runtime versions on the same computer. I developped some years ago and that was an issue: some applications require 1.7, others 1.8, with some funny security specifics (I think it was not possible to set the security level for certificate on a per-version basis)
What’s so hard about that? I genuinely don’t understand. I run applications on different JREs concurrently, and I yet have to find any issues with it.
Curious why you dont recognize the obvious. The different runtimes each have their own behavioral/configuration quirks, library incompatibilities, and workarounds. This leaves stack traces as being less than helpful without full context.
Can you explain why it's so hard? I've had a lot better luck running Java apps than Python.
Not the parent but: Java has a long tradition of reimplementing things in Java rather than relying on system libraries. Everything from OpenSSL to tzinfo to libpng has its own Java implementation, entirely separate from anything else on the system.
> Java has a long tradition of reimplementing things in Java rather than relying on system libraries.
Er, that’s kind of the point of the Java Virtual Machine… It keeps you from tying your application to a particular system architecture.
I’ve noticed that JVM administration tends to fall into the “no man’s land” between devs and admins: Devs figure that the Admins will take care of it, and Admins are annoyed that they need to use a separate set of tools to admin the Java apps (and are not eager to learn them.)
Er, that’s kind of the point of the Java Virtual Machine… It keeps you from tying your application to a particular system architecture.
I’ve noticed that JVM administration tends to fall into the “no man’s land” between devs and admins: Devs figure that the Admins will take care of it, and Admins are annoyed that they need to use a separate set of tools to admin the Java apps (and are not eager to learn them.)
Web browsers do the same thing, they vendor everything they can to make the cross-platform experience better. Given that browsers are pretty much full-blown SDKs these days, and with everything being deployed as either a web app or an Electron app, I think it's fair to say that Chrome and Firefox are the new Java.
[deleted]
I am not admin, but kind of manage non-prod servers. One problem with Java is that a lot of things are half-done. If it totally relied on OS it would have worked, or if Java solution was thorough it would have worked. SSL management and Java app monitoring with tools like jconsole comes to mind. But others might have different annoyances.
It is working on one server and then broke on a newly built server apparently due to some network settings which devs/ app admins are not aware of.
It is working on one server and then broke on a newly built server apparently due to some network settings which devs/ app admins are not aware of.
I don’t think this is Java itself. Many Java apps are not designed with admin UX in mind. Those that have good UX usually don’t land on admin’s plate anyway and are managed by devs or devops.
jconsole is not user developed Java app, it is built-in tool comes with JDK distribution. And problem was not with UI it was that UI wouldn't come up because of some obscure network setting, with no useful error displayed back to user to fix issue.
UX != UI != GUI
Depends on the Java application, I feel your pain if need to manage application servers, but supporting and running modern Java applications shipped as jar files or docker images is not hard at all.
[deleted]
High school AP Computer Science classes are still teaching Java today. I suppose many of the skills it develops are applicable to other languages, but this still needs to change.
However... Minecraft, anyone?
However... Minecraft, anyone?
Why should it change? Java is one of the most popular languages used today
As discussed in the article, it's slow and has compatability/portability issues. And I don't really want to play the log4j card, but...
Other than startup times, modern Java is not slow at all. In fact, it's way faster than many other popular languages today such as Python and Ruby.
That's true. Python is no speed demon. However, languages like C are (for the most part) faster, and they need no emulation layer. I just think it's kinda strange to teach a language that is part-compiled-part-interpreted to kids as a first language.
Maybe we should teach them both a compiled language and a language like Python to show them that each one has its place and specific uses.
Maybe we should teach them both a compiled language and a language like Python to show them that each one has its place and specific uses.
It's not as fast as C/C++, but its faster than most languages in heavy use these days
if we assume the purpose of an entry level class is to introduce students to what they are likely to encounter in the "real world", Java seems like an excellent choice.
Java was really the precursor of electron.
As someone who developed a few Java desktop apps and many more Qt + C++ ones, the difference in performance was huge (memory and startup time).
As someone who developed a few Java desktop apps and many more Qt + C++ ones, the difference in performance was huge (memory and startup time).
WTF is the java mascot suppose to be. I've never understood it. Is it like some sort of modern art champion? Is it ironic? I have no idea, I just don't get it.
"There was always some guy in the back-row of the class with a trench coat and messy beard who let his feelings about the superiority of C++ be known."
Reletable
Reletable
I still run across Java apps pretty often, but they've all been third-party tools for Eve Online. I begrudgingly installed the Eclipse JRE for them.
Eh Java never made it to the desktop. Weird.
I don't know why you're downvoted: there is some truth to that. Java has never been a big player on the Desktop space. There's been a few successful Java desktop apps but not that many.
I kinda liked developing Java Swing app but I never saw Swing apps as something very common.
On the other hand Java and the JVM "not on the desktop" kinda made it everywhere.
I kinda liked developing Java Swing app but I never saw Swing apps as something very common.
On the other hand Java and the JVM "not on the desktop" kinda made it everywhere.
MoneyDance was and is a very good Swing desktop application. I have used it for years and love it.
Is there any data that confirms the decline of Java on the desktop?
It’s not that bad really. Package size and RAM usage is a bit of an issue, as we bundle it with a jlink’ed (stripped down to what is needed, thanks to Java 9 modules) JDK.
Other options like Electron or native Windows/macOS wrappers around a shared core written in C++ were discussed but ultimately discarded.
Still happy with the choice, although it feels a bit dated and IDE support (IntelliJ) is so so.