Modern Java Development: updates, features, APIs and Copilot

This year at *instinctools we organized and hosted a series of online discussions with developers and IT experts. As part of the Techpora project, we wanted to hear different points of view on the events and issues concerning developers. One of these series dealt with the problems of modern Java development.

JetBrains Developer Tagir Valeev, organizer of the RigaDevDays conference, founder of the Latvian JUG Dmitry Buzdin, Developer Advocate of the GraalVM project, OracleLabs Oleg Shelaev and Java Developer *instinctools Denis Leshenyuk attended the conversation. We want to say right away that we did not set the tone for the discussion and did not put the experts in any framework. It was a fairly loose conversation that covered the most important topics for developers.

“Why does moving to a newer version of Java always raise so many questions?”

our company has recently conducted a survey on which version of Java is used most often by developers and customers. The survey was conducted in early 2021. Java 8 scored 72%, Java 11 – 42%, and in third place was the “freshest” version at that time – Java 15 with 14%. It turned out that at the time of the release of a new version of Java, it attracted interest, which then quickly faded. And one more thing: if someone uses Java from Azul, then he can sit on intermediate versions for a long time.

JetBrains developer Tagir Valeev:

I read an article by Carl Mastrangelo, who described his experience of updating applications from Java 8 to Java 16 on Netflix. The article described a very interesting phenomenon, why no one at Netflix decided to update Java in projects. Moreover, it was obvious that the new version of Java is functionally better. New solutions are always better, because these solutions are created by the development team – smart people who move the product forward. Language becomes better, more powerful, more convenient. It would seem that you need to be updated and everyone should want these updates. But for some reason, many companies and projects do not make this update.

Oleg Shelaev, GraalVM Project Developer Advocate, OracleLabs:

Mastrangelo explains in his article how he came to Netflix and updated Java. He did the upgrade gradually. Firstly, I found one library that didn’t support a straight-forward upgrade, sent a pull request to GitHub, it was accepted – and the library began to work better on Java 11. Then he went further: he updated another library, then another one, and so on.

And in a fairly short period of time (several months), he alone shoveled the system of libraries that were used on projects, and carried out a fairly painless upgrade. Why did he do it? Just because no one told him: oh, how difficult it is to upgrade to a new version of Java.

It turned out that Karl did not know that it was difficult to do but did it. As they say, you never know what you can do till you try. You are gradually moving towards the better, and that’s it. It is clear that there are companies and projects in which a particular version of Java is a functional requirement. This may be a requirement of projects from an ecosystem or a requirement of a company that has its own regulations and paid support for a particular version. But there are many projects that “know” that it is supposedly very difficult to update to Java 11, because it added var, removed the API and did something with reflection. Nobody knows what they have done with reflection, but everyone is afraid. It seems to me that updating is easy enough if you go ahead and do it.

“If you are upgrading, then you need to ensure that all dependencies support the new version”

If you are upgrading, then you need to ensure that all dependencies support the new version. And not only dependencies, but also the libraries themselves. It could be tooling, it could be a maven plugin. When Java 9 came out, many maven plugins simply broke. Moreover, it was not Jigsaw that broke them, but the fact that the format of the version had changed. The one at the beginning disappeared, it was 1.8, and it became 9 – and the parsers “raised the roof”.

Tagir Valeev:

You could have a static analyzer on CI or something depended on the asm library, which needs to be bumped from each version. Increasing a transitive dependency is difficult. Now with the transition to Java 11 there are no such terrible problems. Almost all of your dependencies that could be used reached version 11. JetBrains has its own history, it is quite difficult for us to switch to a new version of Java, since we have our own Java (IntelliJ IDEA and other IDEs on the JVM assembly). And in order to switch to the new version, we need to do a lot of work.

“I love features when something new and nice appears in a language…”

