Java 17 arrives with long-term support: What's new, and is it falling behind Kotlin? JDK (Java Development Kit) 17 was released today, the first long-term support release since JDK 11 three years ago. A new version of Java appears every six months, in March and September. According to the Oracle Java SE support lifecycle, these are supported only for six months until the next one appears, whereas LTS releases …
I don't see any useful use-case for sealed classes or strong encapsulation other than control-freakishness.
There have been (very few, but important) times I've needed to access internal APIs on my phone. And fuck you, it's MY phone. I want my garage door app to be able to turn on GPS and data so it can function, and I don't want to spend 5 minutes tapping all sorts of extraneous "enable" dialogs just so I can go home.
Delegation does not help at all if you cannot use your own class in place of the other, which is the case if there is no common interface to implement. Of course, with your own code and sanely written libraries/frameworks, this is not something you'd be forced to do in the first place, but unfortunately a lot of stuff you encounter in enterprise development is horribly written/structured - look no further than some of Oracle's own products. Without the ability to replace an instance with a subclass of your own, you're screwed.
I shouldn't be surprised but still, I am. First encountered this probably JDK 2 era before 2005, with our own app stack. Then hit again 5 years later by this behavior on one of the largest credit card payment processors(at another job not at the payment processor was at a company that was a customer of the processor).
By default java will cache positive DNS responses forever, until the JVM is restarted. The justification in the java.security file (same as it is in JDK 17 just downloaded it to check on Linux) is that caching forever protects against cache poisoning attacks. I mean anyone that knows DNS knows that you really have no way of knowing whether or not a given DNS response is poisoned or not(for any that mention DNSSEC note that doesn't apply to client DNS requests). I mean what if the JVM caches the poisoned response? Also makes for trouble in clusters where JVMs may not be restarted all at the same instant maybe different VMs will get different DNS responses depending on when they restarted.
So many problems with caching forever and it just blows my mind that is still a default configuration. Worse still many java customers(even large enterprises I have come across in my experience) don't know about this setting and just leave it at the default because they don't know any better. Makes it worse still when they are actually scared to change the setting so they leave it at the default.
see the setting for
#networkaddress.cache.ttl=-1
in conf/security/java.security for reference
It wouldn't be so bad if they WANTED to keep the default then to throw up a warning when the JVM starts saying HEY take a look at this setting you may want to change it. Then perhaps add a jvm startup option or something to suppress that warning for those that REALLY don't want to change the setting.
The biggest part of the problem is people just don't know this setting is even there for the most part, and many are stupid so they see the warning in the file and say hey that makes sense I should keep the default setting.
Or the least they could do is change the comment in the file to say the previous justification was very wrong and caching forever is a bad behavior but we keep the default like this because we want backwards compatibility to be perfect or something. But say as a customer you SHOULD change this value.
(Note I haven't fired up anything with Java 17 so they may very well have inserted a warning but I kinda doubt it)
>...is it falling behind Kotlin?
Outside of the niche of Android-centric development, the two are not interchangeable. This is particularly the case if you work for an organisation that takes risk and liability seriously, where signing up to run your business on a language entirely owned and run for-profit by a fairly opaque, minor Czech IDE developer is really not the smartest of ideas. The second Google decide to move onto yet another language for Android there's a serious risk the whole ecosystem dies off.
Even away from the Android world kotlin is gaining significant adoption. The enterprise space is very slow to change anything, hence everyone's still on Java 8. Google's endorsement of Kotlin is worth a lot. Just like "no one ever got fired for buying IBM!” Even if your enterprise has requirements nothing like Google's :)
At my day job, we ported our enterprise workflow product to Kotlin. We did it gradually, a package at a time as that package had enchaments made to it. There's virtually no java in the codebase now.
The developer productivity is a lot higher than java 8. Ultimately less key strokes to achieve the same thing. Lots of the recent Java enchaments are a step in the right direction but probably too little too late.
Kotlin + IntelliJ are one of the few IT tools that are actually a pleasure to use. I really can't recommend them enough!
I wouldn't be surprised if projects that use Java will eventually move on to another language unless they abandon the vomcano that Spring framework is - maybe it will become a niche technology like Cobol?
I had to use it for a whole year without understanding exactly what it does, apart from creating mile long exception stacktraces, turning simple debug operations into a nightmare. And so much complexity added, for nothing!
I understand that it can be a legacy technology because JEE used to be worse ( whatever worse than Spring could possibly be, without physically attacking and abusing you ), but at the time we were rewriting an existing one from scratch because the original one was a patchwork of different bits added over time.
Estimated length of the project was a year, at the end of which we were not even half way through ( we also had to thank hibernate and GWT for that though ). From what I heard it's not uncommon that very basic functionalities will take forever to implement just to make Spring happy.
I found myself a nice Springless job, unfortunately rare these days, learned to develop android apps - which were threatened with Spring for android for a while, until the whole idea was abandoned - and now moving on to Salesforce devving... Hoping that nobody will every be stupid enough to even consider some Spring like frameworks for that.
Spring beans is great, dead simple. I have written xml based springalike in one short class, and ditto an annotations based version so I don't have dependency issues. Any service code that doesn't have dependency injection ends up being hard to unit test, and code that is hard to test ends up being hard to change.
I really cant see the objection to dependency Injection? What's the alternative? We had some contractors write a ton of code without the structure dependency injection gives you and its a bloody nightmare to test or to make it do anything other than what it was first designed for. None of it is reusable.
Fair enough for the dependency injection bit - but if I remember correctly there were about 150MB of Spring related libraries of death. Not sure what they did apart from making it harder to get where we wanted to get.
Hard to unit test would have been a bliss, so much better than almost impossible to deliver. Luckily I left after one year, no idea how long it took them to get a working version of what they wanted. I wouldn't be surprised if they just switched to C# or any other language which just lets you get on with things without lengthy XML prayers. At the time it was the best way to do things, apparently, rather than annotations. Can't imagine what torture annotations must have been then.
As far as I am aware Spring.NET is dead. So there must be ways to do without spring for sure.
I know little about .Net but the article was about Java, Java Spring is devided into well separated libs.
Spring context is under 1mb, that provides both the xml driven version which is still usable but a little dated as most code I have seen uses the annotation driven style, since Java 5.
You can make a mess with any tool, one of the things I like about Spring is if someone does, you can fix it one service at a time without leaving your ide.
It's more difficult to write spaghetti code.
It's not all good, not a fan of spring-batch,
But I'll take jdbcTemplates in preference to any ORM.
My .m2/repository needs spring cleaning (geddit) it has 19 versions of spring-core + deps (gulp) and totals 85 mb.
If you have a 150mb classpath you have some other problem.
I can't see why the author of the article doesn't think pattern matching is a big deal. I use pattern matching in almost everything I code, though this is mostly in functional languages (ML, F#, Haskell), where the support is better than in Java. For example, functional languages support nested patterns and pattern-matching over base types such as integers. Oh, well, I suppose this will eventually make it into Java. Most features of functional languages already have. Like Bob Harper once said: "Over time, every language evolves to look more and more like Standard ML".
I think pattern matching is easy to underestimate if you haven't used it. When people first hear about it, their initial reaction is often "slightly nicer switch statement, what's the big deal?"
The fact that sum types make the type system way more useful isn't obvious at first glance. You have to either think about it really really hard, or have someone show you one of the "make illegal states unrepresentable" essays.
Until web servers such as Glassfish or Tomcat that can run newer versions of Java all my code will be Java 8 compatible for reuse purposes.
Maybe there are alternative web servers or work arounds? Am I missing something?
With that said I've also reviewed changes from Java 8 to 16 and see no real killer feature, and I'm not impressed by syntactic sugar or lazy shortcuts that reduce readability of the code.
It still supprised me that in 2021 you still need a special webserver for running Java web applications, why isn't there some sort of fastcgi process manager which handles Java requests via a reverse proxy like PHP's had for a long time now, then sat in front of that you can use Apache or Nginx and haproxy in front of those.
You don't need a Servlet Server the days. A lot of enterprise style web apps, just embed jetty or similar http servers libraries. So they self host themselves.
Since you are often now deploying them in containers via things like kubernetes many of the advantages of a full blown app server have long gone.
Jit compilation means java will never be a good fit for a scripting language. Once you have booted a jvm you want to keep it alive. With -Xshareclasses it can be fast to boot, but that's not really the point.
It's a memory safe language so it makes more sense to write server components in Java rather than tacking scripts on the back of a C based server.
Java starts to makes sense only when you have a fair few concurrent users and your service is going to stay up for long periods. There is too high a memory cost with Java for most other use cases IMHO .
Java introduces the Sealed classes and interfaces as a preview feature in JDK 15 (JEP 360) and JDK 16 (JEP 397). Now, finalized the feature in JDK 17 (JEP 409), with no changes from JDK 16.
I have gone through this article https://tedblob.com/sealed-classes-and-interfaces-in-jdk-17/. Compared to Kotlin sealed class, this provides more control on what subclasses can extend a class. Kotlin sealed class would have package-private visibility whereas Java sealed class provides more fine-grained control.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
