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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
public class MyFirstJavaProgram {
public static void main(String []args) {
System.out.println("Hello World");
}
}
We've got access modifiers, classes, scopes, lifetimes, variable types, void variables, methods and in particular the main method, String types, arrays of strings, input arguments to main method, the System class, output streams, function calls, string literals, and to top it all off a good old fashioned statement terminator as the cherry on top of that feature sundae. The great irony is that the AP Computer Science Ad Hoc Committee call this behemoth "simple".
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"
That's it. That's the ideal. You get that in languages like Matlab, and I've had great success teaching robotics using Matlab. With Matlab, students are writing real robot programs within a few hours, whereas with Java students are still raising their hand asking "Wait, so what's the difference between an object and a class? What's a method versus a function? What's static mean? What does void mean? What does []args mean?"
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.
> 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.
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.
> 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.
Yes, int vs Integer. It does make sense that those would function differently. /s ;)
And C definitely has some inscrutable errors, but to me once I understood them, they always made sense in computer terms. Whereas Java errors and oddities only make sense in Java terms.
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 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.
> 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!
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.
> 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.
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.
> 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.
Matlab: To access the first element, do x(1).
Student: okay.
And then we move on to the next topic or the activity at hand.
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.
And then we spend the next amount of time talking about indexing, not doing fun things like the activity at hand. The difference between 1 indexing and 0 indexing is trivial in the grand scheme of things. But it's and example of something where just a slight change is the difference between understanding and confusion.
> 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.
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.
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.
> 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.
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).
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:
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.
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.
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.
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.
> 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.
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).
(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.
[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.
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.
...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)...
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.
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.
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.