I love features when something new and pleasant appears in the language. If a feature appears, then we are engaged in its support in the IDE. Of course, it’s very cool to use records, because it allows you to make multiple returns from methods in Java in a local context. For example, I need to return two values ​​from a method and use them in the next method. Developers create some classes, such as “pair”, or write to a variable, create an array of two elements. In other words, absolutely terrible decisions come to many minds, because it was difficult to declare a class for two fields. And now it’s one line of code. It can be declared a private class, returned and used. But one more important feature I would like to note is that everything that happens with switches, how they are upgraded starts from Java 14. And records will win their place under the sun for a long time, but migrations to new switches go almost automatically. Our IDE can do this wonderfully, you switch to a new version of Java, it itself sees that this old and ugly switch can be turned into a new one, and it becomes much more compact and beautiful.

Tagir Valeev:

“You don’t need to worry at the beginning of your career that you are not on the latest Java …”

You don’t need to worry at the beginning of your career that you are not on the latest Java. The basic principles of programming are similar in all languages ​​and all versions. The ability to debug, write automated tests and structure the code is transferred from one language to another quite simply. First you need to learn how to work in a team, and then you can move on to another project where there will be “good Java”. It’s no secret that the personnel market in IT is at the peak of the “bubble”, so it’s not difficult to change jobs for more interesting ones.

Dmitry Buzdin:

Here is another question: how useful will it be for you to follow the innovations if you work on Java 8? Will new knowledge be deposited in your head or after the first difficult release on your project this knowledge will simply be “washed away”.

Java Developer *instinctools Denis Lesheniuk:

You can’t keep track of all the technologies. If you are a Java expert, then you can follow all the latest in the language. But you, for example, read about shenandoah or about some “GC-things”. But in practice, not everyone will have the opportunity to “touch” them or gain experience comparing different GC algorithms. And then the question arises: do you need it or not? You’re either going into product development, or you’re doing tooling and an open JDK. These are completely different directions, they are hardly worth comparing. In the world, there are quite a few specialists involved in the development of the JVM. This is very interesting and may be the peak of an intellectual career, but perhaps not everyone needs it. For a developer, the main thing is to choose your stack and technologies, and then it’s enough to read release notes, go to events, and communicate. Finding a job where there will be enough opportunities for development is quite simple today.

Dmitry Buzdin:

It is impossible to know everything, there is a lot going on around. Keeping track of everything new is simply unrealistic and not worth trying. You always understand that you have a specialization, you are engaged in a specific area and in a specific project. In this area, get as deep as you need to solve your problems. When digging deep, try to look wide. Write sometimes in another programming language, at least at the “hello world” level. I write in Java, but look at what’s new in C#. I don’t write in C#, but I’m curious because everything that appears in C# today may be in Java tomorrow.
Look around you, you won’t be able to immerse yourself in everything deeply, but it is quite possible that you will read about another language, and in 2-3 years something similar will be “brought” into yours. And if they don’t “deliver”, then you will understand that new knowledge has changed your worldview and helps to solve the problem that you are now facing. Don’t stop learning, try to learn something new, it helps to keep your brain in good shape, and you will be efficient for a longer period of time.

Tagir Valiev:

“Software development is always a story about money”

Software development is always a story about money. In cloud services, memory is one of the most expensive resources. Typically, the CPU in projects is not used “to the full”, but the memory in Java projects is often fully selected. This is because the full “stuffing” of Spring is 200 megabytes, if we do less, we will get an error. This is the reason why many companies go for Go. They make a microservice on Go, it takes up 50 MB of RAM, the customer or developer calculates how much it will cost him in terms of money, and instantly makes a decision.
Based on the microservice architecture, we can assume that the project will have, for example, 20 microservices. It turns out that 150 MB of overhead from each spring, and we need to count on three replicas, several tens of gigabytes are eaten. And the main question is why? And here people start to refuse Java, despite other advantages.

Dmitry Buzdin:

“If AI optimizes something, then only overflow”

