Tag: scala

JavaChannel’s Interesting Links podcast, episode 14

Welcome to the fourteenth ##java podcast. Your hosts, as usual, are Joseph Ottinger, dreamreal on the IRC channel, and Andrew Lombardi from Mystic Coders (kinabalu on the channel), and it’s Wednesday, February 7, 2018.
As always, this podcast is basically interesting content pulled from various sources, and funneled through the ##java IRC channel on freenode. You can find the show notes at the channel’s website, at javachannel.org; you can find all of the podcasts using the tag (or even “category”) “podcast”, and each podcast is tagged with its own identifier, too, so you can find this one by searching for the tag “podcast-14”.

  1. javan-warty-pig is a fuzzer for Java. Basically, a fuzzer generates lots of potential inputs for a test; for example, if you were going to write a test to parse a number, well, you’d generate inputs like empty text, or “this is a test” or various numbers, and you’d expect that your tests would validate errors or demonstrate compliance to number conversion (this is a way of saying “it would parse the numbers.”) A Fuzzer generates this sort of thing largely randomly, and is a good way of really stressing the inputs for the methods; the fuzzer has no regard for boundary conditions, so it’s usually a good way of making sure you’ve covered cases. The question, therefore, becomes: would you use a fuzzer, or HAVE you used a fuzzer? Do you even see the applicability of such a tool? There’s no doubt that it can be useful, but potential doesn’t mean that the potential will be leveraged.

  2. Simon Levermann, mentioned last week for having released pwhash, wrote up an article for the channel blog detailing its use and reason for existing. Thank you, Simon!

  3. Scala is in a complex fight to overthrow Java, from DZone. Is the author willing to share the drugs they’re on? Scala’s been getting a ton of public notice lately – it’s like the Scala advocates finally figured out that everything Scala brought to the table, Kotlin does better, and with far less toxicity. If kotlin wanted to take aim at Scala, there’d be no contest – Kotlin would win immediately, unless “used in Spark and Kafka” were among the criteria for deciding a winner. It’s a fair criterion, though, honestly; Spark and Kafka are in fairly wide deployment. But Scala is incidental for them, and chances are that their developers would really rather have used something a lot more kind to them, like Kotlin, rather than Scala.

  4. More of the joys of having a super-rapid release cycle in Java: according to a post on the openjdk mailing list, bugs marked as critical are basically being ignored because the java 9 project is being shuttered. It’s apparently on to Java 10. This is going to take some getting used to. It’s good to have the new features, I guess, after wondering for years if Java would get things like lambdas, multiline strings, and so forth, but the rapid abandonment of releases before we even have a chance to see widespread adoption of the runtimes is… strange.

  5. James Ward posted Open Sourcing “Get You a License”, about a tool that allows you to pull up licenses for an entire github organization – and issue pull requests that automatically add a license for the various projects that need one. Brilliant idea. Laziness is the brother of invention, that’s what Uncle Grandpa always said.

JavaChannel’s Interesting Links podcast, episode 12

Welcome to the twelfth ##java podcast. Your hosts are Joseph Ottinger, dreamreal on the IRC channel, and Andrew Lombardi (kinabalu on IRC) from Mystic Coders. It’s Tuesday, January 23, 2018.
As always, this podcast is basically interesting content pulled from various sources, and funneled through the ##java IRC channel on freenode. You can find the show notes at the channel’s website, at javachannel.org; you can find all of the podcasts using the tag (or even “category”) “podcast”, and each podcast is tagged with its own identifier, too, so you can find this one by searching for the tag “podcast-12”.
Not an “interesting link,” but we discuss data formats – JSON, XML, HOCON, YAML, Avro, protobuff, Thrift…

  1. Java 9.0.4 has been released, as part of the scheduled January update. NOTE: This is the final planned release for JDK 9. This is scary; see also Azul’s post, “Java: Stable, Secure and Free. Choose Two out of Three,” which points out that with Java’s new rapid-release schedule, you’re going to have to be out of date, insecure, or financially on the hook to … someone to keep up with security releases. We’ve been wanting new features in Java for a long time; we’ve been wanting more churn in the JVM, too. Looks like we, as an ecosystem, might get to experience what Scala goes through every few months, except at least we have the option of stability somewhere.

  2. Speaking of Scala, we have “10 reasons to Learn Scala Programming Language.” It actually has some decent points to make… but makes them with Scala. That’s dumb. There’s nothing that Scala really offers you that Kotlin doesn’t, and that’s assuming Java 8 and Java 9’s improvements don’t turn your crank themselves. It’s almost got a point with Spark and Kafka (well, it mentions Spark, Play, and Akka, and I’m going to pretend that the author meant to say “Kafka” instead), but… when that’s your real lever for learning a language, it’s time to admit that the language was a mistake.

  3. DZone: “Java 8: Oogway’s Advice on Optional” is yet another attempt to justify Optional in Java. It has a fair point to make: “Optional is not a replacement for the null check. Rather, it tries to tell the caller about the nature of the returned value and implicitly reminds the caller to handle the absent cases.” But … okay. So what? In the end, you still have to write what is effectively pretty simple code, and adding the semantic turns out in practice to mostly add noise to your code without actually making it any better.

  4. DZone: “An Introduction to Hollow Jars”, which I found fascinating but I don’t know why. A “hollow jar” is apparently a deployment mechanism where you have two deployable components: the main one, the “hollow jar” basically has the other component – which is the actual application code – in its classpath, and serves to invoke the entry point of the application. The invoker would theoretically change very rarely, and therefore could be baked into a docker image or some other base image, and the component that changes more often would be soft-loaded at runtime.

