Banks, digital certificates, government service sites still depend on the plugin of Java.
The idea of Java, "write once, run anywhere" is not always true.
Many services still have platform-specific requirements, they only run on Windows and pose a problem for users on other platforms.
What does Java's plugin offer in functional terms that modern browsers can not solve?
The main thing is that these plugins like Java provide almost unrestricted access to your computer. This is great "advantage" of having an application running Java in the browser. At least that was the motive in the past.
The browser is extremely limited when it comes to doing anything outside of it, outside drawing a page and making basic communication within certain limits with the server where it is talking in that context.
Of course it is common to have some limitations, these plugins still run on virtual machines but the limitation is much smaller than the "pure" browser.
In addition, the language and libraries available are usually a little more powerful, giving more tools for the programmer to work with. This has been more true in the past, but there is still more functionality in these plugins .
It is also possible to achieve better performance with Java or some plugin of the genre but the choice is usually not made because of this.
There is a tendency to no longer use this kind of feature because it even helps bring security issues to your users' machine. Also many people can not even understand the plugin installation and either give up or pay for a technician to do it.
If you consider that the sites that need it today have been replaced by native mobile apps, you should probably have native apps for the major desktop operating systems and eliminate this kind of need. This would give site only the basic functionality that web can provide by default. And an even more powerful and perhaps safer application can be used when you need something more powerful.
It will probably give you less trouble to have to install an application than the plugin .
One reason to still use Java is because in the past they used Java. So they do not want to do anything new. There was a reason to use Java but there is more.
Furthermore, many programmers choose to do it in Java because that's what they know or like. Even if you do not need it specifically, you do not need to "rotate anywhere," it is chosen. This, of course, can work for any language or platform.
Some people think that the philosophy of "compile once on every platform and run anywhere" found in C / C ++ and other languages is better and more portable. Of course there may be disadvantages too.
The Java plugin is nothing more than something that is used to be able to embed Java applets on web pages, similar to what is done with Flash. The purpose of it is to only make Java applications available in browsers and not give any kind of superpowers to browsers. It's true that browsers once did not have enough resources to do some things, so it was easier to use Java or Flash to do something that browsers were not capable of (ie having superpowers). But today's browsers have full power to replace all or almost all cases where Java or Flash would be justified.
The "write once, run anywhere" part is a half-truth. It is the original idea and still it is tried to maintain it, but some accidents in the route broke this. One of these early crashes was the Java virtual machine made by Microsoft around 1998 or 1999, where there were several Windows-specific classes invented by Microsoft within the java.awt package and that did not exist in other JVMs. This turned out to be a nice process from Sun against Microsoft and made Microsoft jump out of Java and invent C #.
Other crashes that surfaced were the stark differences between J2ME and J2SE, as many J2SE classes did not exist in J2ME, and vice versa, and J2ME had considerable restrictions, the "write once, place "was violated. With J2ME starvation dead and nothing official or useful coming from Sun / Oracle to take its place, Google went ahead and launched Android. But again, significant differences in the Android API for Java SE imply another break in the "write once, run anywhere" paradigm.
There are more things that lead to violation of the paradigm, many of them fault the programmer. One way to violate this paradigm is to rely on non-portable details of the operating system, such as explicitly using the path code as C:\Users\Abc in Windows or depending on whether x.txt and X.TXT are two separate files on Linux.
There are also cases where the paradigm is deliberately violated, where the applet simply refuses to load if it realizes that it is not running on the browser the developer wanted or the operating system the developer wanted.
