Javachannel's interesting links podcast, episode 5

Welcome to the fifth ##java podcast. I’m Joseph Ottinger, dreamreal on the IRC channel, and it’s Monday, 2017 October 23.
This podcast covers news and interesting things from the ##java IRC channel on Freenode; if you see something interesting that’s related to Java, feel free to submit it to the channel bot, with ~submit and a URL to the interesting thing, or you can also write an article for the channel blog as well; I’m pretty sure that if it’s interesting enough to write about and post on the channel blog, it’s interesting enough to include in the podcast.

  1. First up, we have a DZone entry; DZone‘s actually really good at picking out content that’s interesting. However, sometimes you have to be fairly selective about what you read, because they end up like a lot of such sites and go for volume and consistency in publishing as opposed to being selective for stuff that’s truly relevant. That’s why you have things like this podcast, of course, because I clearly know what’s interesting and relevant more than they do! Anyhoo, the actual reference is for Eclipse: “Fifteen Productivity Tips for Eclipse Java IDE Users,” and they’re pretty good; none of them are what I would consider the most obvious (which is: “Use IDEA instead”). The truth is, Eclipse is very popular; anything that helps people use their tools more efficiently is a good thing. Some of the tips are fairly obvious (“use the most recent version of Eclipse”) and others are just things that experienced users might know and use already, but that’s the benefit of articles like this: they make sure that everyone has a baseline of competence. Other tips: switch editors with ctrl-tab; group related projects in working sets rather than using multiple workspaces (this is one of Eclipse’ better features, and I’m glad it’s here); download the sources of libraries; conditional breakpoints and watchpoints; leverage code coverage. There are more (nine more, making a total of fifteen, as the article title promises), and none of them are awful.
  2. Next up: Java 8 updates have an end-of-life: September 2018. Along the way, new versions of Java 9 and Java 8 have been released (9.0.1+11 and 8u151/8u152) – which is good, I suppose, although expected with a new major release – but the big news here is that Java 8 is going to see no more public updates after September 2018. Progress marches on, but I have a feeling this is going to be like the Java 7 migration – which is still ongoing. We aren’t seeing as many people saying they’re still on Java 7 – or Java 6 – as we used to, which is anecdotally a good signal that people are moving to Java 8 after all. So who knows? Maybe with such a recent mass migration to Java 8 there will be momentum to allow people to move to Java 9 – especially if they don’t have to use the module system yet – and people will stay more current.
  3. More DZone: they’re on a roll (and sneak preview: they have two more links after this one). The entry this time is “Artificial Intelligence: Machine Learning and Predictive Analytics.” It’s a fairly high-level guide, and being on artificial intelligence, it’s not just Java – and shouldn’t be. It’s a good reference, though. It’s well-done. I would love to see Java be more relevant in AI; it’s certainly relevant, and is a major player in the space, but the truth is that the starting point for AI is in Python, not Java. The same goes for natural language processing; you can find tools in Java, to be sure (Stanford NLP, for example), just like you can find AI resources in Java (WEKA, among others) but they’re typically trailing the cutting edge. Most data scientists would see a preference for Java as a bit of an affectation. (And I say that because I do prefer Java, and the data scientists I know think I’m a loon for that. They’re probably right.)
  4. This is an old link, but it showed up on my feeds recently, so I’m pretending the publication date of May 16, 2017, is badly inaccurate: Java 8u131 – and yes, 131, 151 is the current build – is transparently aware of Docker memory and CPU limits. Why is this important? It’s because older builds were, well, not aware of Docker‘s machine limitations. The idea is that Docker runs a constrained virtual machine; your actual machine might have 16Gb of RAM, but your Docker image might have 2Gb available to it, and only two of your eight cores. But if you ran an older build of Java in that Docker image, it would use the actual physical machine limits to gauge heap allocation limits and CPU core usage – which could obviously cause problems (your 2Gb image would allocate heap as if it were on a 16Gb machine, which would be incorrect). So… I guess, what with this information being fairly stale, it’s good that they fixed this. And if you happen to be running an older Java, update, please. Note that you do actually need to tell the JVM to use group memory for the heap. This is via two command line options: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap.
  5. Another DZone article! This one is “Automata-Based Programming in Spring.” It really serves as a bare introduction for Spring Statemachine, which isn’t quite what the title led me to expect – I was thinking that I was going to get to read about how to apply cellular automata for problem solving, a la Wolfram Alpha, but instead it’s just a library that makes state transitions easy to manage. It’s a Finite State Machine, not Cellular Automata. This is on me for reading it wrongly, by the way; FSMs are automata, but not cellular in nature.
  6. Daniel Dietrich wrote an article called “Opinionated Database Access in Java” – because we all know that database access has no opinion involved at all, ever. In this case, he’s writing a library that provides yet another abstraction: this one leaves modeling to the database; complex queries are moved to the database; access should be simple and obvious. In other words, it’s one of the Java libraries that provides access to the database services, as opposed to backing up Java data structures with a database. It’s not mature yet (and he provides an example of the API using Scala, too, so it never will be mature.) The only thing is: the article doesn’t provide a reference to an actual project, so it’s all vaporware at this point. Plus, as the lively comment flow indicates, it’s another entry in a space that’s very crowded with possible implementations depending on what you want, from ORMs like Hibernate to JDBC layers like MyBatis and jOOQ.
  7. Java’s version numbers are likely to change. Java has generally followed a semantic versioning approach: you have a major version, a minor version, and a build number (sort of). However, there’s a proposal put together by Mark Reinhold (He Who Controlled Java 9’s Release) to go to a date-based release cycle, so the next release won’t be Java 10, but Java 18.3, meaning “released in the third month of 2018.” There are a few problems with this proposal, and I’m hardly alone in seeing them: one is that there’s not a “major release” associated with the build. With Java 8 versus Java 7, there’s a clear delineation of major versions; Java 8 is the one with streams. Java 9, likewise, has Jigsaw. But the next major feature – let’s say “value types” as an example – might be in Java 18.6 as opposed to Java 18.3, so we lose the ability to easily determine feature groups. Plus, Java applications will have a harder time determining the actual baseline versions they require; right now they can parse out the major version and say “Oh, I’m on Java 8 instead of Java 7” but now they’ll have to factor in the actual release year. Maybe it’s me being a curmudgeon, maybe it’s me resenting how Mark handled the Java 9 release, but I think semantic versioning is still better than the year/month release versioning. With Reinhold proposing it, it’s likely to be approved by fiat; I’m sure it’ll grow on me over time, like a fungus, but I still don’t have to like it. Now get off my lawn!
  8. Last week I highlighted Excelsior JET, which allows delivery of native binaries using Java 8 (so far). This week, we see Steve Perkins writing “Using Java 9 Modularization to Ship Zero-Dependency Native Apps“, using Java 17.10… yeah, the date-based versioning isn’t something I like at all yet. Anyway, it’s just a simple “Hello world” example, but it, like others, is a good start; I like seeing articles like this, because this is how we build a repository of knowledge concerning how to use these neat new features Java 9 provides.
  9. And now for the last of our links, this one also from DZone: “OpenLiberty.io: Java EE Microservices Done Right.” OpenLiberty is another microservice framework, like Spring Boot, DropWizard, or Vert.x, this one focusing fairly heavily on canonical Java EE APIs (as opposed to leveraging those APIs where appropriate as Spring Boot or DropWizard do.) It’s billed as a “deep dive into OpenLiberty,” but it’s really not; it’s really a cursory example with a single JAX-RS endpoint (although it does show live redeployment, which is neat.) The actual OpenLiberty sample application isn’t much to speak of; the redeployment is important, but the main thing the article shows is configuration of the OpenLiberty build, which is probably the most important thing it should want to show. It’s interesting; it’d be interesting to try out.

