We have a client side webstart application that is not yet ready for Java 9, it's rather unclear what will happen on 21.9.2017 with the auto-update option in the jRE.
If you have the latest Java 8 version with the auto-update enabled. Will version 9 be pushed to the client? Is disabling the auto-update function the only option to prevent this or will the auto-update only look for new versions of java 8?
Will version 9 be pushed to the client?
No.
New Java versions take some time to percolate to unsuspecting users:
Even after the GA release of Java 9 will Java 8 remain the default download option at Java SE Downloads for about six months. (Turns out that was wrong.)
Java 8 will receive further public updates until at least September 2018.
Only when that time window draws to a close and Oracle published its official "end of public updates notice" will hesitant users have to consider switching to Java 9.
A few months before the end of public support will the auto-updater propose an update to Java 9, but it will require user permission. (At least that's how it worked between Java 7 and 8).
Disabling auto update is not required, and is actually counter productive.
Keep in mind that people have legitimate reasons to continue using JREs or JDKs for Java 8 (probably several years into the future).
It is very much the same as with previous major releases of Java: ideally you plan about moving forward at some time - but there is absolutely no side forcing you when to make that move.
We started using Java 8 for production like 12 months ago - and we still have products out in the field that run on Java 6.
In that sense:
you educate yourself about the changes that Java9 is offering
you mainly identify a "path forward" for your deliveries around the new module system
you start experimenting with Java9 at some point ...
and then, when you decide "we are ready" - then you move forward.
I believe no,
as JAVA 9 has SO BIG change caused by its jigsaw(the change is so huge and make java 9 delay again and again ), such big chance has potential to break your current java application.
BTW: java 9 will finally release in this month.
Related
My display starts to flicker heavily after / while using eclipse. First i thought this is the common "surface problem", but everything is fine if i don't use eclipse (tested for 3 days.) Just after opening eclipse and using it for 5 mins, the whole screen starts to flicker, making it unable to work with. It flickers in every programm and also on the task manager, even after closing eclipse. It stops if i put the monitor on standby for a couple minutes, then comes back randomly.
Things i work with:
Surface Pro 4,
Windows 10 (current version),
Eclipse Version: 2020-03 (4.15.0)
Things i tried:
Using windows compatibility tool,
checking my current drivers (no update found)
Note: I just started programming and digging into IT stuff. So im far from an experienced user and haven't tried any stuff i cant unterstand (yet).
Please help me out, thanks a lot in advance.
I really like NetBeans as an IDE for my Java projects. However, since switching versions from 8.2 to 11.1, it takes too long to open. What can i do?, perhaps change some startup options, to avoid doing lots of things that I don't use anyway? One thing I noticed is that it stays on "loading program modules" for a while.
I've gone through the plugins and have disabled all the ones I don't use, and I close all projects I am not working on. There might be 4 or 5 plugins active. I'm using Java 9. My programs rarely contain more than 2 or 3 classes and don't contain much code. I'm running an Intel(R) Core(TM) i3-5020U CPU # 2.20 GHz 2.19 GHz and 6.00 MB RAM.
Another thing that drives me nuts is that, while I like the auto complete feature, which I can access by hitting CTRL + space, sometimes it gives me options that I don't want, but when I keep typing to put in what I want it still automatically inserts their choice, which usually has nothing to do with what I'm doing. So then I have to waste time removing what they inserted.
Any ideas?
I experienced a similar problem under Windows 10 (64-bit).
messages.log was full of messages like this one:
WARNING [org.netbeans.JarClassLoader]: Opening C:\Program
Files\NetBeans-11.1\netbeans\platform\core\name_of_java_archive.jar took
XXX ms
Adding the NetBeans executable to my antivirus' exclusion list solved the problem.
How can i restore a previous leak period?
Example, we have our server set-up to calculate the leak period based on version number. Unfortunately someone bumped the version number of the project prematurely. We restored the version number and the change is reflected in the project history, but the leak period metrics were not restored. Currently the newer,erroneous version number is being used to label the leak period.
Side question: How does sonarqube detect a "newer" version number? Does it just look at the changed string or does it have to be higher?
Using microsoft windows as an example: If the project version change from 3,3.11, NT, 98, 98 r2, ME, xp, 7, 8, 8.1, 10 how will sonarqube calculate leak periods?
I was able to solve this by going to the project history and deleting the snapshot that caused the version number to change. It seems to revert to previous leak period next time the project is scanned.
I'm not sure there is any other bad side effect to this yet, but at least the reports are more correct than before.
On a windows 2012 RT (x64) TEST server we are running a Tomcat 8 installation and the CPU usage is disconcerting in its regularity of hitting peak usage.
The behavior is happening after an installation of our application but before anyone is accessing it. I have accessed a few pages and tested some features but nothing that could create this behavior that I know of.
There are 2 virtual processors on the server and every ~20 seconds, the CPU usage will spike (on the one processor that is running Tomcat) to 100% for 10 seconds (give or take). See below:
The regularity of the pattern indicates to me that something is incorrect in either the installation or the settings of Tomcat 8.
I have installed the YourKit Java Profiler (by SO recommendation) which I was hoping could shed some light on what is causing these spikes, but haven't been able to see the reason the threads are starting -- at least in part to my newness to YourKit. I did attach it to the Tomcat launch file and it seems to be tracking the behavior.
The catalina logs are silent during the spiking occurrences (as are my application logs) but when I stopped Tomcat there were some messages about ThreadLocals getting started but could not be removed and then: "...Threads are going to be renewed over time to try and avoid a probable memory leak."
I left the server running over the weekend and the pattern has continued until today so I don't think my symptoms are going away. Whatever is starting up has now consumed all available RAM on the system just from starting up these threads (and/or YourKit) every 20 seconds.
What is a possible approach to isolate this aberrant Tomcat activity and hopefully stop or rectify it?
There are many graphs and tabs in YourKit so I hesitate to list everything that might be helpful. Thanks for helping me narrow down the problem with what YourKit (or other tools) could offer me.
Info from catalina log regarding start-up:
Apache Tomcat/8.0.23
Architecture: amd64
Java Home: C:\Program Files\Java\jre1.8.0_65
CATALINA_BASE: C:\Program Files\Apache Software Foundation\Tomcat 8.0
2015-12-08 Update
At Gergely's request, the application is a local installation of DSpace. It's a Java application with a Postgres SQL database backend. We are customizing an opensource version of it from here: http://www.dspace.org/introducing. I'm not exactly sure what else can be helpful and I think the stack trace is more revealing as to what is (and isn't) running -- see below.
By turning on Stack Telemetry in YourKit, "CPU Estimation" was made available by dragging the cursor across a period of profiler history. To me, it looks like all the CPU is doing is spinning idly. Are the Java files pictured below Tomcat routines? They don't strike me as DSpace related (although I'm not an expert) nor does it look like any work is being done while the CPU is peaking.
Of note: the stack trace is identical during the quiet periods -- the only difference being CPU Time (ms) is in the hundreds rather than thousands of milliseconds. For a more direct comparison than what is below, the hump represents ~8,000 ms in Thread.run() and the quiet periods consume ~125 ms of cpu time (although covering approximately the same amount of time).
Lastly, when pages of the application are being requested, a subsequent branch of code appears in the Call Tree. If it happened during the time of a spike it may only take 400 ms of CPU time to load a whole page. The code branch that appears is ApplicationFilterChain.java as a whole separate branch alongside PooledExecutor$Worker.run() -- both underneath java.lang.Thread.run() in the hierarchy.
When trying to interpret the stack trace: Is EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run() responsible?
Processor spikes with no known, associated activity
2015-12-08 Update #2
YourKit comes pre-configured to hide certain java class name patterns which obscured drilling down on java.lang.Thread. Clearing the filters enabled the following screenshots showing that the vast majority of processing time during a spike event is through calling the following 3 methods:
java.io.WinNTFileSystem.canonicalize0
java.io.WinNTFileSystem.getBooleanAttributes (inFile.exists())
StardardRoot.java
My apologies for not yet knowing enough about Tomcat or DSpace to know who is launching these tasks. (In case it matters the line directly above the first line is java.lang.Thread.run() and then <All threads>)
Thank you to those who has viewed and responded to this inquiry. As various individuals have surmised, the problem was related to our settings and use of Tomcat -- not a problem with Tomcat itself (most likely).
This is an attempt to answer the question without perfect knowledge at installing the DSpace application and Tomcat but I think I know enough to be dangerous and potentially helpful to follow-up users.
When installing the application DSpace there are some installation properties in Tomcat's configuration directories that determine whether or not to allow for changes in coding files to be reflected immediately without a Tomcat restart. These settings for us were previously in the directory [tomcat]/conf/Catalina/localhost/ and each of the three files contained a small, insignificant XML file like (e.g. oai.xml):
<?xml version='1.0'?>
<Context docBase="E:/dspace/webapps/oai"
reloadable="false"
cachingAllowed="true"/>
You can find documentation on these properties at the following link:
https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace
Within that documentation is a recommendation about the reloadable and cachingAllowed properties. Search for "Tomcat Context Settings in Production". Here is an excerpt (emphasis mine):
These settings are extremely useful to have when you are first getting started with DSpace, as they let you tweak the DSpace XMLUI (XSLTs or CSS) or JSPUI (JSPs) and see your changes get automatically reloaded by Tomcat (without having to restart Tomcat). However, it is worth noting that the Apache Tomcat documentation recommends Production sites leave the default values in place (reloadable="false" cachingAllowed="true"), as allowing Tomcat to automatically reload all changes may result in "significant runtime overhead".
It is entirely up to you whether to keep these Tomcat settings in place. We just recommend beginning with them, so that you can more easily customize your site without having to require a Tomcat restart. Smaller DSpace sites may not notice any performance issues with keeping these settings in place in Production. Larger DSpace sites may wish to ensure that Tomcat performance is more streamlined.
When I switched these boolean flags to reloadable="false" and cachingAllowed="true" the spiked CPU experience stopped immediately. I don't know if the warning about "Larger sites" applies to us or whether "streamlined performance" could refer to the negative activity I observed.
I presume there may be other problems with our installation that allowed this particular manifestation; one ominous clue is that our production server seems to be operating with these flags in the reloadable="true" configuration. Java, Tomcat, Windows, AND DSpace are ALL getting new versions at the same time so it is fairly difficult to pinpoint why similar Tomcat <context> settings produce such different results.
I am at least content for now to have new behavior and that the system has calmed down. I'll post more if I learn more but will be focusing next on other quandaries.
Update
FWIW, the attributes are settings that directly control Tomcat and they have changed between versions. E.g., cachingAllowed was removed in version 8 which means it can be removed from the Context elements. Compare:
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Attributes
https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Attributes
And for good measure, here is the help text for reloadable in the Tomcat 8 documentation:
Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. That's why the default setting for this attribute is false. You can use the Manager web application, however, to trigger reloads of deployed applications on demand.
So it would seem that the ultimate answer is that Tomcat 8 on Windows 2012-R2 with the flag reloadable='true' polls for changes to WEB-INF/lib and WEB-INF/classes. The volume of the folders and files to peruse may very well be the cause of these intense, spiked CPU events. For now I will be relying on reloadable='false' which definitely removes the symptom for us.
Not an explicit answer, but way too long for a comment
After reviewing the update on this question and reading a bit I suspect that this recurring issues is caused by a CuratorTask. Reasons being:
The stacktrace you acquired clearly shows that a WorkerThread managed by the DSpace library (so Tomcat is not to be blamed) is using the processor at those times.
After reading a bit about DSpace itself, it looks like that it has a feature that allows users to define curator tasks that should be periodically executed.
On top of this there is at least one task that is - according to the documentation - It is activated by default, so theoretically there can be any number of tasks activated by default.
Moreover this conversation reveals at least 1 curation task that is actived every 10 seconds.
All these together point to the same direction. I would suggest using the UI of DSpace (probably in Admin mode) to look around and find the active curation tasks and verify if their scheduling corresponds to what you have observed.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
UPD. 0xC0000005 is STATUS_ACCESS_VIOLATION, defined in winnt.h. Meaning the app has tried to access a memory it doesn't have access to. Most of the time it's dereferencing a null pointer.
In short. After patch 19 has been installed I can't run any form: compiled with patch 18 or 19, by myself or others. Immediately after starting I get Windows error:
--------------------------------
ifrun60.exe ....
--------------------------------
The application failed to initialize properly (0xC0000005). .....
--------------------------------
Details
In Windows Event Viewer: error id = "26", Source = "Application Popup", User = "n/a"
I'm able to run forms from within Builder (i.e. "Program" --> "Run")
Everything was good with Developer 6i patch 18.
Another one programmer on our team has the same problem (others have not tried yet)
Windows XP SP3 (32-bit).
What I've tried
Add ifrun60.exe (and other exe from BIN folder) to Data execution prevention (DEP) exceptions
Uninstall every possible component via Oracle Installer, erase ORACLE_HOME from HDD and re-install, then
Incrementally apply all patches I have (5, 13, 15, 18, 19)
Start form in Windows compatibility modes
Why do I need this
The main reason is that this patch fixes some weird behaviour that presents only on my machine (in team of 7) - I'm getting error while trying to assign global variable. It always disappears after re-compilation on any other machine and sometimes (what the... ?!) after my own recompilation later
And the second reason is, well, just curiosity because I've almost broken my brain trying to make this work
Progress
2010.02.11 - I've just found out (thanks to ProcMon), that the last action before crush is loading ifrcm60.dll (with SUCCESS result code).
I've tried to replace this DLL with version from patch 18 and then ifrun60.exe complains about wrong DLL
2010.02.16 - Dr Watson doesn't generate any info
2010.03.02 - Support (including extended) for Designer 6i came to end on 31 dec 2008, so I can't rise support request.
Also the only mention of this problem I was able to find is the dead thread (2 y.o.) on Oracle forums
It seems to me, that the only way to solve this will be to defenestrate my PC... any other suggestions ? :)
Solution
OK, I give up. Just reinstall Windows (love this solution in any situation :) (I've done Win7 32 bit)
If you are installing patches then presumably you have an Oracle Support account. If so, I urge you to raise an SR with them. Or - as I'm not sure that Forms 6i is still supported - search the Metalink Knowledge Base for solutions.
Because this is going to be something really obscure in your set-up. There is a thread in the Tech Guy forum which covers the sort of techniques you need to deploy in diagnosing this. Find out more.
I had the same problem and solved it applying patch 6857221 for Forms 6i. You can download it here: https://support.oracle.com/epmos/faces/PatchSearchResults?_afrLoop=384799287815717&_afrWindowMode=0&_adf.ctrl-state=5a8q1h6fh_4 (you will need an Oracle support account)