This is a lot different than I remember. As I remember it, Java was touted as a compile-once run everywhere language. Back then, you had many different flavors of UNIX, with different hardware architectures, and in practice, software was deployed (and supported!) directly on customer servers (web services didn't exist). Plus, this was a time when pretty much all code was written in C. Virtual machines with garbage collection were academic research projects.
Java (until recently) was always a sub-par language. It was difficult to work with and behaved in unexpected ways. Academics hated it because there were much better grammars. Engineers hated it because it was slow and rigid compared to C. Gosling designed it for embedded systems, of all things. But, it aimed to solve a very expensive problem, and lots of hype was directed at it.
(Edit: I should have emphasized that the tooling really sucked more than the language. We had fantastic C compilers and IDEs. And, Java had immature tools. Worse, you had to manually build Jars and package your Jars appropriately. Ant, Maven, Gradle, etc didn't exist.)
Also, the GoF authors didn't write design patterns as a response to Java. They wrote it as a retrospective on large software systems - what worked and what didn't. The 'patterns' were called such because they were observed in many independent projects, each having been reinvented time and again. The patterns proliferated with Java EE architects who pushed patterns as common ways to communicate standard design principles. You have to keep in mind that this was also a big time for 1) RAD, 2) UML, and 3) software factories. Large companies were sold a vision than in a very short period of time all they would need would be an 'enterprise architect' who would 'draw' the software, hit a button, and out would come the complete system.
Java (until recently) was always a sub-par language. It was difficult to work with and behaved in unexpected ways.
Every language has its idiosyncrasies to be sure, but this doesn't really jibe with my recollection. I remember Java being a much better alternative to C++ in many ways, including (and especially) binary object compatibility which made it possible to effectively use libraries. Remember how C++ libraries had to either be pre-compiled for your platform (which the same compiler you were using, etc.) OR be shipped as source.. and given C++'s blazing fast compilation times coughcough, well....
Anyway, in 2001 we were building Java IVR applications on Windows and shipping the jars to AIX machines and running them with no problem. The "write once, run everywhere" thing certainly wasn't 100% true (especially for desktop apps using Swing) but for many applications it really was the case (or close to it).
I'm sure it worked well in many cases. But, in our case, we were developing for Solaris, AIX, HP-UX, and Windows NT. The VMs would behave differently in different environments, and I remember VMs stack dumping on many occasions which became a major support headache. We used to call it 'build once, run nowhere.'
But, in our case, we were developing for Solaris, AIX, HP-UX, and Windows NT. The VMs would behave differently in different environments, and I remember VMs stack dumping on many occasions which became a major support headache. We used to call it 'build once, run nowhere.'
Interesting. The only thing I really remember people complaining about a lot was thread scheduling. Java always let you set a thread priority and a lot of people tried to use that to make things behave in very specific ways, but - if I recall correctly - it was the case that that behavior was always allowed to be platform independent and couldn't be relied on to create a consistent cross-platform experience. Outside of that, it seemed like UI issues with Swing (or, I guess, AWT) were the main things people ran into trouble with.
What time frame was all of this for you? Wondering if it was just the very early days of Java before some of the problems were resolved.
Also, Java only provided the lowest common denominator. A piece of software I worked on back then needed to start a long 2hr process, but only if there was more than 2GB of free disk space (which was not a trivial requirement circa 2000). But Java did not have a way to query free disk space at the time because IIRC it was missing on one of the platforms (and then it wouldn't be "run everywhere"). So instead it would run, and if insufficient disk space would just fail.
> Academics hated it because there were much better grammars.
Surely not at my university.
By 1998 it had already replaced C as the language for distributed computing classes.
C with SUN RPC or PVWM was just too clunky to keep on using and was used just as introduction to distributed computing.
Same with compiler design classes.
The ECOOP'99 was full of Java related presentations with the keynote of Jim Waldo about Jini, something that would just come in handy in our modern IoT days.
> We had fantastic C compilers and IDEs. And, Java had immature tools.
On which OS?
Visual Age, JBuilder, Zortech all were quite similar to their C and C++ siblings.
> The patterns proliferated with Java
Nah, they were already quite common in C++ with CORBA and COM/DCOM projects.
Sure, universities embraced it in the late 90s because it was easier to teach to undergrads, and CS programs were becoming cash cows. But, the researchers that I knew certainly weren't using it for their own Computer Science research (aside from VMs and heterogeneous environments).
Yeah, Jini was cool! And Tuple spaces, etc. There were some cool things being built on Java, but few people were embracing it as a silver bullet.
Java (until recently) was always a sub-par language. It was difficult to work with and behaved in unexpected ways. Academics hated it because there were much better grammars. Engineers hated it because it was slow and rigid compared to C. Gosling designed it for embedded systems, of all things. But, it aimed to solve a very expensive problem, and lots of hype was directed at it.
(Edit: I should have emphasized that the tooling really sucked more than the language. We had fantastic C compilers and IDEs. And, Java had immature tools. Worse, you had to manually build Jars and package your Jars appropriately. Ant, Maven, Gradle, etc didn't exist.)
Also, the GoF authors didn't write design patterns as a response to Java. They wrote it as a retrospective on large software systems - what worked and what didn't. The 'patterns' were called such because they were observed in many independent projects, each having been reinvented time and again. The patterns proliferated with Java EE architects who pushed patterns as common ways to communicate standard design principles. You have to keep in mind that this was also a big time for 1) RAD, 2) UML, and 3) software factories. Large companies were sold a vision than in a very short period of time all they would need would be an 'enterprise architect' who would 'draw' the software, hit a button, and out would come the complete system.