Interesting Links podcast, episode 2

Welcome to the second ##java podcast.
We have lots of interesting things to cover, so let’s dive in.

  1. Java EE development has moved to the Eclipse Foundation, under the project name “Eclipse Enterprise for Java“, or “EE4J.” Java EE is still the branding for enterprise Java. This move makes Java EE more open; we’ll have to see how well it works under the Eclipse Foundation. We’ll survive either way; it’s a good move for everyone.
  2. RebelLabs’ Developer Productivity Report 2017 is here, almost 72% of the developers said their main programming language is Java 8 – and about time, considering Java 7’s been dead for two years; IntelliJ IDEA is the most popular Java IDE at 54% with the respondents, and one of the survey questions says that 91% of the people who like it said it’s because of superior functionality, as compared to 13% of Eclipse users and 73% of NetBeans users. Some other things that stood out: small teams are the norm, with teams of three to nine people making up half the teams, with medium-sized teams (10-19) coming in at 22%. Hmm, maybe a team of nine people isn’t actually all that small. It’s a great report; you should check it out.
  3. Given Java 9’s release and new features, it’s expected that a lot of migration articles are coming up. Sure enough, DZone’s in play with one that shows migrating a Spring app to Java 9. It has some module-based concerns and walks through fixing them; it’s not exhaustive, but it’s likely to be representative of early adoption efforts.
  4. Nicholas Frankel discusses some clean coding standards around lambdas. It’s easy to decide that a tool is available and thus must be used everywhere, he says – actually, he says that developers act like children and we have to play with our new toys, which is probably a pretty appropriate description. He shows a fairly ugly way to use lambdas primitively, then shows how it can be made a lot more developer-friendly. It’s not exhaustive, but still worth looking at.
  5. According to InfoWorld, Java 9 is not going to receive long-term support. That doesn’t mean it’s not supported, but that the long-term support plans are different than what we’ve seen in the past. Long-term support releases are going to be made every three years, so that’s the baseline for support plans; we’ll have to see if (and how) this affects Java in the long run.
  6. Up next: another DZone link, this time on Java’s Optional. The author, Eugen Paraschiv (from Baeldung) offers Optional as a tool for functional programming, and I suppose he’s right, in a way. The article does a good job of walking through most, if not all, of what Optional can do for your code, including with Java 9, and he does say that Optional is meant as a return type and not a property type, which is … better than he could have done. The article’s worth reading, and is done at much more depth than many similar articles.
  7. We also saw mention of OpenTable’s embedded PostgreSQL container. This allows us to treat PostgreSQL as if it were an embedded database (well, sort of); considering that PostgreSQL is a lot stronger for production use than, say, H2 or Derby, this is a nice way to do database-oriented integration tests on a “real database.” That’s not to say that H2 or Derby aren’t real databases, but they’re anecdotally used in the Java ecosystem more as embedded databases to help with integration testing than as production databases. Of course, now that I’ve made that assertion, I expect RebelLabs to ask something about this on their next survey and completely demolish my statement. Thanks ahead of time, guys.
  8. A bit more on Java 9. RankRed has “What’s new in Java 9,” covering a bird’s-eye view of the changes: the module system, new versioning, the Java Shell, a better mechanism for compiling for older versions of Java, JLink, compact strings, high definition graphics, new factory methods for collections – catching up to Kotlin and Scala, better networking and serialization security, Nashorn changes, a new random generator, segmented code caches, dynamic linking of object models, and an enhanced garbage collector. Whew, that’s a lot – and I left some out. It gets better, though: The Java 9 readme points out that the default JCE policy files now allow for unlimited cryptographic strengths, a feature that the RankRed list left off.
  9. Spring 5.0 has gone to general availability – it’s been released, in other words. Support for Java 9, Java EE 8, functional variants, Kotlin, a new reactive web framework… all kinds of goodies for Spring fans.
  10. Kotlin 1.2 Beta is out. Kotlin is another JVM language; this one’s from IntelliJ, the people who bring you the IDEA editor family. There are a lot of little improvements here, including some things that can drive you crazy during normal development – there’s also multiplatform support, which is important even if you’re like me and only really deploy on the JVM.
  11. We mentioned ZeroTurnaround early in the podcast – the RebelLabs report – but it’s worth noting that in addition to the developer survey, they also released JRebel 7.1, with Java 9 support, Spring 5 support, and a bunch of other things too.