Interesting Links – 14-Feb-2017

  • From DZone: Distributed Systems Done Right: Embracing the Actor Model is a reference to a webinar (ugh, “webinar”) from Lightbend on, well, the Actor Model, a way of representing distributed services. Powerful model, even if you don’t use Actors as described.
  • TwelveMonkeys is a set of additional plug-ins and extensions for Java’s ImageIO. It includes BMP, TIFF, JPEG, PNM, and a few others.
  • From user u1dzer0: Awesome Asciidoctor: Include Partial Parts from Code Samples describes how AsciiDoctor can extract, well, partial code samples from a block of code. Given Java’s verbosity (not a bad thing, but a still thing that many people don’t like), having a way to ignore code can help focus on relevance. (Also see: Dexy.)
  • JSON is the new Data Transfer Object is a short reference to JSON – Javascript Object Notation – in Java EE. JSON is becoming one of the more popular serialization formats (and I use “becoming” sarcastically – it’s very popular already). For better or for worse, it’s time. This isn’t a long article, nor is it very deep – but it touches on something that’s become more and more important over time.
  • The Deadly Diamond Of Death In Java 9’s Module System discusses a problem Java 9 has with automatic modules, when a dependency has two names but one resolution path. (Confused? Read the article – it describes it better than I do, but at much more length.)

An Aside About Scala

A mailing list that was pretty popular back in the day recently had some activity asking about Java 8. The discussion itself was a little bit interesting, including a reference here and there to other languages… like Scala. Kirk Pepperdine wrote a post that absolutely riveted Your Humble Author, and may have actually convinced him to stop bothering with Scala except where absolutely necessary. I’d like to quote it here, since Yahoo!’s web page formats things poorly sometimes:

I personally don’t feel that Scala offers any advantages over Java. If you take away the opinions on style, I’d argue that moving to Scala actually leaves you at a slight disadvantage. First, point, the JVM support for languages other than Java was quite poor until Nashorn. Nashorn was actually 2 separate projects. One to get JS running in the JVM and the second was to refactor the JVM to isolate the APIs needed to support alternate languages. Scala hasn’t been able to take advantage of those changes as of yet and I’m not sure they are interested in doing so. Next is tool support. The Java tooling chain is and remains quite broken in 8. I fear that this situation will get slightly better in 9 but then changes there will batter the tooling china quite badly. Unless the Scala people step up to the plate (and there is no evidence of them doing so to date), the dismal state of the tooling chain in Scala will continue to get worse. I currently see very little motivation for companies to invest in the work needed to improve the tooling in Scala. Though I see that this might change, every time I’ve previously thought it might get better, something in the market changes and Scala takes a hit and things don’t get better so my track record on predicting this is admittedly very poor. But then I’m predicting improvements in this area and they’ve simply not happened.
What makes me more hopeful is that I know of a couple of very big projects running in stealth that are based on Scala. These projects are big enough that they’ve really been hurt by the weak tooling story in Scala and I imagine or can only hope that they will start to look at fixing the problems they are facing. Many of these problems are baked into the JVM so to fix them, we need to further fix the JVM’s support for alternate languages. The feeling I get coming from some JVM developers is that it’s the JVM that is past EOL. Maybe Graal will be the thing that replaced HotSpot… not sure… all I know is that the JVM is past due for a huge refactoring and simply don’t see anyone.. certainly not Oracle funding that effort.

I’ve “played”with the new features and to be honest find the Scala implementations cleaner and easier to write and understand.

