Grow some balls and be responsible for your self and your own work. It is just a tool - no one is standing over you with a gun to use it - and if they are you have a much bigger problem than a crappy PDA.
As an employer I would expect my employees to do their job. If a tool like a blackberry is useful to someone, more power to them, if they don't want it, I couldn't care less. Does not get you off the hook for doing your job though. Now, your job either includes off-hour support or it does not. No PDA will change your contract. If it includes it, stop whining and do your job or quit. If it does not, stop whining and just turn the fucking thing off or at least ignore it. That's what I do as an employee.
People are just whining because they have no guts to stand up for themselves and have no self control. The PDA is the least of their problems. If you can't take responsibility for yourself, I have no sympathy for you.
Can anyone please tell me why we need to support IE6?
Because according to stats on one of my relatively high traffic sites - IE6 is still about 37.64% of the IE traffic (or more than 1/4 of ALL traffic). Sad but true.
It will block all traffic from legitimate IE6 users, and if you have a $20K router, you probably don't want to do that.
If you read the links in the article (and some comments further down), there are things you can do to block this, including blocking requests with these UAs that also have odd or missing headers, cookies, etc.
LOL, perhaps you might want to READ the rule before replying - it is NOT blocking all IE6 users, just the ones that are missing "Accept-Encoding" header
Conservation of Energy says that what they are claiming is impossible. Water simply cannot be the fuel source for a hydrogen fueled energy source. When you burn (i.e. oxidize) hydrogen you get water as the result. Since no machine yet devised by man is 100% efficient the machine can't even sit and spin, to say nothing of produce enough excess energy to move a vehicle. I love that people can state anything with conviction and as long as it sounds remotely scientific most people will just believe it. If you actually recall your high school physics, the law of conservation of energy only applies to a closed system, which this does NOT have to be and is probably not.
Now I am sure this may well be vaporware (no pun intended) but there is tech out there that does this that has been demonstrated to work. One comes to mind is the Purdue University prof that was making rounds recently talking about aluminum alloy catalyst that separates water on contact.
Now the claims of some in this thread that they are actually getting the energy from an Aluminum + water -> hydrogen + ? reaction is possible, but that isn't what they are claiming. And if they did it would be an Aluminum powered vehicle and we would be asking how many miles per pound it gets. While looking up high school physics, look up the word "catalyst" as well:-)
How do we know we can trust Google with your bookmarks? If you have "secure" bookmarks, you probably shouldn't be using a service like this. if you have "secure" bookmarks you probably need to find a dictionary and find the definition of the word "secure". Now saved passwords and browser history and cookies are another matter.
Google should know better. Abandonware? Open source it! Then if people care they can upgrade it for FF3. Considering the product relies on google's servers - it may not be enough to open source it for it to be usefull. That being said, it would be really nice if you could run your OWN servers for this - I might consider sync-ing things like passwords and browsing history.
Stealther is your friend. Two clicks (Tools->Stealther) puts you in porn mode.
Is there a reverse of this? I am not so concerned with porn as I am with revealing to one client names of my other clients, etc (by virtue of browser history) - so it would be nice to have a quick toggle of turning all history completion options to off from time to time.
Sounds like a good idea, but sometimes you need to act faster than 90 days in order to be effective. Unfortunately, any exceptions you can come up with would then be abused, much like everything else by this administration. Easy, if it is an emergency, it has a maximum time limit of 90 days before it has to be re-voted in by which point the 90 day rule is in effect.
Of course you can always static-link to your libs, but how is that different from just shipping the JDK along?
It's drastically different, and if you'd read the previous posts in the thread, this would be obvious. With statically linked libraries, the user can have one application that requires one specific version of the library running alongside another application that requires a different specific version of a library, and never even know there was potential for a conflict.
This is exactly why it is EXACTLY the same. With Java you can have multiple JVMs running alongside each other with no problems. Some of the apps I ship include their own JVM's. Not because they are really picky but because when you charge millions of $$'s per app you don't want to rely on clueless client's sysadmins to install your pre-req's. Plus it makes installing a dupe environment in QA much easier. Anyway, I offer multiple versions of JVM's that can be installed along side of each other without conflicting with each other, let alone anything on the system level. We install as an unprivileged user in a protected dir, so no other app can even SEE our JDK's (unless it is running as root, and no one with a clue runs apps as root) let alone be affected by it.
Shipping the JDK with a Java application isn't like that at all. Yes, if the prescribed version of the JDK is installed with my application, it ensures that my application runs (assuming I've done my job even halfway reasonably, of course). Installing that JDK, however, may break some of their other Java applications -- and the only way to fix them is to re-install some other version of the JDK, and in doing so, breaking mine.
Thats just FUD. It is simply not true. You can run multiple versions of JVM alongside each other.
There is also a substantial difference in practicality: static linking adds some to the size of the program, but not anywhere close to the same as the size of the JDK.
Sure, JDK is larger - it offers a heck of a lot more than average lib, but disk space is not an issue in modern world. Logically it is exactly the same - you add required libraries and code to your code and ship them together. Not that you really NEED to do it and its rarely done in either java or any other language, but capability is there in java as much as it is in C or any other language.
Installation isn't affected either -- static linking doesn't mean that the installation has to be carried out as root or anything like that -- whereas, the JDK normally should carry precisely such requirements, due (if nothing else) to exactly the problems outlined above.
FUD FUD FUD. You don't need to be root to install JDK. Just copy the files and run. JDK is 100% self contained in a single directory structure.
Of course, with something like VMWare, you can get around even the degree to which Java is broken -- all you have to do is create a separate virtual machine in which to run a separate copy of the OS, on which to run each required Java Virtual Machine. In a decent world such a suggestion could only ever be a joke, and in poor taste at that. In the Java world, it's neither a joke nor even unusual.
More FUD. For one, VMWare would be redundant (and retarded) as JVM stands for "JAVA VIRTUAL MACHINE" It is already a VM and there is no reason you need multiple OS's - unlike most compiled languages, Java code is not OS dependent.
Now, there ARE good reasons to run apps in VMWare on large scale apps, but that has nothing to do with selection of language app is written in.
The bottom line is that your entire post hinges on a simple lie that JVM is somehow tied to the system and that you can only have one installed. That is just not true.
Not so. It's true of a language that makes the end user provide/install a large part of the environment in which the program runs. Technically, this isn't a characteristic of the language per se, but of the implementation. Nonetheless, it's not the sort of problem that arises for those who use languages like Fortran, C, C++, Ada, etc. I disagree. In fact this is much bigger issue under C, C++ and so on as you usually have to link against multiple shared libs which creates nightmares orders of magnitude worse than anything Java can dish out. Just google around you will find many stories of executables failing due to missing or mismatched libs.
Of course you can always static-link to your libs, but how is that different from just shipping the JDK along? Just because all the libs are inside same executable file, does not mean that you are not just copying them along.
During development a similar problem can arise -- I can write code that requires a specific version of a specific compiler (or library). Somebody else can write code that requires a different specific compiler or library -- but unlike the situation with Java and such, this does not affect the end user.
You obviously never upgraded linux kernel or a major version of gcc. For example I have much code compiled under RH9 that does not come close to RUNNING under any modern Linux distro - let along compile. Sure you can track down the right version of the lib, then find the right versions of all the libs that lib relies on, then all the libs those rely on - but you can't honestly claim this is easier then installing a particular version JDK for your OS.
Of course, even with a language like this, a programmer can use things like.so's or DLLs (as the case may be) that can lead to problems -- as I said, this is a characteristic of the implementation, not the language. Nonetheless, it's much easier to avoid with something C, C++ or Ada than with something like Java or Python.
C'mon, when was the last time you seen anything larger than "Hello world" statically linked? Even something as simple as cat is dynamically linked against two libs.
There are system libraries or something in windows and different versions of the jre or jdk install different versions of that. And it does brake. Thats just not true. Every single file of the JDK, every library, every executable, every anything exists in one directory structure specific to each JDK build. You can take the whole thing and copy it into any other directory on any other machine and it will work. You can run two or twenty different versions side by side and they will not interfere at all as long as your env variables are set correctly.
The only "shared" things are: global environment variables, and file extension registration - both you can live without.The only other thing is the browser integration - and if you are using applets you will have all sorts of other problems. Applets suck.
> > In our case it's mostly because we have no choice. > You always have a choice.
What I mean is that the software we need for our business only runs on Windows. It is cost prohibitive to change to another software package -- about 2-3 million dollars that we don't have, being a nonprofit organization. That was mostly a joke.... mostly;-)
Using a launch script is a good idea except that our primary software vendor made their own launch program... and of course that program is NOT written in Java, so I'm SOL on that one. Of Beat them up to explain what it does. Chances are it will respect the env variables you pass into it.
course I could write my own launcher I suppose... Thats the spirit;-)
Also, something I failed to mention in that exact post you are replying to is that some of the applications are on web pages, so the ideas presented probably would not work for those. However, you did give me an idea: I could probably make a batch file that changes the Java home ENV variable to whichever version the person is about to need. It would be a pain in the @$$ for the end user, and isn't really a "fix", but it would at least allow them to run the programs they need. Now I just need to make sure a regular user has the permission to set env variables... seems unlikely, but it's worth a shot. I am nor sure I follow you, is the app a WAR/EAR file for a web app or is it an applet? It its a WAR file, your best bet is to run multiple containers (which is often a good idea anyway).
If its an applet, heck, I have no idea. Applets were a bad design by java, and were then blown out of the water by Flash and pretty much abandoned. Applets never work right, I would stay away from that technology. Your best bet is to either fix the applet code to be the lowest common denominator or switch to using proper applications instead. If you do want to use web as frontend, I would either concentrate on making it into an HTML/AJAX app or switch to something like FLEX - which works nicely with java on the backend and Flash on the frontend. Good luck with that.
Thanks: I am the sysadmin, and while I'm not the best ever, I am pretty good at what I do. And yes, we run Windows: it is rather unhelpful of you to claim that as part of the problem, since
My guess on you running windows was not meant as an insult, but as a guess based on two things - one is that most windows users do not understand concept of installing things on non-system level. Everything is usually installed by someone double-clicking an installer and not having any idea what that installer is actually doing - making life considerably more difficult. That being said, SUN is actually very good at installing multiple JVMs and JREs in parallel as far as I know. But the real issue is that the environment variables in Windows are significantly "broken" (or at least do not behave how one would expect them to), so you need a sysadmin that understands how they work on windows before messing with them.
Here is a quick rundown of things you may want to know - but I suggest you learn more than just this:
- Java app will run on whatever JRE you run with - it cannot and will not request a particular version - so it is your responsibility to tell it which jdk to run on or it will pick one from default env variables.
- Most of the time apps run on first java.exe they find in PATH, so if you want to run on non-default java, either change PATH or better yet provide the full path to executable when running.
- Some apps require JAVA_HOME env variable to be set to Java install dir so you are best of setting that. You can then use that to call java.exe via something like %JAVA_HOME%\bin\javaw.exe
- If you are using JDK, you probably want to point CLASSPATH to and appropriate tools.jar and other jars that match your %JAVA_HOME% - again, using JAVA_HOME variable is good.
- Rather than using system CLASSPATH variable - you are better off creating your own variable and passing it via "-cp " option on java.exe
- Unlike normal operating systems, setting env variables on Windows sometimes sets the system env variables (but not always) and usually only for new processes. This can lead to unexpected behavior when running apps that rely on default JDK - meaning you should either always reset default env variables in windows, or never rely on them at all and specify your own. This is a huge headache, and a good reason to hate windows.
- Most java apps will launch from a shell (UNIX) or batch(Windows) script - this is the perfect place to set the env variables. If not, you can make your own script.
- Some java apps are executable JAR files - these on windows rely on registry to run, your best bet for running these from scripts is to execute them via "javaw.exe -jar jarfile.jar" command.
the majority of people use Windows. In our case it's mostly because we have no choice.
You always have a choice.;-) Its not that its impossible to do in windows, its actually rather simple, but you do need to understand what you are doing before doing it.
I have installed multiple versions needed to run the programs and they HAVE broken each other. I have witnessed and experienced it first-hand. No amount of claiming that "it really does work" will change the reality that it does not.
Have you configured each program to run on its required version of JDK? If you don't turn on the engine, does not mean the car does not work.
Now, I cannot say that this is Sun's fault -- and based on previous experience with some of our software developers, I would not be surprised -- but the fact that it has happened MULTIPLE TIMES with different pieces of software (some are web apps, some desktop) tells me there is undoubtedly an underlying problem.
Yes I agree. My guess the underlying problem is lack of understanding on how Java works. (which is not a good sign for java developers, alas quite common in my experience)
If the developer is not supposed to use it, it should not be present at all. Of course I have never implemented my own programming language, but it seems like a good idea... Its not that they should *never* be used, just probably not in commercial/production code. There are plenty of cases where those parts of JVM are very useful, especially in internal and one-of processes. You can gain a lot of performance among other things. A friend of mine is doing the NetFlix challenge and has to use all sorts dark corners of JDK to squeeze it for performance. Its just that if you use it, it becomes non-portable support nightmar. But if you don't care about support (as is valid in some cases) - it is fine.
Are you serious? Where I work, we regularly use at least three Java applications, and each one requires a particular version of Java, none of which are the same. One of them requires Java 1.5, while another one will break completely if Java 1.5 is installed. It's a nightmare! And while yes, the version requirements may be the fault of the developers, the fact that it can happen at all is unacceptable. Erm, you must be running windows and don't have a sysadmin with a clue. You can run as many versions of JDK in parallel as you want and they will not interfere with each other. Its not rocket science, just set a few env variables. Thats actually one of my favorite things about Java - you are never tied to a "system" install of JVM - in fact you don't even need root privileges to install JVM.
So now I'm always wary about using Java applications, since they can easily get tied to a specific JRE and if that JRE has security flaws, you're SOL. Same can be said of ANY language that evolves. I am currently battling an app parts of which require Python 2.3, parts 2.4 and parts 2.5.
The bottom line is that no language will ever make the programmer smart. If the programmer is dumb enough to use some esoteric/ undocumented/ unsupported part of the JVM (Sun has a number of those, but no, it is NOT easy to get stuck on a specific JVM rev unknowingly) - thats the programmer's fault. If the app is supported (or at least open sourced) fixing this sort of a dependency on a particular version should be quick and easy. If you do not have code and the app is not supported, then you really shouldn't be running it in the first place! Sounds like the app was abandoned long before you realized it.
Don't get me wrong, I think its a cool toy I will be playing with, but until it actually works in more than one beta browser, its is no threat to Flash at all.
You mean like say, FireFox AND Webkit?
No, if you have bothered to read TFA, only beta of firefox 3 is fully supported and nothing else. Webkit is a little more supported than anything mainstream, but latest nightly Webkit (not even a beta!!) can do image handling, but not pixel or text processing.
Thus, anything outside of the above (images, pixel processing, and text) should work "ok" everywhere. Is it just me or does graphical language that does not fully support image, pixel, or text processing seems a bit.... silly.
Don't get me wrong, I think its a cool toy I will be playing with, but until it actually works in more than one beta browser, its is no threat to Flash at all.
ZFS doesnt offer me anything as im not managing servers Dtrace doesnt offer me anything as im not a developer SMF doesnt offer me anything i cant do with startup IPS doesnt seam any better than deb or rpm
Is there any reason to switch? If you do not use it, than you probably don't need it. Funny how "insightful" that statement is.
And every outdoor adventurer should use one too. I believe Steve had a watch based personal locator beacon, although people were not sure if he had it on him.
That I feel I'm confident enough in my ability to survive most situations. Enough so that I would rather they not send a search party out for me, cause if I don't show up in a day or two, then I'm dead, and they are wasting money. There are a lot of cases where people are found after a week or two still alive (sometimes barely) - The recent case of that CNET editor comes to mind - his family was found after a few weeks, and he would have survived if he stayed with them too. But if they would have called off search - they would have all died. I wonder if they were billed for the rescue...
Anyway, you might want to give up on yourself after a few days, but if *I* am LOST, just keep on searching. I could care less how much it costs.
I mean, how often does anybody actually survive a plane crash? Statistically speaking based on all recorded airplane crashes, you have roughly 50% chance of survival. Those odds go down if you are in the front of the plane (about 40% survival rate) vs back of the place (about 60%) - makes you think twice about that first class seat, doesn't it.
Slashdot Mirror
Grow some balls and be responsible for your self and your own work. It is just a tool - no one is standing over you with a gun to use it - and if they are you have a much bigger problem than a crappy PDA.
As an employer I would expect my employees to do their job. If a tool like a blackberry is useful to someone, more power to them, if they don't want it, I couldn't care less. Does not get you off the hook for doing your job though. Now, your job either includes off-hour support or it does not. No PDA will change your contract. If it includes it, stop whining and do your job or quit. If it does not, stop whining and just turn the fucking thing off or at least ignore it. That's what I do as an employee.
People are just whining because they have no guts to stand up for themselves and have no self control. The PDA is the least of their problems. If you can't take responsibility for yourself, I have no sympathy for you.
-Em
AVG doesn't execute javascript? That seems like it would be a very common vector for malware, no?
Most antivirus software does not execute viruses, why should this be different?
-Em
The question is, how much of that 37.64% is actually AVG in disguise...
I thought of that - answer is none. These stats are from actual browsers executing javascript - which AVG does not.
-Em
Can anyone please tell me why we need to support IE6?
Because according to stats on one of my relatively high traffic sites - IE6 is still about 37.64% of the IE traffic (or more than 1/4 of ALL traffic). Sad but true.
-Em
At a Command Prompt window, type /REMOVE_FEATURE fea_AVG_SafeSurf /REMOVE_FEATURE fea_AVG_SafeSearch
c:\downloads\avg_free_stf_xxxxxxxxxx.exe
where c:\downloads\avg_free_stf_xxxxxxxxxx.exe is the full path of your AVG 8 installer.
At least it is intuitive....
-Em
For the record, this is a REALLY bad idea.
It will block all traffic from legitimate IE6 users, and if you have a $20K router, you probably don't want to do that.
If you read the links in the article (and some comments further down), there are things you can do to block this, including blocking requests with these UAs that also have odd or missing headers, cookies, etc.
LOL, perhaps you might want to READ the rule before replying - it is NOT blocking all IE6 users, just the ones that are missing "Accept-Encoding" header
-Em
Now I am sure this may well be vaporware (no pun intended) but there is tech out there that does this that has been demonstrated to work. One comes to mind is the Purdue University prof that was making rounds recently talking about aluminum alloy catalyst that separates water on contact. Now the claims of some in this thread that they are actually getting the energy from an Aluminum + water -> hydrogen + ? reaction is possible, but that isn't what they are claiming. And if they did it would be an Aluminum powered vehicle and we would be asking how many miles per pound it gets. While looking up high school physics, look up the word "catalyst" as well
-Em
-Em
-Em
Is there a reverse of this? I am not so concerned with porn as I am with revealing to one client names of my other clients, etc (by virtue of browser history) - so it would be nice to have a quick toggle of turning all history completion options to off from time to time.-Em
-Em
This is exactly why it is EXACTLY the same. With Java you can have multiple JVMs running alongside each other with no problems. Some of the apps I ship include their own JVM's. Not because they are really picky but because when you charge millions of $$'s per app you don't want to rely on clueless client's sysadmins to install your pre-req's. Plus it makes installing a dupe environment in QA much easier. Anyway, I offer multiple versions of JVM's that can be installed along side of each other without conflicting with each other, let alone anything on the system level. We install as an unprivileged user in a protected dir, so no other app can even SEE our JDK's (unless it is running as root, and no one with a clue runs apps as root) let alone be affected by it.It's drastically different, and if you'd read the previous posts in the thread, this would be obvious. With statically linked libraries, the user can have one application that requires one specific version of the library running alongside another application that requires a different specific version of a library, and never even know there was potential for a conflict.
Thats just FUD. It is simply not true. You can run multiple versions of JVM alongside each other.Shipping the JDK with a Java application isn't like that at all. Yes, if the prescribed version of the JDK is installed with my application, it ensures that my application runs (assuming I've done my job even halfway reasonably, of course). Installing that JDK, however, may break some of their other Java applications -- and the only way to fix them is to re-install some other version of the JDK, and in doing so, breaking mine.
Sure, JDK is larger - it offers a heck of a lot more than average lib, but disk space is not an issue in modern world. Logically it is exactly the same - you add required libraries and code to your code and ship them together. Not that you really NEED to do it and its rarely done in either java or any other language, but capability is there in java as much as it is in C or any other language.There is also a substantial difference in practicality: static linking adds some to the size of the program, but not anywhere close to the same as the size of the JDK.
FUD FUD FUD. You don't need to be root to install JDK. Just copy the files and run. JDK is 100% self contained in a single directory structure.Installation isn't affected either -- static linking doesn't mean that the installation has to be carried out as root or anything like that -- whereas, the JDK normally should carry precisely such requirements, due (if nothing else) to exactly the problems outlined above.
More FUD. For one, VMWare would be redundant (and retarded) as JVM stands for "JAVA VIRTUAL MACHINE" It is already a VM and there is no reason you need multiple OS's - unlike most compiled languages, Java code is not OS dependent.Of course, with something like VMWare, you can get around even the degree to which Java is broken -- all you have to do is create a separate virtual machine in which to run a separate copy of the OS, on which to run each required Java Virtual Machine. In a decent world such a suggestion could only ever be a joke, and in poor taste at that. In the Java world, it's neither a joke nor even unusual.
Now, there ARE good reasons to run apps in VMWare on large scale apps, but that has nothing to do with selection of language app is written in.
The bottom line is that your entire post hinges on a simple lie that JVM is somehow tied to the system and that you can only have one installed. That is just not true.
-Em
Technically, this isn't a characteristic of the language per se, but of the implementation. Nonetheless, it's not the sort of problem that arises for those who use languages like Fortran, C, C++, Ada, etc. I disagree. In fact this is much bigger issue under C, C++ and so on as you usually have to link against multiple shared libs which creates nightmares orders of magnitude worse than anything Java can dish out. Just google around you will find many stories of executables failing due to missing or mismatched libs.
Of course you can always static-link to your libs, but how is that different from just shipping the JDK along? Just because all the libs are inside same executable file, does not mean that you are not just copying them along.
During development a similar problem can arise -- I can write code that requires a specific version of a specific compiler (or library). Somebody else can write code that requires a different specific compiler or library -- but unlike the situation with Java and such, this does not affect the end user.
You obviously never upgraded linux kernel or a major version of gcc. For example I have much code compiled under RH9 that does not come close to RUNNING under any modern Linux distro - let along compile. Sure you can track down the right version of the lib, then find the right versions of all the libs that lib relies on, then all the libs those rely on - but you can't honestly claim this is easier then installing a particular version JDK for your OS. .so's or DLLs (as the case may be) that can lead to problems -- as I said, this is a characteristic of the implementation, not the language. Nonetheless, it's much easier to avoid with something C, C++ or Ada than with something like Java or Python.
C'mon, when was the last time you seen anything larger than "Hello world" statically linked? Even something as simple as cat is dynamically linked against two libs.Of course, even with a language like this, a programmer can use things like
-Em
The only "shared" things are: global environment variables, and file extension registration - both you can live without.The only other thing is the browser integration - and if you are using applets you will have all sorts of other problems. Applets suck.
-Em
> You always have a choice.
What I mean is that the software we need for our business only runs on Windows. It is cost prohibitive to change to another software package -- about 2-3 million dollars that we don't have, being a nonprofit organization. That was mostly a joke.... mostly
written in Java, so I'm SOL on that one. Of Beat them up to explain what it does. Chances are it will respect the env variables you pass into it. course I could write my own launcher I suppose... Thats the spirit
If its an applet, heck, I have no idea. Applets were a bad design by java, and were then blown out of the water by Flash and pretty much abandoned. Applets never work right, I would stay away from that technology. Your best bet is to either fix the applet code to be the lowest common denominator or switch to using proper applications instead. If you do want to use web as frontend, I would either concentrate on making it into an HTML/AJAX app or switch to something like FLEX - which works nicely with java on the backend and Flash on the frontend. Good luck with that.
-Em
Thanks: I am the sysadmin, and while I'm not the best ever, I am pretty good at what I do. And yes, we run Windows: it is rather unhelpful of you to claim that as part of the problem, since
My guess on you running windows was not meant as an insult, but as a guess based on two things - one is that most windows users do not understand concept of installing things on non-system level. Everything is usually installed by someone double-clicking an installer and not having any idea what that installer is actually doing - making life considerably more difficult. That being said, SUN is actually very good at installing multiple JVMs and JREs in parallel as far as I know. But the real issue is that the environment variables in Windows are significantly "broken" (or at least do not behave how one would expect them to), so you need a sysadmin that understands how they work on windows before messing with them.
Here is a quick rundown of things you may want to know - but I suggest you learn more than just this:
- Java app will run on whatever JRE you run with - it cannot and will not request a particular version - so it is your responsibility to tell it which jdk to run on or it will pick one from default env variables.
- Most of the time apps run on first java.exe they find in PATH, so if you want to run on non-default java, either change PATH or better yet provide the full path to executable when running.
- Some apps require JAVA_HOME env variable to be set to Java install dir so you are best of setting that. You can then use that to call java.exe via something like %JAVA_HOME%\bin\javaw.exe
- If you are using JDK, you probably want to point CLASSPATH to and appropriate tools.jar and other jars that match your %JAVA_HOME% - again, using JAVA_HOME variable is good.
- Rather than using system CLASSPATH variable - you are better off creating your own variable and passing it via "-cp " option on java.exe
- Unlike normal operating systems, setting env variables on Windows sometimes sets the system env variables (but not always) and usually only for new processes. This can lead to unexpected behavior when running apps that rely on default JDK - meaning you should either always reset default env variables in windows, or never rely on them at all and specify your own. This is a huge headache, and a good reason to hate windows.
- Most java apps will launch from a shell (UNIX) or batch(Windows) script - this is the perfect place to set the env variables. If not, you can make your own script.
- Some java apps are executable JAR files - these on windows rely on registry to run, your best bet for running these from scripts is to execute them via "javaw.exe -jar jarfile.jar" command.
the majority of people use Windows. In our case it's mostly because we have no choice.
You always have a choice. ;-) Its not that its impossible to do in windows, its actually rather simple, but you do need to understand what you are doing before doing it.
I have installed multiple versions needed to run the programs and they HAVE broken each other. I have witnessed and experienced it first-hand. No amount of claiming that "it really does work" will change the reality that it does not.
Have you configured each program to run on its required version of JDK? If you don't turn on the engine, does not mean the car does not work.
Now, I cannot say that this is Sun's fault -- and based on previous experience with some of our software developers, I would not be surprised -- but the fact that it has happened MULTIPLE TIMES with different pieces of software (some are web apps, some desktop) tells me there is undoubtedly an underlying problem.
Yes I agree. My guess the underlying problem is lack of understanding on how Java works. (which is not a good sign for java developers, alas quite common in my experience)
Also, we are talking about JREs, not JD
-Em
Are you serious? Where I work, we regularly use at least three Java applications, and each one requires a particular version of Java, none of which are the same. One of them requires Java 1.5, while another one will break completely if Java 1.5 is installed. It's a nightmare! And while yes, the version requirements may be the fault of the developers, the fact that it can happen at all is unacceptable. Erm, you must be running windows and don't have a sysadmin with a clue. You can run as many versions of JDK in parallel as you want and they will not interfere with each other. Its not rocket science, just set a few env variables. Thats actually one of my favorite things about Java - you are never tied to a "system" install of JVM - in fact you don't even need root privileges to install JVM.
-Em
The bottom line is that no language will ever make the programmer smart. If the programmer is dumb enough to use some esoteric/ undocumented/ unsupported part of the JVM (Sun has a number of those, but no, it is NOT easy to get stuck on a specific JVM rev unknowingly) - thats the programmer's fault. If the app is supported (or at least open sourced) fixing this sort of a dependency on a particular version should be quick and easy. If you do not have code and the app is not supported, then you really shouldn't be running it in the first place! Sounds like the app was abandoned long before you realized it.
-Em
You mean like say, FireFox AND Webkit?
No, if you have bothered to read TFA, only beta of firefox 3 is fully supported and nothing else. Webkit is a little more supported than anything mainstream, but latest nightly Webkit (not even a beta!!) can do image handling, but not pixel or text processing.-Em
Don't get me wrong, I think its a cool toy I will be playing with, but until it actually works in more than one beta browser, its is no threat to Flash at all.
-Em
Dtrace doesnt offer me anything as im not a developer
SMF doesnt offer me anything i cant do with startup
IPS doesnt seam any better than deb or rpm
Is there any reason to switch? If you do not use it, than you probably don't need it. Funny how "insightful" that statement is.
-Em
All planes and boats should have one.
And every outdoor adventurer should use one too. I believe Steve had a watch based personal locator beacon, although people were not sure if he had it on him.
-Em
Anyway, you might want to give up on yourself after a few days, but if *I* am LOST, just keep on searching. I could care less how much it costs.
-Em