Okay, that’s this week’s podcast – thanks for listening.

Interesting Links, 9 Feb 2016

  • From Parks Computing, a short word of advice in “On Recruiting” for the movers and shakers (and those who want to be movers and shakers): “The quality of your company’s software will never exceed the quality of your company’s software developers.”
  • DZone is back with a few interesting posts: “OpenJDK – Is Now the Time?” starts by wondering is OpenJDK is reaching critical mass to the point where it should be considered instead of the standard Oracle JDK. It’s an odd post.
    • It points out that if Google had used OpenJDK instead of Oracle’s libraries, the lawsuit might not have happened (Editor’s note: it might have!). This is a good point.
    • It says that the deployment options might open up, with standard package management instead of a custom update process specific to Java. This is also a good point.
    • It points out that OpenJDK’s performance and scalability is the same as the Oracle JDK. This is… not a good point. The codebases are the same (they’re routinely synchronized: code in one will be in the other eventually.) Oracle’s JDK is effectively OpenJDK with some closed-source libraries, so Oracle’s JVM can write JPEGs natively (and some other features like that.)
    • It also points out community improvements to OpenJDK – “As open source developer’s continue to provide insight into the source code, it is likely that OpenJDK could begin to outperform the version released by Oracle.” Um… since the codebases are the same, that’s not likely to happen much at all.
  • From ##java, cheeser had a beautiful expression of reference equivalence. Someone was asking about how two references (A and B) pointing to the same object work – cheeser said, “If B is your *name*, A would be a nickname. Both of them mean you so anything said to either name or nickname both go to you.
  • Fix PATH environment variable for IntelliJ IDEA on Mac OS X” describes a way for OSX users to provide the OS’s PATH to the popular IDE. It turns out that programs installed via brew aren’t necessarily available to IDEA unless you start IDEA from the shell – which few do. It’s easy to fix; this post shows you how.
  • Another from DZone – they’re on fire! – Per-Åke Minborg posted “Overview of Java’s Escape Analysis“, which discusses what escape analysis is (it’s a way of determining the visibility of an object) and what it means for performance. (If an object isn’t used outside of a method or a block, it can be allocated on the stack rather than on the JVM heap – and as fast as the heap can be in Java, the stack is much faster.)
  • Pippo is a new, very small microframework based on services. The example looks … easy enough; take a look, see what you think.
  • Yet one more from DZone: Exceptions in Java: You’re (Probably) Doing It Wrong advocates the use of RuntimeException to get rid of those pesky throws clauses and forced try/catch blocks in your Java code. It’s an argument Spring advocates, and checked exceptions aren’t part of languages like Scala… but I personally find the over-reliance on unchecked exceptions to be terrible. The core argument against check exceptions from the article: “The old argument is that (the use of checked exceptions) “forces” developers to handle exceptions properly. Anyone on a real code base knows that this does not happen, and Exceptions are routinely ignored, or printed out and then ignored. This isn’t some sign of a terrible developer; it is such a common occurrence that it is a sign that checked Exceptions are broken.” Except no, it’s such a common occurrence that it’s a sign that developers are terrible. This article was so terrible that I’ll probably write up a better response as soon as I get some time.