Speaking about features and development of programming, I would not underestimate artificial intelligence technologies. A few years ago there was a qualitative leap.

Tagir Valiev:

If AI optimizes something, then only a trip to stackoverflow. You write two codes. The first is systemic, which is resolved by going to stackoverflow. And here you can really get some kind of increase. But here it also turns out a lot of copy-paste code, which is not clear where it was pulled from.

Dmitry Buzdin:

The leap cannot happen because of the essence of programming. Programming is instructions. And it is possible to teach programming to AI if only we “upload” knowledge about a specific problem area into machine intelligence. Now AI can play Starcraft and find bugs, but AI can’t write code. After all, someone must translate human requirements into some kind of programming language, be it a visual language or a sign language. So far, it is simply impossible to exclude a person from software development, AI can only provide greater comfort in programming.

Imagine that we have made an AI that can program an online casino. In this case, I agree that such AI can help to make an online casino quickly. But if you look at AI as a means to close file streams and solve typical problems, then no.

It is not clear how progress will develop, but AI will be used in highly specialized things. For example, it will be possible with the help of AI to view the code to indicate to the developer, for example, where to place the cursor in order to prescribe some parameter. There will be no such a situation when a customer comes and asks to create a robot that will buy bitcoins when they cost little and sell them when they rise in price, and AI will make a jar file. The job of software developers is likely to get easier as AI technology advances. Most likely, it will be the same as with translators. There are many applications for translation, but in fact complex translation or important meetings are carried out by professional translators, not programs. People de facto solve some critical issues, and AI in programming can also develop along this path. It is possible that developers will write only tests, and AI will write code.

Oleg Shelaev:

“It’s nice that you write only 30% of the code, and you get money for 100%”

GitHub Copilot has been released recently and can be used by invitation only. But on Twitter, you can see posts already in which developers demonstrate crazy things. It turns out that it is enough to write only the name of the method, and GitHub Copilot will completely “invent” its body for you by name. So the new future of programming is just around the corner, and we had a serious discussion within our team that developers would have to retrain.

Tagir Valiev:

It is possible that GitHub Copilot will write for all programs. On the other hand, what we have tried ourselves is not yet as magical as those examples that are posted on Twitter. When you look at what’s going on in IDE development, there are a lot of incremental things that I like. Recently, it has become possible, for example, to write in Java “list.m” and you are immediately offered the option “.stream.map”.

I have carried out an experiment: I took the standard task of counting the most frequently occurring words in a text file and wrote it in Java from scratch. At the same time, I turned on logging, it is easy to make a keylogger from the IDE by turning on the macro recording mode. And I got indicators where I manually entered characters, and where the IDE prompted me. It turned out that the IDE wrote 2/3 of the code for me. It’s nice that you write only 30% of the code, and you get money for 100%. But it is worth noting that writing a new code is far from the biggest part of a programmer’s job. A programmer is often engaged in debugging, refactoring, researching bugs, writing and reading documentation, and some architectural things. And in the tasks listed above, although automation exists, it moves at different speeds. So there is still a lot of work to be done as a programmer. Thus, I look to the future with optimism, because the most boring part of the work will be automated, which we understand how to do with our heads, but we are too lazy to do it with our hands. The computer will gladly do the boring work for us, and the most interesting part of the task will be on the programmers for quite some time.

In many projects, there is great benefit from the ability to plan functionality. And in purely business projects, the speed of code creation directly affects productivity. “JetBrains” is a technology that speeds up programming at times, but it still needs to be “learned”. If you don’t use some smart features of auto-commission, but try to write code by hand, then you are still far from being a senior in terms of productivity. This “thing” needs to be mastered as a priority. As for replacing programmers with AI, this will not happen. I did scientific work on this topic. The idea of ​​​​replacing the developer with a machine has been floating around since 1980. But so far, we only see technologies that speed up writing or generating code.

Dmitry Buzdin: