151–160 of 251 posts
Any news on JavaFX? I know it's developed independently but is it an even option beside Qt, Electron, etc..?
I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do it other way". Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue. A quote from Thinking Forth comes to mind: > The newest traditional languages (such as Modula 2) bend over backwards to ensure t…
Yes, the strong encapsulation of JDK impl classes can create some inconveniences to an attacker. But I don't feel it's valuable enough to justify luck of access to the internals.
No releases for 17 yet, but checking the site, I discovered that AdoptOpenJDK was moved to the Eclipse Foundation and renamed to Adoptium: https://adoptium.net/
I don't know if I'm reading this right, but it seems that the Adoptium packages (were AdoptOpenJDK) are slated for Sept. 30 the latest: https://github.com/adoptium/adoptium/issues/73
I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape or form! I am not a Java developer. I am one of those users who has a bad memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, and had example "Hello Worlds" that are reminiscent of Enterprise FizzBuzz [1]. At some…
Oracle owns "Java", that is the name, the trademark, etc. In that sense, OpenJDK is "not" "Java". But operationally, this is moot. But it has impact in other areas. What was originally "Java Enterprise Edition" was transferred over to the Eclipse Foundation, but they couldn't take the "java" name with them. All of the JEE packages were "javax.enterprise.". Oracle wouldn't give up the "Java" part in order to not dilute its trademark, so now its the "Jakarta Enterprise Edition", and all of the packages are being renamed to "jakarta.enterprise.". I mention this just as an example of the hoops the community going through, even today, over what's happening with java.
So, Oracle and the community have to dance a fine line over what is the language, compilers, tools, and libraries, and what is "java", what is trademarked, what is owned by Oracle.
Oracle was kind enough to be an invested member in the Java community by not forking, closing, and going off its own way, and leaving the OpenJDK to fend for itself. This is essentially what happened to Solaris and OpenSolaris.
The other JDKs (Zuul, AWS, etc.) were certainly a hedge against this. The industry has a lot invested in "java", and can't really afford to let it get out of hand. Having "official" builds, that were supported, and patched, and eyes on vs the latest release from OpenJDK gives companies a secure feeling. That's why other companies stepped up to support their own JDKs. To help assure clients that the technology is stable and still worth building on.
So, the differences are not so much different languages, or even different implementations (though there is certainly some of that). Rather much of it is simply stability in the community.
Also, the whole licensing issue with Oracle vs the others was a big deal also. We'll see what impact the new free license from Oracle has.
Earlier quoted context omitted.
> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.
I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.
A lot of the time, the software I'm working on has data objects that are really amalgamations of other fields. Example: "Address" is the street address, the city, the postal code, etc, etc. These sorts of objects should be immutable. Records are perfect for that.
If I need to add additional logic, methods, then you can add those to a record. But it continues to enforce that the state is immutable.
Lately I have insight similar to 'what hardware improvements give, software bloat take it away', 'what JDK platforms give third party Java frameworks take it away. I have this misfortune of dealing daily with a nasty Java framework which converts compile time errors into runtime errors, single error trace with multiple stack traces , most of them being from framework itself. One thing that might improve situation is…
what was the framework, if you don't mind sharing?
If only I could understand the difference between java 1.8, 8 and 18.
Starting from 1.6 they only showed the minor version number. So 1.6 = Java 6, 1.8 = Java 8, etc. I always assumed this was because .net (arguably it's main competitor) was churning fast through version numbers and they "wanted to keep up".
PS: had to edit, was really just a note about the numbers not the content of the versions!!!
On its own, the features specifically for Java 17 aren't obviously that compelling, but the important thing is that Java 17 is an LTS, the last one of which was Java 11, 3 years ago. Since many organizations, including mine, stick to LTS releases, that means a lot of developers will get a big change in what they can do sometime in the next few months as they upgrade to the LTS. Among other things, this means that we…
Earlier quoted context omitted.
Exactly, I hate dealing with Lombok projects for that reason. I'd rather the cruft than the compiler add-on.
Do you not just use maven? Any of the major IDEs will automatically configure annotation processors for you when they're configured in your pom. Similar for gradle.
TBH, it was a lot of trouble so that someone could avoid generating a couple of getters and setters, and could use a annotation to setup the logger. I realize that there are more features available than that, but the ones that I've seen often used it in such mundane and boring ways that the setup wasn't worth the hassle for me.
But I guess we all get annoyed with minor hassles in different ways. I got annoyed with the hassle of setting up an IDE, they got annoyed with getters and setters more. :)
Earlier quoted context omitted.
This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of programs; so you might be stuck on 11 if you use HBase, Spark, etc.
You won’t be stuck, you just need to add some command line flags when running your application, as a way of acknowledging these packages are breaking encapsulation.