7 ms·
When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM
by brightball 1y ago
When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier.
Java the language eventually drove me away because the productivity was so poor until it started improving around 2006-2007.
Now I keep an eye on it for other languages that run on the JVM: JRuby, Clojure, Scala, Groovy, Kotlin, etc.
IMO JRuby is the most interesting since you gain access to 2 very mature ecosystems by using it. When Java introduced Project Loom and made it possible to use Ruby's Fibers on the JVM via Virtual Threads it was a win for both.
Charles Nutter really doesn't get anywhere close to enough credit for his work there.
- cogman10 1y agoLet me extol the virtues of Java the language. You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it. Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.
- _ea1k 1y agoYeah, that and the portability are really incredible and underrated. It is funny, because I constantly hear things like "write once, debug everywhere", but I have yet to see an alternative that has a higher probability of working everywhere. Although Python is pretty close, if you exclude Windows (and don't we all want to do that?).
- bhaak 1y agoI often run into problems running Python code under Linux. I don’t know if it is a me problem or if I’m missing the right incantations to set up the environment or whatever. Never had that much problems with Java. But I’m a Java and Ruby person so it might really be missing knowledge.
- cestith 1y agoPython can be tricky with the big differences between 2 and 3.
- loloquwowndueo 1y agoPython 3 came out in 2008. If the 2 vs 3 differences are still biting you you probably have bigger problems to solve (deprecated, insecure, unmaintained dependencies for example).
- coolcase 1y agoAnd IPv6 came out in 1995
- loloquwowndueo 1y agoYour point?
- coolcase 1y ago"Comes out" and "Ready to switch to" are two different things. Your conclusion is correct but not because Python 3 came out in 2008. It was ready to switch to some point a few years later but we'll before 2025 (I don't recall when sorry I didn't do Python at the time!)
- icedchai 1y agoAs late as 2022, I was at a company still in the middle of "migrating" from 2 to 3. I wouldn't be surprised if the migration project was still going on. The system had gone beyond tech debt and was bordering on bankruptcy.
- cbm-vic-20 1y agoI've got a jar that does one small thing and does it well that was compiled in 1998. Still works fine, no reason to update it.
- brightball 1y agoThat is an excellent point too. It always made me wonder why I hear about companies who are running very old versions of Java though. It always seemed like backwards compatibility would make keeping up to date with the latest an almost automatic thing.
- fpoling 1y agoJava version updates typically change GC behavior. If one has highly tuned setup there is no guarantee that a newer version would not regress. Another problem is crashes. Java runtime is highly reliable, but still bugs happens.
- josefx 1y agoIt is "mostly" backwards compatible. Applets and everything related to them where dropped. A few interface dependencies where changed to improve modularity of the runtime. Widely used hacks like sun.misc.unsafe are getting replaced with official APIs and locked down. Development of some Java EE packages has been taken over by a third party, so they are no longer packaged within the java namespace. To name just a few of the bigger examples.
- kamma4434 1y agoIt is - but you don’t want to find out that something broke because of odd JVM update. If it ain’t broken…
- worik 1y agoI have been badly burned, twice, by Python's cavalier attitude to backwards compatibility
- eppp 1y agoI know that what you said is supposed to be true. However in my real world experience it is anything but. Cisco java programs are a disaster and require certain JVMs to run.
- aaronbaugher 1y agoThe enterprise Java applications we use require specific versions of specific Linux distros. It's possible that they would run on other distros, or even other operating systems, if you got the right JVM. But there's enough question about it that the companies that sell them for a substantial price aren't willing to promise even a little portability.
- fpoling 1y agoI have C++ code from 1997 that I occasionally compile. So far it runs. 10 yeas ago compiling with -Wall exposed an inconsequential bug and that was it. I suspect when it stops to compile it will be from an absence of a particular X11 library that I used to parse a config in otherwise command-line utility. Which also points to another thing where Java compatibility shines. One can have a GUI application that is from nineties and it still runs. It can be very ugly especially on a high DPI screen, but still one can use it.
- AnimalMuppet 1y agoThat's not the virtues of Java the language. That's the virtues of Java the backward-compatible platform. That is, you didn't say anything about the language (syntax and semantics), you only talked about backward compatibility. (It's still a valid point. It's just not the point you labeled it as.)
- cogman10 1y agoThe language also follows the backwards compatibility principles. Java hasn't, for example, added new keywords in a backwards incompatible way. You can, for example, have something like int record = 1; double var = 2; even though `var` and `record` are now used to create and define things.
- johnisgood 1y ago> You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. This is not my experience with Java at all. I very often have to modify $JAVA_HOME.
- winrid 1y agoAre you using Gradle projects? Gradle is especially difficult for some reason.
- johnisgood 1y agoSadly. I would rather avoid Gradle and Java in general. I did not have good experiences with them. :/
- thomashabets2 1y agoI have the exact opposite experience. I haven't coded much Java, but when I tried to revisit it, code I wrote 10 or 20 years ago doesn't even remotely compile anymore. While with C++, 20 years later you may need to add a missing #include (that you were always supposed to have), but then it just works as it always has. Java is, in my opinion, a complete mess. And I think it's weird how anybody could like it past the 1990s. C++ not being compilable later hasn't been true since pre standard C++. We're talking 1980s now. https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...
- KronisLV 1y ago> Moreso than nearly any other language backwards compatibility has been key to java. The Java 8 and 8+ divide very much works against this. It was a needed change (much like Python 2 vs 3) but nowhere near pleasant, especially if some of your dependencies used the old Java packages that were removed in, say, OpenJDK 11. Furthermore, whenever you get the likes of Lombok or something that has any dynamic compilation (I recall Jaspersoft having issues after version upgrade, even 7 to 8 I think), or sometimes issues with DB drivers (Oracle in particular across JDK versions) or with connection pooling solutions (c3p0 in particular), there's less smooth sailing. Not to say that the state of the ecosystem damns the language itself and overall the language itself is pretty okay when it comes to backwards compatibility, though it's certainly not ideal for most non-trivial software.
- cogman10 1y agoThe Java 9 change was to remove access to unofficial APIs. I agree it was somewhat painful, but not nearly to the level of the 2->3 change which ended up changing python syntax. Most dependencies worked throughout the change and still work. > Furthermore, whenever you get the likes of Lombok or something that has any dynamic compilation ... there's less smooth sailing. Not sure about c3p0, but Lombok goes out of it's way to inject itself into javac internals in order to make it's output changes. It's using the most internal of internal code in order to make that @Getter annotation work. Plenty of other annotation processing APIs are completely unaffected by javac updates because they choose not to use internal APIs. Immutables, Autovalue, dagger2, all examples of dynamic compilation that continue to work regardless the version of java. Lombok is a horrible little dependency that I wish people would abandon. It's making a mess and then complaining that it's somehow Java's fault because Lombok decided it needed access to the AST. I get it, things have broken. But what has been broken is literally the undefined and non-public APIs which went so far as to call their packages things like `sun.misc.unsafe` just to try and ward off people from using these APIs. (With the javadocs to boot which told people not to use this). And even with the break, the Java devs went out of their ways to make stand-in apis.
- int_19h 1y agoThe counter-example to this is C#. Barely younger than Java (by 5 years), and starting its life as mostly a Java clone with a sprinkle of Delphi, it evolved much faster and made many changes which "make things look better" without breaking things. Source-level compatibility goes pretty much all the way back to 1.0, as well.
- jbverschoor 1y agoOh yeah. I still don’t understand why we even moved away from the original JEE model, including the different roles (app dev, deployed, etc). The whole spec was great with the exception of entitybeans. It provided things that are still not available it anything else.. why do we store configuration/credentials in git (encrypted, but still). And the context were easy to configure/enter. Caucho’s resin, highly underrated app server. Maybe not underrated, but at least not very well known
- brightball 1y agoI remember Resin. I grew to be a big fan of JBoss and was really disappointed when the Torquebox project stopped keeping up (Rubyized version of JBoss).
- datavirtue 1y agoYeah, JBoss put "it's slow" to bed right away. I was doing my own research at the time and tried some workloads on it. Huge difference.
- liveoneggs 1y agoresin was okay but I never got what it offered over tomcat
- jbverschoor 1y agoFull JEE, not just servlets, performance, reloading, and a bunch of enterprise features. Resin existed. After about 10+ years Spring kind of took over JEE. Omg. Spring was just like moving code to xml. Different now, but still. What I miss from JEE: - single file ear/war deployment, today that’s a docker image - the whole resource api from Java (filesystem/jar doesn’t matter). It means you don’t necessarily have to unpack the jar - configuration / contexts for settings, + UI for it, database connections etc. Docker kind of works, most most images fail to achieve this. Docker compose kind of takes care of things. - as said before.. all Java still runs everywhere
- icedchai 1y ago
- ksec 1y agoIt is unfortunate the whole JRuby doesn't get more attention and it seems Rails community dont use JRuby much. JRuby could also run on Graal as well.
- deleted 1y ago[deleted]