141–150 of 243 posts
What's the best way to run java apps in a container nowadays? The official openjdk images are based on "oracle Linux" and that doesn't sound right :) is there good small and well supported java image based on a popular distribution?
EDIT: Also openjdk has buster based images: https://hub.docker.com/layers/openjdk/library/openjdk/jdk-bu...
Earlier quoted context omitted.
You might consider Kotlin then. It’s more JVM-aligned than Scala, but waaaay terser than Java (as yet — the Java team is making great strides).
What do you mean by "JVM-aligned" and how is Kotlin more JVM-aligned than Scala? Speaking as someone who uses Scala on a daily basis and never touched Kotlin.
"Helpful NullPointerExceptions describing precisely which variable was null JDK 15" I wonder what number of collective hours would have been saved with this one, had it come earlier.
obj.call1().call2().call3();
obj.call1()
.call2()
.call3();
I’ve always admired Java for managing to slowly but surely move the language forward while maintaining backwards compatibility and keeping the community together. When you look at how many other languages have faltered and lost momentum due to transition issues (Perl 6, Python 2/3), it really shows have difficult of a task it is. Progress can seem glacially slow at times - it’s always disappointing to see your favori…
I would add C# to the list of languages with good backward compatibility and progression with every new version. Very similar to Java, and has a lot more feature set with somewhat decent documentation.
Earlier quoted context omitted.
What do you mean by "JVM-aligned" and how is Kotlin more JVM-aligned than Scala? Speaking as someone who uses Scala on a daily basis and never touched Kotlin.
Kotlin types and Java types are much more compatible than Scala types. No need to use converters. Also, Scala leans very FP, while Kotlin and Java don't, so they are also more similar in that regard, though I don't know if that's what "JVM-aligned" means here. Overall, Kotlin and Java just have better interoperability than Scala and Java
The JVM is designed to execute the constructs of the Java language. Scala compiles to JVM bytecodes, but it does a lot of (very cool!) things that are not natively supported by the JVM, and thus tend to be pretty expensive. Scala's pattern matching, for example, goes beyond what can be efficiently expressed in the JVM.
As a rule, Kotlin does not take this approach. Instead, almost all the constructs in Kotlin can be cleanly expressed in JVM bytecodes.
Reified generics is a good example. Kotlin only allows them when a function can be inlined, since in those situations, you don't actually need generic arguments, since the code in the inlinable function can be dropped in place. This allows for the convenience of reified generics -- but only if you're willing to live within the limitations of the inline restriction. (And it's also elegant, since it'll be easy to relax the constraint once the JVM adds the needed support.)
I've run across one or two things in Kotlin that don't translate to JVM bytecode elegantly, although I'm struggling to find a good example off the cuff. They're definitely the exception, though, whereas the Scala team took a more radical approach.
Is it in the realm of possibilities that Java will someday have runtime generics support (instead of type erasure)? It's the most frustrating aspect of the language because you can't use basic Java features like method overloading with them. Also, I don't understand how people use the `Optional `..? Is there a way to use method overloading with it? `ErasedType` could be _anything_ at runtime, doesn't sound fun. Besid…
I may be misunderstanding your question, but in general you wouldn't be doing anything type-specific with an Optional's value unless you were in a part of your code that knows the type at compile time. For example, a data structure might return an Optional from a get() method, but all it's doing is returning the T or an empty.
> Besides all references types are already nullable/(optional)... so what's the point?
1. It's nice to explicitly say if a value might not exist than to be unsure if a null object is meaningful.
2. It can force consumers of an Optional to deal with the empty case (versus forgetting to null check)
3. Null might mean something like "this value was accidentally never initialized" versus "I am explicitly indicating an empty value"
4. It can give better developer ergonomics with convenience methods or monadic style (such as with Scala's Option type, where you could .map() on an Option, or merge multiple Options together)
Earlier quoted context omitted.
I would add C# to the list of languages with good backward compatibility and progression with every new version. Very similar to Java, and has a lot more feature set with somewhat decent documentation.
One thing I've always admired about C# is that it's an ISO standard. Which I'm not sure if that really means much these days in terms of computer programming languages. It seems like it would be an amazing hedge against a private organization co-opting it in the future.
(for the curious, here's the complete list of C# language versions: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...)
Earlier quoted context omitted.
> More seriously, what are you missing in Go that is well-done in Java? 1. Generics. And yea, I know Go is getting generics "Real Soon Now" (tm), but it is incredibly annoying to write the same collection code over and over and there's some third-party libs that would really benefit from generics (looking at you Azure Go SDK). 2. Error handling... with the big caveat that I actually like Go's error handling mechanism…
Much of the verbosity came from the false presumption that every field in every class needs a public getter and setter. (I cannot express in words how terrible this is.) Some can come from the framework, mostly poorly-designed ones. I think Java 11 and higher are reasonably terse/expressive without being overly dense.
Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely language that with a little discipline can be used to create very lean looking code. Go is one of the HN darling languages and I work in Go everyday for work (and generally like it), but I really wish I could reach for Java most days.
“Java is a big DSL to transform XML into stacktraces” — so was the joke at the time when domain-specific languages were the hype. This, and the FizzBuzz, Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... More seriously, what are you missing in Go that is well-done in Java? I assume verbosity of the code is still the defining characteristic of Java?
hasThing := false
for _, v := range stuff {
if checkForThing(v) {
hasThing = true
break
}
}
if !hasThing {
return false
}
if !stuff.stream().anyMatch(v -> checkForThing(v)) {
return false;
}
Earlier quoted context omitted.
I disagree that it's a lovely language. I think, as developers, we very quickly develop Stockholm syndrome. Once you "learn" a language, it's really easy to churn out code and apply idioms without even realizing that you're constantly writing workarounds and kludges for your language's deficiencies. As a polyglot dev, the following are my gripes with Java: * null - we all know, so I'm not going to bother expanding ex…
> No unsigned ints. I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations. I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority. > Silent in…
The problems really only come from mixing those types, and the simple solution is to disallow such mixing without explicit casts in cases where the result type is not wide enough to represent all possible values - this is exactly what C# does.
I think Java designers just assumed that high-level code doesn't need those, and low-level code can use wrappers that work on signed types as if they were unsigned (esp. since with wraparound, many common operations are the same).
> Java-style wrapping integers should never be the default
The ironic thing about this one is that C# introduced "checked" and "unchecked" specifically to control this... and then defaulted to "unchecked", so most C# code out there assumes the same. Opportunity lost.
While we're on the subject of numeric types - the other mistake, IMO, is pushing binary floating point numbers as the default representation for reals. It makes sense perf-wise, sure - but humans think in decimal, and it makes for a very big difference with floats, that sometimes translates to very expensive bugs. At the very least, a modern high-level language should offer decimal floating-point types that are at least as easy to use as binary floating-point (e.g. first-class literals, overloaded operators etc).
C# almost got it right with "decimal"... except that fractional literals still default to "double", so you need to slap the "M" suffix everywhere. It really ought to be the other way around - slower but safer choice by default, and opt into fast binary floating-point where you actually need perf.
> At least Java has the defence that they didn't know how it would pan out. C# has no such excuse in copying Java.
I think both Java and C# did it as an attempt to offer some generic data structure that could cover as many use cases as possible, since neither had user-defined generic types. In retrospect, it was an error - but before true generics became a thing, it was also a godsend in some cases.