Java DevTools: Fashionable does not mean good
Today with us, Anton Arkhipov aka antonarhipov is the developer and product manager of JRebel at ZeroTurnaround, and we are talking about the right development tools and their misuse. Anton has been professionally developing Java for over ten years. Main interests are related to programming languages ​​and software development tools. Loves vim and IntelliJ IDEA. He often speaks at international conferences - behind his back speaking at such conferences as JAX, JavaOne, Joker, JPoint, GeeCON, Jfokus, JavaZone, EclipseCon.
- Anton, what are you doing in the field of Java-development?
- For the last six years I have been working for ZeroTurnaround, and on duty I have been doing what I like most - developing tools for Java developers. Our well-known product is JRebel for Java developers, and our second major product is XRebel, also for Java developers, but more for those involved in web development. I was engaged in the first three years of JRebel, and for the last three years I have been involved in the creation of XRebel.
')
“The popularity of IDEA is growing, and I was surprised to find that, according to a survey conducted on your company's website, it overtook Eclipse this year.
Positions of various IDEs among those surveyed on the site zeroturnaround.com
- We have to admit: any questionnaire is lying. These are statistics, and as you know, “there is a lie, there is a big lie and there are statistics”. IDEA is the most popular IDE among those who answered this questionnaire, but this does not mean that it is the most popular among all Java developers. If we look at the statistics among the users of JRebel, then Eclipse will still be the leading IDE, with a fairly strong margin - the share of Eclipse is more than 60%.
In fact, what’s interesting is not what share of IDEA users is now, but how this share has changed. We are conducting these surveys not for the first time, and all the time the popularity indicators are growing for IDEA and falling for Eclipse. And for NetBeans, they are always very marginal. Not that 10% could be considered marginal, but still they are quite low, with which, of course, the NetBeans team strongly disagrees. They believe that such things can never be studied through questionnaires. But everyone is interested in it all the same, and all this will always be done.
We see a trend that IDEA is growing. And it seems to me that this is due to the fact that IntelliJ IDEA and the JetBrains company decided to change the strategy for the release of new versions. More often there are updates, more often there are bug fixes, you can always see “early releases”.
And when a product is actively developing, it attracts developers. We are like children, we love everything new. And the more powerful the tool, the more we want it. Despite the fact that, for example, 95% of the power of this tool may not even be needed.
It seems to me that one of the big advantages of IDEA is that it is developed by one company, with a single view on how it should look, how the product should look. I do not see this in Eclipse. There is not a single "party line", let's say. And so some pieces are coherent, and some are perfect, as if “ad hoc” in the system. I’m not saying that there is no such thing in IDEA - there is trouble in IDEA too, but it is corrected when the community begins to resent: “Guys, how is it that you have a commercial IDE”. And there they quickly try to smooth out these rough edges. In Eclipse, unfortunately, I did not observe this.
Eclipse is still a community-project, even though there are great forces behind it. He follows his rather conservative new release strategy. In addition, several years ago there were quite big problems with releases, as far as I know, there were problems with performance and stability. But it happens in many products. And IDEA had a period when the releases were not very good, and NetBeans too.
The only big contributor to Eclipse, who cares for the “single line”, is, I think, Red Hat with its distribution JBoss Developer Studio. They try to build a distribution kit that you have installed and that works. And they are such a “motor” for Eclipse to improve it. A lot of the latest improvements in Eclipse are associated with Red Hat.
- Essentially, do you think the IDEA programmer works more productively than in Eclipse? Here you will report on IDEA. Surely you both worked in IDE.
- Yes, I worked the last twelve years, since 2004, in IDEA. I used Eclipse and contributed to it from 2006 to 2008, and somehow I used it a little bit from time to time. But on duty, we make plugins for IDE. Our product is embedded as a plugin, and I was just engaged in the development of plug-ins. Therefore, I have been actively using all IDEs for the last few years. I even watched how many different versions of Eclipse I had - about ten pieces.
- But for the most part you worked in IDEA? Then it is clear that for you work in it is more productive, you are used to it.
- Yes, first, of course, this is a matter of habit. But besides this, I believe that for every task you need to have your own tool, which you know well and with which you can take and do whatever you want. For some things in Java development, it would be more convenient for me to use NetBeans — I would take NetBeans for this task. For some task it would be more efficient for me to use Eclipse - I would take Eclipse.
For me in IDE, the most productive part is the navigation and shortcut system. Very often, people are looking for some kind of logic in the shortcut system. There is no logic, never. For example, I was asked the question: “What kind of logic is there in such a shortcut in IDEA?” It’s wrong to ask so, because if you look at where some shortcuts are, you can see some oddities everywhere. Why is Ctrl + H a search in Eclipse? Where is the logic here? Unclear.
- Shortcuts, like chords - are remembered by muscle memory.
- Yes, here we must remember the spinal cord, muscle memory and so on. And the main thing is that you can do what you want to do now, and as much as possible out-of-the-box, without setting up, customizing the system.
Here, as a choice between Mac or Gentoo Linux: either we customize everything for ourselves, or we take and go right away, sit in the Ferrari and scrub a hundred kilometers per hour.
If a person can provide this with some instrument, then he is a good fellow. And here it does not matter, IDEA or Eclipse. I found this for myself in IDEA. Someone might find this in Eclipse for themselves.
- The eternal reason for the "holy wars" of programmers is the choice of a version control system. I want to share my story. Once upon a time, our company made a bet on SVN, and now we have many employees (most of them are not Java programmers or not programmers at all) trained to work effectively with SVN, many tricks and features. And recently we have seen that Git has smashed everyone in popularity. And often there are “advanced young professionals ” who come and say: “What is it that you are still on Subversion? You are outdated! You are not in trend! How so? "
The popularity of version control systems
- In our company for historical reasons, we do not use Git in many projects. There are teams that wanted to switch to Git - they switched. But we have the main number of projects and the most basic projects are contained in an even less popular environment than SVN - this is Mercurial.
Would we have any advantages from switching to Git or not?
At one time, we invited trainers from GitHub to give us Git training so that we could decide if we should switch to Git or not. And after this daytime intensive we then sat down, thought and understood that considering the way we work, we wouldn’t feel better from switching to Git. And to get the benefits of Git, we would need to change our job.
If your way of working (doing brunches, these are all things) fits under your version control system and it supports it, then that's good. If we take a tool that allows a bunch of cool things to do, and use it anyway as SVN, then there’s little use for that.
Regarding the popularity of Git, this is the moment where it works, it seems to me: developers love something very powerful. Even if all this power is not needed, we want it to be at hand - this cleaver. Even a machine gun, not a cleaver. SVN is a cleaver, we commit there, and everything suits us. Then we took the Git-machine gun and started back there, just like in SVN, commit. And then the question arises: why all these things?
- Yes, if you can't play well, why do you need a good musical instrument?
- Well yes. I, frankly, have never seen a meaning for myself to devote time to Git very much. But today, of course, if someone asks me what tools a developer should know, then first of all I will call Git anyway.
- Is the success of Git due to the popularity of the GitHub service?
- Yes, of course, GitHub - it is the most popular, because it seems to me that Git is also popular. And secondly, envy works here. "I want the same as my neighbor, because he has a powerful one." And the popularity of Git is also due to this.
- Many Git apologists are pushing for decentralization. I answer them that our SVN is replicated to three servers, we have enough decentralization.
- Well, this is a different decentralization! It's just that if you have a decentralized team, if you have different projects all the time, different interrupted development and so on, the branch is just the power of Git. If we are talking about brunches in SVN, this is still a rudiment.
- But it starts to work, only when a very large team and a very large project. And when it is within a small company, fairly centralized, then Git does not provide the advantage?
“Then not, of course.” If a small team, and if we also try not to make many brunches, or, for example, we develop everything in one main branch with so-called feature flags, then the advantages of Git are lost. Especially if a small team.
- It is somewhat threatening now, if you look at the graphics, for Maven it looks like the rise in popularity of Gradle. Gradle, in my opinion, everywhere, many are talking about him. Should the Maven user think about switching to Gradle?
The popularity of assembly automation
- On this topic we gave a wonderful report at the last JPoint conference this year, with Baruch jbaruch Sadogursky and Yevgeny Borisov. There we had an epic battle - Maven, Gradle and SBT. Well SBT is there by the way, but mostly Maven and Gradle. And there, at the end of the report, Baruch summarized very well that for a huge number of projects and scenarios Maven would be enough for the eyes. And Maven, thanks to his “inflexibility” of the so-called - you can’t just take it, stick your hands in and fix the build logic - that's what it takes. It is conservative, stable, people know how to “cook” it. Accordingly, it will be kept at 70%. And he holds, and it seems to me that this does not change much. This is the questionnaire, maybe, the numbers play somehow.
- Gradle grows and eats away from Maven his share.
- Well yes. But the main enterprise projects will still be sitting on Maven. In the direction of Gradle, probably, old projects that are written on Ant will look, if they continue to be developed in that logic.
- In the logic of an imperative, rather than a declarative approach to assembly?
- Yes Yes. For this, Gradle is quite a good option. But Gradle has its own problem: it is very easy to write pasta there. Many of these "macaroni" are explained by the fact that the assembly language, Groovy, is not static, typed.
If the “Enterprise Mode, On!” Key ever appears in the Gradle, which will disable any scripts inside the build file, I think this will be its first step into the enterprise world. In principle, many people think so. And Baruch thinks so, and I agree with him.
It seems to me that Maven is still solid, this is a de facto standard. Everyone should know him.
Gradle is for those who really have assembly requirements that go beyond. Gradle, it seems to me, is not just a tool for assembly, it is a little more, it is a tool for automation, to do something more than just an assembly. He took all the good things from Maven, Groovy added, and we now have such a powerful tool. Again, his popularity is due to the fact that he is powerful. We are again returning to the argument that developers really want power, not even always when it is needed. And I am sure that many are taking Gradle now for some new projects where it does not give any plus in comparison with Maven.
I think this is some kind of inertia to which we are used. We are accustomed to improving all the time.
- But we, developers, always need to improve anyway, we have such a profession.
“Maybe we should just stop and improve on what we already have and what we already know, and not to miss new frameworks, tools, and so on.” We have good tools that we could master as much as possible, and knock out the maximum efficiency from them, from what we have. And we, not having reached, without squeezing at least 90% of these tools, are already rushing to a new tool, just because someone said that it is more in a trend, more brilliant and more interesting.
- Well, the last question, what will you do at the Joker 2016 conference?
- I have two reports at the conference - one about Java bytecode , and the second about efficient use of IDEA .
If you are wondering what will be about tools at Joker 2016 , here are some useful links to already approved reports:
- Anton, what are you doing in the field of Java-development?- For the last six years I have been working for ZeroTurnaround, and on duty I have been doing what I like most - developing tools for Java developers. Our well-known product is JRebel for Java developers, and our second major product is XRebel, also for Java developers, but more for those involved in web development. I was engaged in the first three years of JRebel, and for the last three years I have been involved in the creation of XRebel.
')
About development environments
“The popularity of IDEA is growing, and I was surprised to find that, according to a survey conducted on your company's website, it overtook Eclipse this year.
Positions of various IDEs among those surveyed on the site zeroturnaround.com
- We have to admit: any questionnaire is lying. These are statistics, and as you know, “there is a lie, there is a big lie and there are statistics”. IDEA is the most popular IDE among those who answered this questionnaire, but this does not mean that it is the most popular among all Java developers. If we look at the statistics among the users of JRebel, then Eclipse will still be the leading IDE, with a fairly strong margin - the share of Eclipse is more than 60%.
In fact, what’s interesting is not what share of IDEA users is now, but how this share has changed. We are conducting these surveys not for the first time, and all the time the popularity indicators are growing for IDEA and falling for Eclipse. And for NetBeans, they are always very marginal. Not that 10% could be considered marginal, but still they are quite low, with which, of course, the NetBeans team strongly disagrees. They believe that such things can never be studied through questionnaires. But everyone is interested in it all the same, and all this will always be done.
We see a trend that IDEA is growing. And it seems to me that this is due to the fact that IntelliJ IDEA and the JetBrains company decided to change the strategy for the release of new versions. More often there are updates, more often there are bug fixes, you can always see “early releases”.
And when a product is actively developing, it attracts developers. We are like children, we love everything new. And the more powerful the tool, the more we want it. Despite the fact that, for example, 95% of the power of this tool may not even be needed.
It seems to me that one of the big advantages of IDEA is that it is developed by one company, with a single view on how it should look, how the product should look. I do not see this in Eclipse. There is not a single "party line", let's say. And so some pieces are coherent, and some are perfect, as if “ad hoc” in the system. I’m not saying that there is no such thing in IDEA - there is trouble in IDEA too, but it is corrected when the community begins to resent: “Guys, how is it that you have a commercial IDE”. And there they quickly try to smooth out these rough edges. In Eclipse, unfortunately, I did not observe this.
Eclipse is still a community-project, even though there are great forces behind it. He follows his rather conservative new release strategy. In addition, several years ago there were quite big problems with releases, as far as I know, there were problems with performance and stability. But it happens in many products. And IDEA had a period when the releases were not very good, and NetBeans too.
The only big contributor to Eclipse, who cares for the “single line”, is, I think, Red Hat with its distribution JBoss Developer Studio. They try to build a distribution kit that you have installed and that works. And they are such a “motor” for Eclipse to improve it. A lot of the latest improvements in Eclipse are associated with Red Hat.
- Essentially, do you think the IDEA programmer works more productively than in Eclipse? Here you will report on IDEA. Surely you both worked in IDE.
- Yes, I worked the last twelve years, since 2004, in IDEA. I used Eclipse and contributed to it from 2006 to 2008, and somehow I used it a little bit from time to time. But on duty, we make plugins for IDE. Our product is embedded as a plugin, and I was just engaged in the development of plug-ins. Therefore, I have been actively using all IDEs for the last few years. I even watched how many different versions of Eclipse I had - about ten pieces.
- But for the most part you worked in IDEA? Then it is clear that for you work in it is more productive, you are used to it.
- Yes, first, of course, this is a matter of habit. But besides this, I believe that for every task you need to have your own tool, which you know well and with which you can take and do whatever you want. For some things in Java development, it would be more convenient for me to use NetBeans — I would take NetBeans for this task. For some task it would be more efficient for me to use Eclipse - I would take Eclipse.
For me in IDE, the most productive part is the navigation and shortcut system. Very often, people are looking for some kind of logic in the shortcut system. There is no logic, never. For example, I was asked the question: “What kind of logic is there in such a shortcut in IDEA?” It’s wrong to ask so, because if you look at where some shortcuts are, you can see some oddities everywhere. Why is Ctrl + H a search in Eclipse? Where is the logic here? Unclear.
- Shortcuts, like chords - are remembered by muscle memory.
- Yes, here we must remember the spinal cord, muscle memory and so on. And the main thing is that you can do what you want to do now, and as much as possible out-of-the-box, without setting up, customizing the system.
Here, as a choice between Mac or Gentoo Linux: either we customize everything for ourselves, or we take and go right away, sit in the Ferrari and scrub a hundred kilometers per hour.
If a person can provide this with some instrument, then he is a good fellow. And here it does not matter, IDEA or Eclipse. I found this for myself in IDEA. Someone might find this in Eclipse for themselves.
About version control systems
- The eternal reason for the "holy wars" of programmers is the choice of a version control system. I want to share my story. Once upon a time, our company made a bet on SVN, and now we have many employees (most of them are not Java programmers or not programmers at all) trained to work effectively with SVN, many tricks and features. And recently we have seen that Git has smashed everyone in popularity. And often there are “advanced young professionals ” who come and say: “What is it that you are still on Subversion? You are outdated! You are not in trend! How so? "
The popularity of version control systems
- In our company for historical reasons, we do not use Git in many projects. There are teams that wanted to switch to Git - they switched. But we have the main number of projects and the most basic projects are contained in an even less popular environment than SVN - this is Mercurial.
Would we have any advantages from switching to Git or not?
At one time, we invited trainers from GitHub to give us Git training so that we could decide if we should switch to Git or not. And after this daytime intensive we then sat down, thought and understood that considering the way we work, we wouldn’t feel better from switching to Git. And to get the benefits of Git, we would need to change our job.
If your way of working (doing brunches, these are all things) fits under your version control system and it supports it, then that's good. If we take a tool that allows a bunch of cool things to do, and use it anyway as SVN, then there’s little use for that.
Regarding the popularity of Git, this is the moment where it works, it seems to me: developers love something very powerful. Even if all this power is not needed, we want it to be at hand - this cleaver. Even a machine gun, not a cleaver. SVN is a cleaver, we commit there, and everything suits us. Then we took the Git-machine gun and started back there, just like in SVN, commit. And then the question arises: why all these things?
- Yes, if you can't play well, why do you need a good musical instrument?
- Well yes. I, frankly, have never seen a meaning for myself to devote time to Git very much. But today, of course, if someone asks me what tools a developer should know, then first of all I will call Git anyway.
- Is the success of Git due to the popularity of the GitHub service?
- Yes, of course, GitHub - it is the most popular, because it seems to me that Git is also popular. And secondly, envy works here. "I want the same as my neighbor, because he has a powerful one." And the popularity of Git is also due to this.
- Many Git apologists are pushing for decentralization. I answer them that our SVN is replicated to three servers, we have enough decentralization.
- Well, this is a different decentralization! It's just that if you have a decentralized team, if you have different projects all the time, different interrupted development and so on, the branch is just the power of Git. If we are talking about brunches in SVN, this is still a rudiment.
- But it starts to work, only when a very large team and a very large project. And when it is within a small company, fairly centralized, then Git does not provide the advantage?
“Then not, of course.” If a small team, and if we also try not to make many brunches, or, for example, we develop everything in one main branch with so-called feature flags, then the advantages of Git are lost. Especially if a small team.
About assembly automation
- It is somewhat threatening now, if you look at the graphics, for Maven it looks like the rise in popularity of Gradle. Gradle, in my opinion, everywhere, many are talking about him. Should the Maven user think about switching to Gradle?
The popularity of assembly automation
- On this topic we gave a wonderful report at the last JPoint conference this year, with Baruch jbaruch Sadogursky and Yevgeny Borisov. There we had an epic battle - Maven, Gradle and SBT. Well SBT is there by the way, but mostly Maven and Gradle. And there, at the end of the report, Baruch summarized very well that for a huge number of projects and scenarios Maven would be enough for the eyes. And Maven, thanks to his “inflexibility” of the so-called - you can’t just take it, stick your hands in and fix the build logic - that's what it takes. It is conservative, stable, people know how to “cook” it. Accordingly, it will be kept at 70%. And he holds, and it seems to me that this does not change much. This is the questionnaire, maybe, the numbers play somehow.
- Gradle grows and eats away from Maven his share.
- Well yes. But the main enterprise projects will still be sitting on Maven. In the direction of Gradle, probably, old projects that are written on Ant will look, if they continue to be developed in that logic.
- In the logic of an imperative, rather than a declarative approach to assembly?
- Yes Yes. For this, Gradle is quite a good option. But Gradle has its own problem: it is very easy to write pasta there. Many of these "macaroni" are explained by the fact that the assembly language, Groovy, is not static, typed.
If the “Enterprise Mode, On!” Key ever appears in the Gradle, which will disable any scripts inside the build file, I think this will be its first step into the enterprise world. In principle, many people think so. And Baruch thinks so, and I agree with him.
It seems to me that Maven is still solid, this is a de facto standard. Everyone should know him.
Gradle is for those who really have assembly requirements that go beyond. Gradle, it seems to me, is not just a tool for assembly, it is a little more, it is a tool for automation, to do something more than just an assembly. He took all the good things from Maven, Groovy added, and we now have such a powerful tool. Again, his popularity is due to the fact that he is powerful. We are again returning to the argument that developers really want power, not even always when it is needed. And I am sure that many are taking Gradle now for some new projects where it does not give any plus in comparison with Maven.
I think this is some kind of inertia to which we are used. We are accustomed to improving all the time.
- But we, developers, always need to improve anyway, we have such a profession.
“Maybe we should just stop and improve on what we already have and what we already know, and not to miss new frameworks, tools, and so on.” We have good tools that we could master as much as possible, and knock out the maximum efficiency from them, from what we have. And we, not having reached, without squeezing at least 90% of these tools, are already rushing to a new tool, just because someone said that it is more in a trend, more brilliant and more interesting.
- Well, the last question, what will you do at the Joker 2016 conference?
- I have two reports at the conference - one about Java bytecode , and the second about efficient use of IDEA .
If you are wondering what will be about tools at Joker 2016 , here are some useful links to already approved reports:
- Kirill Tolkachev "Release Management with Gradle"
- Martin Toshev "Spring RabbitMQ"
- Vladimir Tsukur "Path from CRUD to Hypermedia API with Spring"
- Alexey Zinoviev “What is the Spark coming?”
- Vladimir Krasilshchik “Vert.x: Beauty and the Beast”
Source: https://habr.com/ru/post/307606/
All Articles