Snyk JVM Ecosystem Report 2021

...has just been released: https://snyk.io/jvm-ecosystem-report-2021 and gives quite interesting overview of the Java world we're living in. Full version (33 pages!) is free and available for download under this link .

Key takeaways

1. AdoptOpenJDK dominates - 44% of developers uses this distro. Interesting point - Amazon Corretto gets only 9% share. Sounds as if the community learnt not to trust corporations ;-)
2. Systems move away from Java 8 (more use 11 in production already). Also, more than 25% of the Java developers use Java 15 in development. That's a good thing showing that ecosystem is healthy and alive.
3. Kotlin is the second most important language on the JVM (more popular than Groovy or Scala). There are also 531k repos in Kotlin on Github as compared to 194k in Scala / 64k in Groovy. One possible explanation is that Kotlin simply fixes what's broken in Java without overcomplicating things (yes Scala I'm looking at you). 

Most surprising (or are they?)

1. Maven is still the most popular build system for Java with 76% of developers using it. There is more - Maven scored better numbers than a year ago! Given high popularity of Gradle here-and-there (for example in OSS projects) and general tendency to scrap XML-based tools, this is quite interesting piece of data.
2. Domination of Spring, with more than 50% of developers using Spring Boot and almost 30% using Spring MVC. This sounds surprising as I've recently heard a lot (and I mean it - a lot) of complains about how bloated and complex Spring has become. With so many configuration modules being loaded automatically by default it's sometimes crazy hard to understand what the hell is happening when the app starts. On the other hand Spring Boot allows for startup of a new project in a mere second (or few more). Does that mean that in general developers prefer (or are required to prefer) speed of development versus quality/speed/control? 

Happy reading! Let me know if you find something surprising / interesting in the report.

JSON stringify - transformation tip

JSON stringify

Well known JavaScript method for transforming objects or values into string. However, there is an optional second parameter to the call - a replacer. Once provided, alters the stringification process.

Method

If a method is provided, will be applied to each property of an object. Very handy tool if serialised form has to have for example different values. For example:

let data = {'one' : 1, 'two' : 'a string'};
JSON.stringify(data, (key, value) => key === 'one' ? 2 : value)
// "{"one":2,"two":"a string"}"

As the object being serialized is also available (as this reference), we may perform a wider range of transformations, for example:

data = {x : 1, y : 2, multiplier : 10};
function replacer(key, value) {return typeof value === 'number' ? value * this.multiplier : value}
JSON.stringify(data, replacer);
// "{"x":10,"y":20,"multiplier":100}"

Array

Simply put - a whitelist. Only selected properties will appear in the serialised form. For example:

let data = {'one' : 1, 'two' : 'a string', 'garbage' : 'some'};
JSON.stringify(data, ['one' ,'two']);
// "{"one":1,"two":"a string"}"

To sum up - a very handy tool for quick-and-dirty processing of a bare JSON / JS objects.

Full reference here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify

How to fix: Webpack file-loader corrupting fonts

The problem

Recently I've been forking on a fairly simple React / Webpack application, built with newest CRA (https://facebook.github.io/create-react-app/).
Everything was fine in the development but when I built a production package, I started noticing strange warnings in dev tools console. All of them concerned fonts loading, for example:

Failed to decode downloaded font

OTS parsing error: incorrect entrySelector for table directory

OTS parsing error: incorrect file size in WOFF header

After short investigation it became apparent that file-loader is not able to handle WOFF or TTF fonts correctly, returning empty content.

The solution

Webpack allows for configuration of loaders per file name pattern. Therefore it's fairly easy to switch fonts loading to use URL loader instead of file loader. Just add following right before generic file loader kicks in (typically - last entry  in module/rules/oneOf):

{
 test: [/\.woff$/,/\.ttf$/],

  loader: require.resolve('url-loader'),
  options: {
    limit: 150000,
    mimetype : 'application/font-woff',
    name: 'file?name=static/media/[name].[hash:8].[ext]',
  },

},

Now all of your fonts will be served as embedded data URLs. This obviously will make resulting package bigger and will prevent separate caching of fonts - it's a tradeof. Also please make sure you set appropriate limit so that all "offending" fonts are captured!

