The following diagram taken from the report shows just how extensive this growth has been:
The growth in Java exploits is apparently largely due to exploit kit makers targeting out of date JREs. DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) are cited as one reason why memory attacks (e.g. buffer overflow) have become less common and possibly one reason why JRE attacks have proportionally taken up a larger slice of the pie but regardless of the reasoning it's clear that Java is a major path for vulnerabilities on windows operating systems.
This comes as no real surprise given the extensive security issues Java applets and web start had in 2013. While some of these vulnerabilities were already being exploited it was a matter of time before their use became more widespread.
The issue now is what how to mitigate the problem. Clearly the best option for users is to either disable applets and JWS within the browser (preferable to Java developers) or uninstall the system JRE entirely (less so). While some users may choose to take the path of disabling only applets and JWS many will also choose to try to live without Java.
Where an app requires a system JRE there is often no workaround to get it up and running without one. Similarly applets can provide the ability to customise the app to a particular web user account by passing in parameters, something which is not generally possible with a downloaded app.
Going Java-less may work for the most part but there are still popular apps that require a system JRE. This tug of war between users trying to stay safe and developers trying to get across that Java can be a safe and excellent technology will take time to play out. Ultimately though we believe that consumers trying to avoid Java will likely force developers to change their apps to work with a private JRE which doesn't come with the same integration with the browser and therefore avoids the same security pitfalls.
Certainly where there are apps that require an older JRE to run (for example some enterprise apps) the sensible choice for both parties would be to alter the app to run as a native app with a private (older) JRE rather than keep the old JRE installed a system JRE and try to ensure that the applets and Java Web Start remain switched off.