Interesting Links, 25 Jan 2016

  • From ##java itself, Hot deploy to Jboss from Intellij using deployment scanner documents a problem someone had while trying to deploy from IDEA into JBoss, and discusses how to get it working. Of particular note: “The Intellij deployment options for ‘upload external changes’ (turn it on!) and ‘preserve file timestamps’ (turn it off!) have given me particular grief in the past; if you find that Intellij doesn’t seem to be picking up changes and uploading them, look at the former.”
  • J2ObjC 1.0 has been released. From the project website: “J2ObjC is an open-source command-line tool from Google that translates Java source code to Objective-C for the iOS (iPhone/iPad) platform. This tool enables Java source to be part of an iOS application’s build, as no editing of the generated files is necessary.” The UI for each platform is still written in code for that platform, but this might make porting code to iOS easier for Java coders.
  • A user on ##java posted a link to a free app he’d written for iOS devices: Trident. It’s an app that interacts with Gitlab (and Github, in early preview form), with a primary focus on discussing issues, pull requests, and files from a mobile device. This isn’t an endorsement (your author doesn’t have an iOS device) but it might be worth watching.
  • We’ve seen a lot of JavaFX questions lately – mostly they’re from a small cluster of users (therefore: a few JavaFX users, each with a lot of questions, and yes, this is anecdata.) Gluon maintains SceneBuilder, which, well, builds scenes for JavaFX, and just had a new release, version 8.1.0 of Scene Builder.
  • Feature Flags are a way to release features to specific users. Turns out there’s a hub dedicated to the method, including a reference to multiple libraries that enable limited releases in wide-area deployments. (The hub itself looks like it’s provided by the authors of Launch Darkly, but that’s okay.) It’s not a new idea, I think, but it’s written up pretty well here and it’s nice to have a hub for the capability.