I recently started java programming. I was told BlueJ is one of the best IDE's out there to start with. It worked for about a week. But then there was this one specific program, very simple program, just divided a few numbers to get an idea about associativity. It showed me an error that division by 0 is not possible. Right after that, each program i did produced no output what so ever. As in the output terminal will remain blank, completely. At the same time, my whole OS starts to slow down, even down to the file explorer. I have no idea whats causing this, since i have not changed the settings nor tampered with it.
Also i thought maybe it could be because of the complexity of the program, like a loop or something. Hence, i tried a simple hello world program, just to display a text, that's all. Even a simple program like that didn't produce an output.
What could be causing this problem ?
Operating system : Windows 10 Pro (64 bit)
RAM : 8 GB DDR3
Bluej : Version 4.1.0
I would uninstall and reinstall BlueJ, as well as doing the same with Java. This is probably the best method to resolve.
Related
I have a simple Java applet that I'm running from an HTML page on my computer (i.e. file:///C....). It works fine even when I start it in debug mode, which I do with "suspend=y". When I attach the debugger it works great if breakpoints are disabled. It also works fine if I stop at breakpoints and quickly go on to the next one, if any. The problem arrises only when I linger on a breakpoint about 7 to 9 seconds. If I do that the application crashes: The Java console disappears without any messages, the jp2launcher.exe task terminates, and the debugger "disconnects".
I would like to know whether or not other people have this problem debugging Applets with Java 1.8.0_60. If you can take your time about moving on from a breakpoint I'd like to know what you're doing differently. A breakpoint's not much good if you don't have time to look at the state of things.
I've searched Stack Overflow for tags [applet] and [debugging] with any of the words "crash", "stop", and "terminate" but found only one, irrelevant question.
My environment: I'm running 32 bit Java 1.8.0_60 on 64 bit Windows 7. I run my Applet in Internet Explorer or Firefox. I'm using the IntelliJ debugger. I'd try a different version of Java but that's not an option these days, I believe, without removing all recent versions of Java from my computer - a lot of trouble since I'd need to install them all again.
I am a newbie to Java and I have this app developed by someone else which is having some issues.
This Java app works well on windows xp 32 bit, but there is a delay while running on 64 bit windows 2008 R2 server. I have asked the customer to make sure that they are running the 32 bit version of JRE. I have checked the traces for the application and the application has an issue while calling a synchronized block always. This synchronized block adds the data into a queue from which it is picked up by some other process. I have checked the traces if some other process is using the block but it isn’t. The only confusing part is that the same app runs perfectly on windows xp 32 bit.
After googling I came to know that there are threading issues in win64
Help me with this.
This isn't exactly an answer, but it might be of some help and it's more than a comment:
Most likely your 64 bit machine has more cores than the 32 machine, making it more likely that two or more threads really will run at the same time and any synchronization problems that never, or rarely, arise on the 32 will quickly pop up on the 64. Also, newer machines tend to execute more instructions at once than older machines. Both types reorder them as they do so. (Also, compilers often reorder the code.) So the 64's are a bit worse to start with, and when you throw in the more extensive, real multithreading the problems multiply.
(This can work the other way: the many-core machines tend to run threads in a predictable order, where a single core machine can wait many minutes to run something you expected would be executed immediately.)
I've usually found the best way to fix bugs is to stare at the code and make sure everything is precisely right. (This works better if you know when something is precisely right.) Failing that, you need logging messages that only print out when they're useful (it's hard to sort through a billion of them). You seem to have no trouble reproducing your problems (which almost makes me think it may not be a multithreading problem at all), which should make it a bit easier to figure out.
A few months ago I created a Java application which calculates chess ratings. I only ever tested it on my computer, but the program worked as expected.
I only just found out that on certain operating systems, the program doesn't work as it should. I've included a picture of the incorrect output on Windows 7 whereas this is what I get on Windows 8. (The player's rating should decrease since he scored only 1.5/5 against lower rated opposition). It seems that the program does not allow the player's rating to decrease.
Can anyone point me in the right direction as to why the program is behaving differently between these two versions of Windows? I was unable to find any explanation here on SO or anywhere else.
I think the most plausible explanation is that the Windows 7 version has a different argument there in the field 2: 2068 whereas Windows 8 has 2048.
Firstly, here are a couple of things that will NOT be the cause.
Arithmetic does not behave differently between Java on Windows 7 and 8. If you are running the same (single-threaded) algorithm with the same inputs, then the outputs should be the same.
Arithmetic does not change on 32-bit versus 64-bit JVMs.
So what could it be? Assuming that it is the same JAR, then it is likely that the algorithm doesn't change. So here are a couple of possibilities.
It could be a result of different inputs. Without looking at the algorithm, we can't exclude the possibility that there is something about it that makes it sensitive to the inputs in an unexpected way.
If there was a race condition in your code, you could find that that some aspect of your program doesn't work properly on some Java platforms ... due to differences in CPU speed, memory architecture and / or thread scheduling.
That's about as precise an answer as you could possibly get ... without looking at your code. So I think you are going to have to debug this yourself.
Get access to some Windows 7 machine that exhibits the problem.
Run the application with a debugger attached to see if the problem recurs under those conditions. If it does, then debug in the normal way to figure out why the algorithm is not working.
If attaching a debugger (and setting breakpoints) changes the way the program behaves (i.e. it makes the problem "go away") then you have evidence that points to a race condition of some kind.
For future Googlers, the problem wasn't with Java; it was a problem with newlines in a text file from which my program was reading data. For some reason, the "\n" character separating values in my text file was not showing up in Windows 7 but worked fine in Windows 8. Very strange but glad that it's fixed!
I have tried three IDEs, all of which I'm fairly sure require Java to run, and all of them start up very very slow (30 seconds to 1 minute) on the first launch of the day. After that, they all start up lightening fast.
The three programs are: Aptana Studio 3, Eclipse, and PHP Webstorm.
Based on upon my web searches, I have modified the AptanaStudio3.ini using some of the suggestions on how to speed it up and they all work ... for every start up after the first launch, that is, but the first launch of the day remains painfully and inexplicably slow.
I have searched SO and I did not see any questions speaking to this issue. If anyone finds an answer here, thank you very much but I could not.
My only conclusion is that this issue is related to how Java runs on Windows 8 since all three software programs are adversely affected. Is this a known bug in Java on Windows 8? I have no idea what to think but I would be greatly appreciative if someone can offer help.
OBSERVATION: from my testing, it seems that if I start up my laptop and then launch Eclipse or Aptana within the first say the first 10 minutes of booting, it launches quicker (still slow but not as bad) then if I were to wait for about an hour and then launch my IDE. Not sure what this indicates.
Thanks
Though you can tune the Eclipse (or Aptana) .ini file and do things like disable class verification and boot using the JVM DLL, this has more to do with OS and hardware disk caching than the JVM. Boot each of the IDEs from a Ramdisk and you'll see that they boot equally as quickly from RAM the first time as they do from 'disk' the second time.
Source: I've spent a lot of time trying to solve this problem already. :)
It might be worth checking your antivirus scanner behaviour - I have precisely this problem.
In spite of SSD & reasonably quick i5 on win8 ultimate, the first boot time for eclipse is measured in many minutes (can be over 10), with subsequent restarts being done in a matter of tens of seconds. The whole PC can do a full restart in about half a minute, so its unlikely to be a raw I/O issue.
From looking at the cpu hogs & digging from there, it appears that the a/v (macafee) is doing an on-access scan for all the eclipse components & plugins after every boot & I suspect this is where much of the time is being taken.
I'll post an update when I've persauded someone to exclude eclipse & jvm from the on-access scan...
Since Aptana Studio is based upon Eclipse there is no big difference to be expected.
This is not a known Bug for Java on Windows 8, since I experienced it at least already in Windows 7. AFAIK it has to do with starting the JVM for the first time.
Of course you could throw a lot of memory at it or tweak the .ini of the IDE. The JVM-startupprocess wouldn't really be affected and it would still be slow. What is neglectable for a server is a problem on the desktop. For details take a look at http://en.wikipedia.org/wiki/Java_performance#Startup%5Ftime
I'm using the external java package jdde in MATLAB. Please note that for the following example, the DLL file that comes with the package needs to be on the MATLAB librarypath. The method to do this is different depending on your MATLAB Version.
Using jdde in MATLAB works fine, except for the first time after I reboot the computer or I logoff/logon in Windows. When I run the following code for the first time after a computer reboot, MATLAB will stay in busy mode forever (with 0% CPU). When this happens, I kill the MATLAB process in the task manager and restart MATLAB. When I run the same code again, it will execute instantly (not staying busy forever).
javaaddpath('C:\pretty-tools-JDDE-1.0.2.jar')
a = com.pretty_tools.dde.client.DDEClientConversation;
a.connect('','');
To sum it up, the above code will cause MATLAB to stay busy forever the first time I run it after a system reboot or user logoff/logon. When I run it again after killing the MATLAB process, it will work perfectly fine (not hanging up MATLAB).
I have seen this behavior on different computers, and in different Versions of MATLAB (2010 and 2012). I'm using Windows 7 x64.
In the code example, the a.connect command is the one that causes MATLAB to stay busy forever. Putting this command in a try/catch block would not help, because the a.connect doesn't cause an error, it just never does continue.
I'm not sure if this problem is caused by MATLAB or by the java package.
Any ideas how to get rid of this behavior would be much appreciated.
Note: The input argument of a.connect does not matter, it will always hang, so I just gave '' as input in this example.
Code hangs without any know reason in DdeInitialize() method. New build JDDE-2.0.3 contains workaround for this problem.
Try running the add path command on its own so that there is a second or two before it tries to execute code dependant on the jar. I have found this to often be the problem with intermittent issues having to do with jars in Matlab
Switch over to classic mode initially so that u will get rid of that.