REST API cook book

Introduction

Recently I've stumbled upon an interesting site - REST Cook Book. As nowadays almost everyone develops RESTful APIs and there is a great deal of controversy regarding how to design it properly (say: singular vs plural nouns or collections range query) I decided to take a look at the "recipes" Author serves.

The recipes

First of all, the site is NOT a REST API design guide. Instead, Author decided to write a bunch of short articles concerning some interesting pieces of frequently asked questions. Second of all, Author seems to be focused on HATEOAS (Hypertext As The Engine Of Application State) which differs a bit from "JSON with RPC" style as commonly found in modern Java web applications. The most important difference is that HATEOAS does not care so much about URL structure, as each possible operation for a resource (in other words - possible transition from current state) is returned in form of link / rel / href.
Nevertheless it's an interesting read. Typically authors write a lot about the basics - like mentioned singular vs plurals or how to use basic HTTP methods. Here, we get recipes concerning such rarely discussed aspects as:

• collection pagination - with link rel = next / first / last 
• discovering supported HTTP methods with "OPTIONS" 
• implementing asynchronous operations using 202 "ACCEPTED"

There is also a lot of discussion under almost every recipe, which is very resourceful. 

Resource-oriented client architecture (ROCA)

What is ROCA ?

Recently I've encountered ROCA - resource-oriented client architecture, which is a lightweight set of recommendations / guidelines for a good web application architecture. It's available here: http://roca-style.org.

Downsides

After reading thru I can say that authors tended to stay conservative in their approach, especially regarding front-end. It's usually a good thing, as typical development process usually relaxes the rules set at the beginning (due to lack of time, business pressure etc.) so being too constrained at the beginning usually means appropriate constraints at the end ;-)
In ROCA case however, I have following comments:

"JavaScript is used unobtrusively and the application remains usable (albeit with a decrease in usability and convenience) if JavaScript is disabled."

Well, this one is rarely possible nowadays. Most rich web applications use a lot of JavaScript not only to make UX better, but also for core processing (transformation of data from REST, validation etc.). For applications (SPAs) based on JS frameworks (Angular, vue, react, ...) it's totally impossible. It's also not practical to provide a separate, HTML-only version for clients without JavaScript, taking into account decent support of JS by all modern browsers and OSes.

"The same functionality must not be implemented redundantly on both the client (JavaScript) and the server. Thus, due to the application logic requirement, application logic must not reside on the client-side."

This one is also hard to apply in modern web apps. I believe that it's good to minimise redundancy, especially regarding "heavy" business logic. But parts like data validation are often implemented in both places. Backend needs to do it in order to maintain data consistency. Frontend needs to do it in order to provide better user experience (interactive feedback).

"All JavaScript code and CSS code must be static, and must not be dynamically generated by the server in a form specific to the resource requested"

Out of my personal experience, there are some solid cases when JavaScript has to be generated online. One example is a distributed system in which parts (let's call them "microservices" ;-) ) can be turned on/off, virtually enabling/disabling parts of the frontend. Then, such change has to be reflected in JavaScript returned. However these are very specific and therefore limited cases.

Upsides

Rest of the rules I'm OK with. Some sound very basic in modern world (like "server adheres to REST principles" or "client uses RESTful HTTP queries"). Others, however, are more tricky, easy to miss during web app develpoment and should be reminded, like:

"A user must be able to link to a specific piece of information, e.g. by copying the address from the browser's address bar and pasting it into an e-mail, creating a bookmark, or using any of the fancier ways to share URIs."

or

"The browser controls like the back, forward and refresh buttons must work as expected. I.e. the back button should take the users where they expect to be taken to (the last meaningful resource they worked with). A browser refresh should not cause a re-rendering of the login or home page instead of the page the user was looking at, or a (to the user) unexpected question about wanting to submit the same data again (when the user doesn't recall submitting any data, indicating a mis-use of the POST verb)."

Summary

To sum up, I think that ROCA is a good idea worth reading (especially during project's start). However as any given kind of recommendations, should be applied carefully, with respect to the domain and problem.