Apart from the political reasons(some contrast, archival copy, link to the video segment), the reason is that Java stdlib gets broken in a regular manner(as described in 2017 by the Chief Architect of the Oracle Java Paltform Group, Mark Rainhold) and if that change breaks some of the dependencies of the software that the freelancer creates, the workload of changing or replacing the dependencies becomes so huge that a single person is not able to fix it. Mega-corporations with their piles of money and swarms of developers can fix and/or replace the dependencies, but freelancers have to choose dependencies that WORK RELIABLY over a LONG PERIOD. Another difference between the megacorporations and freelancers tends to be that megacorporations tend to have fewer applications to fix, but freelancers have many clients with many small projects. The dependencies of a small freelancer project are usually not small projects at all.
It's OK to use the Java as an interface language, but the core technology of a freelancer has to be created in something that survives financial winters.
Thank You for reading this short post :-)
I think that it would be fair that if I criticize the Java core developers for their effort to keep the Java stdlib clean by replacing, deprecating, parts of the Java stdlib that they find less elegant, then I should also describe, what I find to be the solution that I like. My, very subjective, preference is that everything in the stdlib and the language is kept backwards compatible forever, all of stdlib components have to be live at prestdlib for at least 4 years WITHOUT ANY CHANGES before they move to the stdlib and language feature deprecation is based on a command line tool that offers warning messages, never has any false positives and never evaluates any artistic aspects of the code(layout, naming convention, organization of files and folders, etc.). As I already mentioned, my such preference is very subjective, a matter of taste, but I also add that part of my bias is that I deeply despise the attitude that software developers should not be trusted to do their job rigorously, the attitude that software developers should not be trusted with software development tools that require training and rigor to use without accidents. I'm not saying that I as a software developer should not have machines searching for my mistakes, but it must be my decision, what I consider to be a mistake, not so that the machine enforces some decision on me that I do not consider to be a mistake. Telling a proper, hard working, software developer that he/she does not know, what constitutes a mistake, is like telling surgeons that they should not use scalpels, because scalpels are too sharp for them and they might cut themselves and accidentally hurt patients along the process.
In the case of the proposed solution some components will live in the prestdlib for 10 years or even more before moving to the stdlib, but at least the application developers have certainty that if they base all of the code of their application on the stdlib, the application will run without requiring maintenance. If they want to avoid writing everything themselves, then they can use the new components from the prestdlib, with a trade-off that in stead of writing the components themselves they have to update their application whenever any of the used prestdlib components changes and whenever any of the used prestdlib components moves from prestdlib to the stdlib. Clients of the application developers can be offered a price based on the number of prestdlib components in the project: the more prestdlib components there are, the shorter the applications refactoring free life will be and the sooner the client has to pay another sum for the refactoring work. The number of prestdlib components could be listed with automated tools.
The workaround, where the application developers deliver their software in a virtual machine, has a fundamental drawback that newer components need to be backported to that virtual machine. The newer components have dependencies, which also might need to be backported. Some of the build tools of the backportable components might need to be backported. The amount of work that needs to be done to backport all necessary components can become too exhaustive to handle, but a virtual machine that includes all of the development tools is an excellent way to prolong the life of the application in a situation, where the deployment operating system and hardware of the application do not change, but the application needs to be upgraded to interface with newer components that run on a machine other than the one, where the application itself runs. For example, the application software of some "Internet-of-Things" appliance might need to be upgraded to be able to communicate with newer types of devices that did not exist at the time of the installation of the "Internet-of-Things" appliance.
To avoid singling out the Java core developers I mention that the C# core developers also seem to deliberately break backwards compatibility(archival copy).
Thank You for reading my text.
In theory a dirty hack to cope with the changing stdlib might be to use the official stdlib as a subset of the prestdlib and write a custom library that is used as the properly stable stdlib, but that's probably such a huge amount of work that one might already consider working on Free Pascal and Lazarus or some other Free Pascal projects, where there is no worries about whether the core technology is able to survive financial winters. The FreePascal, Lazarus, MSEide+MSEgui are already well maintained on multiple operating systems without depending on huge piles of corporate money, whilst the Java Virtual Machine is a beast to port to every major operating system and hardware combination. According to my 2018_06 knowledge, the most capable group of people outside of the American megacorporate world, who have the motivation, the pile of money and the skills to keep the Java Virtual Machine and the Java stdlib usable, are the Russian/St_Petersburg JetBrains team. A year 2016 quote from the JetBrains forum(archival copy, local copy unpacked):
Konstantin Bulenkov says: May 3, 2016 at 8:29 pm Thank you for sharing this, Martin. >are You going to maintain the Java Virtual Machine implementation to keep your IDE working? Yes, we already do. At the moment we have our own fork of OpenJDK project. We named it JetBrains Runtime and it includes several important features for us such as Subpixel antialiasing, fixes for better font rendering on Linux, fixes for HiDPI support including per-monitor HiDPI support, and others. Also, we’re trying to protect our users from regressions which happen in official JRE builds.
The main problem with the JetBrains Runtime is that no Russian company is able to say to the Kremlin/KGB/FSB that we will not place any back doors to our software. If even the American companies are not able to decline poisoning their products, then the chances of a Russian company declining to meet the demands of the Kremlin are even smaller(archival copy). I do not know, whether the Telegram.org case(archival copy) is an FSB operation to lure people to channel their private conversation through the Kremlin data collection system or whether it really is a genuine form of protest by the founders of the Telegram.org, but dividing the personal data flow between different adversarial eavesdropping parties might help the end users a little bit. Besides, if the U.S. companies disrespect the privacy of their clients with a probability of 1 and the U.S. intelligence services are known to leak(to the Kremlin) like hell, then some channel that leaks to the Kremlin with a probability of 0.9 is an improvement.
As a side comment I say that probably the next step at text processing might have something to do with an upgrade to regular expressions and the use of logic. As of 2018_06_15 I do not know, what it would look like to use the enhanced ideas in practical programming, but given the amount of text processing routines that software in 2018 tends to include, something that lessens the amount of manual work that software developers have to do might be very handy, even if it has a high learning curve. Regular expression writing tools, like the one in the KomodoIDE, are nice, but I think that they have hit their limit.
Thank You for reading this text.