231–240 of 478 posts
Still nothing to handle checked exceptions in streams properly... sigh.
But my favorite is abusing the language using Lombok SneakyThrows. It just feels dirty using it. In a good way.
Earlier quoted context omitted.
It's fascinating reading a post like this because I feel exactly the same from the opposite perspective. I feel bad for people trying to write in other languages and manually re-inventing dozens of features the JVM ecosystem just gives you for free. In many ways, the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc). I still don't see…
That's how much people hated writing Java. Also, Erlang would like to have a word with you.
or, they are more concerned with shiny new tech rather than using a mature and well-tooled out stack that doesn't sound sexy. I for one, don't need sexy tech - i want my app's domain to be the shining star, not the tech stack.
Earlier quoted context omitted.
Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements). More importantly, the JVM ecosystem is m…
> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it…
Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy
Earlier quoted context omitted.
GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages for game development. This could open up the JVM for games, which could have some exciting implications.
>GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages There is such a thing as reference counting :)
Non-trivial reference counting starts to look like mark-and-sweep GC.
And even then, when a ref count drops to zero, the runtime cost of destruction and deallocation of particular objects can be expensive. Stop-the-world GC is bad, but “make a blocking call because you can’t use async APIs in destructors” is worse - especially when the destructor runs in a program thread instead of a GC thread.
I feel that languages which provide support for defined object ownership and lifetime (Rust, any others?) will become the future because in many scenarios object-lifetime can be nailed-down by the compiler and thus eliminate the need for GC or ARC.
Earlier quoted context omitted.
My limited understanding is that high end Unity devs code their stuff not to make garbage. Unity has a very nice system for profiling that sort of thing. Also, CLR has F#, which I like much better than Scala (and, no type erasure in CLR), Clojure which is ... just like Clojure on JVM, and C#, which as a Java dev since 1.1 I have come to prefer as a language even as I remain JVM ecosystem preferring on the server side…
Totally agree. C# and kin are far better designed. It's the lively Java ecosystem that keeps me around as well
Earlier quoted context omitted.
10 ms isn't all that much. When games load in assets they'll do various things like malloc huge chunks and you lose a few frames. If GC only causes occasional (maybe every 2 minutes) loss of a frame or two it should be no problem. If you watch benchmark FPS traces that count every frame delay you'll see that occasional stutters happen in basically every game. Loss of a single frame just isn't noticeable
> When games load in assets they'll do various things like malloc huge chunks and you lose a few frames. Streaming/Loading assets in the main render thread is a very 2005 thing to do.
Earlier quoted context omitted.
Ah yes, parallel stream(), for when you need to filter a list of 13000 entries for.... Reasons. Bad reasons. Use it all the time :)
I tried it once on a simple monte carlo thingy and legitimately said "wow!" out loud when it just worked. God, all the fussing with threads and fork-joins and mapreduces and god knows what everyone else wanted me to do: gone. Gone!
One thing you should know is that parallel streams use default thread pool unless you specify otherwise. Had that choke up some REST handler threads a few times. If you think it might be an issue make sure to specify a different pool
Anybody know how the graal project ties in with all of this? Is oracle effectively developing 3 different JVMs (OpenJDK, Oracle JDK, GraalVM)? Or is there some sort of convergence plan? From what I understand, graal has made a lot of headway with language interop, as well as a handful of specific memory optimizations and native compilation, but overall is lagging in pure throughput/latency performance behind hotspot.…
Oracle JDK is just the Oracle(TM) Supported branding of OpenJDK, now. As of Java 11, there are no feature parity or real technical differences between OpenJDK or OracleJDK, just support/EOL differences from vendors. So, that's pretty simple. GraalVM is... complicated. There are a few parts to it: 1) An advanced JIT compiler, written in Java, and distributed as ordinary maven/jar packages, etc. You can use it yourself…
I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework. Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javas…
just had this conversation with a co-worker today. java is a stable api but it also doesn't evolve. The tradeoff is you get a program guaranteed to work no matter the upgrade vs being able to build better toolage. React changes every year or 2. It is exhausting. But you get way better patterns and some things that drastically improve productivity.
Also keep in mind that React is a library, not a language. If you want to compare things, compare Javascript to Java, or the Java stdlibs to React. Maybe that's what you meant when you said Java.
IMO, Java and its libraries are nicer to work with solely due to its static nature and OO design. It is worlds apart from a scripting language when you need to refactor, or even just understand, legacy code. And if you can't even run tests on that legacy code anymore, like a React project over a year or two old?
What are the better patterns and productivity boosts you get from React vs. a Java ecosystem?