To say that Scala is less verbose than Java maybe true in the small but I’ve found it not to be so true in the large. Reachability in a language is very important and deserved or not, Scala as the reputation of not being so reachable and hence not so readable. IME, almost everyone one I know struggles with the readability of Scala even those that have been using it for quite some time. This is not to say that Scala code can’t be read, it’s simply that Scala code not naturally easily readable and hence people struggle with it.
I think we had the same types of problems with Smalltalk. People resisted Smalltalk for some of the same reasons and in cases where C/C++ wasn’t so desirable we saw teams jumping to Java. In this era I think the current alternative to Java is Go. The buzz around Go is more marketing and hubris than reality but it has a buzz and level of activity that feels familiar to the buzz that we say with Java in it’s early days. Just like people kicked the tires and sniff around Smalltalk and then moved on, I get the same sense here with Scala.

Java is starting to give under its own weight of patched-on features, IMHO.

On the contrary, I think that Brian has done a wonderful job integrating Streams and Lambda’s into Java. The only thing I can complain about that makes things a wee bit difficult is this aversion to mutable state. Fine if you don’t like mutable state but that streams make the mutable/immutable decision is an overreach on Brian’s part. It disallows a valid model that we need to work in. It’s different than how everything else works in the language. Streams are inherently single threaded and thus concurrent modification of state is a concern that lies outside the internals of a Lambda expression. IOW, Java != Scala in that Scala had immutability baked into (just about) everything right from the beginning. Brian did consider these points when he designed Lambdas and he opted for his bias towards immutability.. so be it.. All I know if that Lambda’s do not feel like they are patched on to me. They feel like a natural part of the language… much better than the earlier proposals that were tabled. The work on ValueTypes and type inference is also focusing on making sure that the added features do not feel like bolted on bits and that they fit naturally into the current language. Brian’s idea was to create small changes in the language that have a huge impact on your code. While I don’t agree with all of his choices I do think he’s done a brilliant job.
Regards, Kirk

Interesting Links, 31 Oct 2016 (and 25 Dec 1038)

  • kumuluzEE is “A lightweight framework for developing microservices using standard Java EE technologies and migrating existing Java EE applications to microservices.” It’s not immediately clear from the web page what makes it ideal for migrating to microservices, but there it is.
  • “Don’t Even use COUNT(*) For Primary Key Existence Checks” has some valuable performance advice, and considers multiple DB implementations while offering it.

Now for some Scala stuff:

  • “Quo Vadis, Scala?” has some considerations of the value of Scala on the larger JVM ecosystem. Turns out that Scala has more impact than some think it does, and less impact than others think. Go figure. 🙂
  • “Sbt makes me want to give up Scala” has some well-considered criticisms of the Simple Build Tool, SBT, Scala’s primary delivery mechanism. Well-written and justified; if a build tool is the primary contact point someone has with a language, and that build tool is slow and uncomfortable to use, well… that impression is going to stick with people. SBT is really powerful… and it sucks. This post walks through a lot of why.
  • From user tetero, apparently inspired by the SBT link, “Scala Collections: Why Not?” is a video presentation by Paul Phillips that feels like it’s a rant about why he’s leaving Scala: it doesn’t do things the way he wants. Sure, what he wants would be good (simplicity, accuracy, honesty, clarity) and it highlights what people see as the worst in Scala: the community’s hardheadedness about how good Scala really is. It turns out to be an anti-Scala rant, in the end, but the truth is that Scala is better than he makes it sound and just as bad as he makes it sound. Use Scala if it works for you, and don’t, if it doesn’t. (The user in question said that this video was part of what led him to Clojure. There’s nothing wrong with Clojure, but like most things, it’s not perfect and Scala’s type system oddities seem like a poor sole motivator.)

Tags on javachannel.org

Articles on javachannel.org are going to start using Odersky’s “Scala Levels” as tags for new content (with old content being rated as they get maintained over time, possibly).
The levels are in two groups: A1, A2, A3, and L1, L2, and L3. The “A” stands for “application;” the “L” stands for “library.” Put simply, the features that tend to be found in applications and libraries are different; an application can prefer concrete types, whereas a library tends not to (if able); the skills and knowledge for writing applications or libraries are different.
An A1 programmer is a beginner at Java; an L3 programmer is expected to really know the language and its features well.
The skills are grouped like: A1, A2/L1, A3/L2, L3. The idea being expressed here is that before you should design a library, you need to be moderately skilled at Java – a beginner shouldn’t bother worrying about expressing ideas in a library.
Odersky actually grouped concepts for Scala in each level (for which he’s gotten some scathing criticism from Tony Morris, for example); eventually, I’d like to have the same kind of groupings for Java, if only to establish a baseline (which is what Odersky was doing, and what Morris apparently missed, in his quest for overreaction. Tony’s a brilliant guy, but like so many other brilliant people in this field, he’s desperate to find points of contention, and then wring them dry. Astute readers might note that Tony’s critique has no way through which to offer commentary…)
So: What you’ll start seeing is tips on javachannel.org being grouped by these levels by tags; the higher the level, the more complex the content is.