Full disclosure: this is a federal computer/system so I have limited capability to make significant changes, but our federal "Enterprise" service desk of course does not know what is happening, so, I'm here.
I have a 64 bit operating system set up due to setting up ODBC connections to work with various programs which includes R 64 bit (this is the set up we were told we needed for all the systems to work). I of course also need Java 64 bit in order to use many of the R packages available nd have installed 64 bit Java multiple times, while sometimes removing and sometimes leaving 32 bit Java installed. Everything works fine for a while and I'm able to use the packages requiring Java by setting the Java environment path as necessary. No problems there.
The issue comes a few hours/one day later when my entire system shuts down with no notification at all (all programs just shut down while I'm actively working in them). The system reboots itself, 64 bit Java is uninstalled and 32 bit Java is reinstalled (regardless of whether I had uninstalled the 32 bit version or not) and I'm left to reinstall 64 bit, which works for a few hours before the whole process repeats itself.
I can't find anything anywhere for the same issue so... Anyone have any ideas? Our service desk basically just told me our systems only force reboots for Windows updates and and don't have any idea what is happening.
Edit: This is Java 1.8.0_111 although I've had the same issue with previous updates of Java 8.
Edit 2: No one else is having the same issue and are having no trouble with 64 bit Java on their computers. I'm special.
Related
I am using AS 3.1.2 to create an app but when I typing code, which is always, the AS have a delay from letter to letter and it very annoying to work like this.
I treid to reinstall the AS but it didn't work.
Someone maby know how to fix it?
I have 16gb ram
and Intel I5 6500 processor
When the AS running he using +- 2.5gb of ram
I don't know if this is the actual cause, it's merely a proposition. Have you tried checking the compatibility of AS3 with your Windows version, because from your task Manager view, it is evident that you have a 32 bit system. Since AS 3 is released recently with 32 bit compatibility being dropped with recently released softwares, games and OS, I assume the problem is with your 32 bit system. Try running it on a 64 bit system and it may solve the problem.
I have a program using JDK 1.7 running on Windows Server 2008 (32 bits). If I want to re-deploy the program to the latest Windows Server (64 bits), do I need to rewrite the program or just minor change is ok?
Thanks a lot!
Short answer
No, you should not need to change your code. You don't even need to recompile it. Just run your JAR/class and it should work fine.
You didn't provide much details of your application, so I ask you to read the long answer for more info, since there are considerations which might help you in the future.
Long answer
The Java Compiler generates bytecodes which are later interpreted by the JVM. The JVM translate the bytecode into native commands. The JVM will do the "hard work" while you can focus on one single program. The Java platform is platform independent, therefore you should not need to change your code if you are going from 32 bits to 64 bits Windows.
As always, there are some exceptions, which go beyond the 32/64 bits case. I will list some for example:
Breaking lines in Linux and Windows while working with persistence (MS files usually have carriage return)
Using JNI to consume native libraries (This might impact 32/64 bit programs)
Fonts used on different operational systems
Maybe some Java bug, but very improbable
As a general practice, if you are going to cross platform your application, try to find the "boundaries" of your program. When do you have go "outside" your application to seek specific OS resources?
Even if your program runs in an application server, such as JBoss, you should not need to change your code.
I think your program will work fine without any changes, just keep in mind that exceptions may apply.
I don't think you need to change anything. Do you use any native code through jni?
First, are you using JDK or JRE on the 32 bit Windows? You just need JRE to run your application.
Second, on Windows 8, you can still install 32 bit JRE so your application should run.
Third, if you installed 64 bit JRE, your application should still run. There might be more bugs in 64 bit JRE. If you encounter a lot of bugs, just use 32 bit JRE instead.
i have developed a desktop application for my college project. I developed in 64 bit machine with NetBean IDE 7.0.1 of 32 bit and i have JDK of 32 bit, project runs perfectly form NetBean but when i converted into .jar it did not work, but same .jar file works in 32 bit machine. Anyone have idea about this thank in advance.
Under normal circumstances, you can take code developed on a 64 bit machine and / or a 64 bit JVM, and run it on a 32 bit JVM ... and vice versa. This applies whether or not you are using a JAR.
The fact that you are having trouble says that you've done something wrong. However, without some more information, we'd be wasting our time speculating on what that might be. "It did not work" is not enough to go on. (It is like going to a doctor and saying, "I'm not well" and expecting him to cure you on that basis alone.)
I am thinking about buying an Apple Powerbook 1.5 GHz machine. While my primary focus for that machine would be internet, I may also do some programming on that machine since it would be the machine I would be taking to college...
What I wanted to know if there would be any major difference in context with the compilers used etc? Would I have to setup a completely different environment for the Power PC?
To be fairly clear, my primary categories of work include:
* Python {i know mac supports this right out of the box}
* PHP/MySQL
* HTML/CSS
* Javascript
* Java - I will be starting to learn Java, do this is pretty significant.
I am a complete n00b as far as Mac OS is concerned. Any and every help is appreciated.
PS: If this falls in the wrong category, I apologise.
Keep in mind that, with the latest recent release of OS X, 10.6 or Snow Leopard, Apple has pulled the plug on Power PC Macs: 10.6 does not run on any PPC Mac. Based on its past support policies, you can expect that Apple will continue to provide security updates and, possibly some bug fixes and minor features, for 10.5 (Leopard) until the next release of OS X (as yet, unannounced). But you can also expect that more and more things will be released by Apple or third-parties that are Intel-only, like the things already mentioned. Of the list you mentioned, it would seem that the only immediate concern is Java 1.6; Python and the rest will be no problem for a long-time to come.
By the way, you might want to check out MacPorts and Fink, two independent projects that tailor and package for OS X hundreds of popular open source packages. If it isn't already shipped with OS X or you need a newer version, you may find something you need there.
The Powerbook can't do Java 1.6. That might be a problem for you. You also can't do iPhone development on it. Other than that, once it's maxed out on RAM it's a pretty decent development environment.
I own a MacBook (intel core 2 duo processor) myself and would strongly discourage you to get an older model than that if you want to get reasonably up-to-date java support. (Java 1.6 does not work on older models as far as I know) I really like my macbook and it is a great development machine for me, but I have strong doubts on the java support (See for example http://stuffthathappens.com/blog/2007/10/28/os-x-java-definitive-timeline/).
I have an 12" 1.5 Ghz, 1.25GB ram G4 Powerbook and I wouldn't recommend it for java development due to the fact that running an IDE (Eclipse or NetBeans) will be painfully slow. Also expect to buy a new battery for an old laptop.
If 10.5 is not enough for you, you may want to consider installing Linux since the StuffIt you mention is easy to install with e.g. Ubuntu.
I've got a little game that a friend and I are writing in Java. It's kind of badly coded and we're working on refactoring it, but that's not really the issue right now. We both have 64 bit machines and I guess before we were both using 32 bit JDKs, but recently I had some problems and so I removed all JDKs and installed the latest 64 bit JDK, and I'm not sure when but my friend is also now running a 64 bit JDK. Our game was running fine in the 32 bit JDK, but with the 64 bit version the game won't start. I've been trying to debug it with eclipse, but it's been a bit of a pain.
Our game is networked and multithreaded, and I think we have some issues with how we synchronized things (I didn't fully understand the whole idea of synchronization when I was writing it before) eg. we had made our run() methods synchronized which has no effect, but despite the stupidities of large parts of our code the stuff still runs on a 32 bit JVM (Windows and Linux).
The game starts up where one person hosts a game, and then others can join until the host decides to start the game. It then sends a prompt to all the players, asking if they want to start, and if all say yes the game starts. What is happening on the 64 bit JVM is that it sends the message, but it seems like the response is getting lost or something, or the server isn't counting correctly that everyone has OKed because the game doesn't actually start. Actually, the host gets a few more messages that the other player(s) don't get and gets a little farther in starting the game, but the server seems to get stuck somewhere.
Any ideas what might be the problem? Our code is up on github if anyone wants to take a look. I'd be extremely happy if you did, but I don't expect anyone to wade through our ugly code. Thanks!
By the way, we are both running on 64 bit Windows Vista and JDK 1.6 u12 and u14, but we also run Linux although I haven't been able to test it on a 64 bit Linux JVM yet.
Oh, more details about why I'm pretty sure it's a 64 bit JVM isssue:
So we were working on this basically in the fall semester, and stopped working on it for a while. After 6 months we pick it up again, stagger at our horrid code, and start trying to clean it up. Then we realize that neither of us can run it properly. I try to find a revision that works, but I get to the last revision from before we started working on it this summer and it's still not working. I then even checked some binaries (.jars) that I had compiled before and even the earliest revision I have doesn't work on the 64 bit JVM. I then checked in a 32 bit Linux VM running the Sun JDK1.6 JVM, and it worked fine. Thus, I'm pretty sure it's a 64 bit problem since before the same binaries were working perfectly.
I've also noticed that Vista was assigning IPv6 addresses to my sockets for some reason, when connecting to a server on my own machine (0:0:0:0:0:1 instead of 127.0.0.1) but I fixed anything that was IPv4 specific and it's still not working.
I actually have just created another problem on my github repository which is a whole other tale of woe, so I can't test my latest build on another machine right now. But the last build before refactoring works fine on a 32 bit JVM with a dual core, so it doesn't look like a race condition.
Oh, another thing, exact same problem running under OpenJDK 6 64 bit under Linux. I'm guessing it's a race condition that the 64 bit version somehow brings out.
The game starts up where one person
hosts a game, and then others can join
until the host decides to start the
game. It then sends a prompt to all
the players, asking if they want to
start, and if all say yes the game
starts. What is happening on the 64
bit JVM is that it sends the message,
but it seems like the response is
getting lost or something, or the
server isn't counting correctly that
everyone has OKed because the game
doesn't actually start. Actually, the
host gets a few more messages that the
other player(s) don't get and gets a
little farther in starting the game,
but the server seems to get stuck
somewhere.
This sounds like it might be a race condition, i.e. flawed or missing synchronization. Since race conditions are timing-dependant, almost anything (including switching JVMs) can cause them to manifest.
I'd stop worrying about 64bit vs 32bit and try to diagnose the actual problem. Since it involves multiple machines, it's unfortunately going to be very hard (which is generally the case with race conditions).
The best way to do it is probably to make sure all machines have synchronized clocks using NTP, and then log the sending, receiving and processing of messages with millisecond timestamps so you can see where messages get lost or aren't processed properly.
We found out what the issue was. There was a loop in one part where a thread waited on something to become ready that another thread was working on, except it was just a while(!ready){} loop. It seems like in the 64 bit JVM threads don't get preempted or something, because in the 32 bit JVM this loop would get preempted and then the other thread would finish and set the variable to true, but not in the 64 bit JVM. I understand now that we should have used wait/notify and locks to do this, but at least temporarily throwing a sleep() in there fixed it. Not exactly a race condition, more of a quirk of the threading model it seems, so I'm not accepting any of the other answers since they didn't answer the question I asked.
Are you running with the java process with the -d64 option? If not, then I'm pretty sure you're still running the JVM in 32-bit mode, and your issue may be related to the environment or the OS instead of the bitness.
I would not expect 64 vs. 32 to cause any issues in this case, threading is way more likely to be your cause
kudos for using raw sockets, but they're very tricky to get correct. Consider using a library for your network stack, like Apache Mina, unless of course the goal of the project is to write your own socket code. Definitely read over the quick start guide. It's text-based protocol maps directly to what you're using.
Side note: sticking synchronized on every method and using finalize are symptoms of bad things / code smells