I'm restoring an antique vehicle and for that I use the EPC (Electronic Parts Catalog) from Mercedes Benz. (Membership is free, so those wanting to see the program I'm talking about can go here if they want to check it out.) To get to the program, there's a sign in page, then another page with a link. Clicking the link downloads a file called ewa-net.jnlp and it's launched with JavaWS.
I used to use this program on my Linux system and it worked. I remember I changed either the osname variable in my /etc directory or I changed the OS in Firefox before I ran the program and changed it back when I was done, so it wouldn't effect any other Java program. The EPC program worked just fine under those conditions. I strongly suspect the reason for requiring Windows is more of a defensive move (for example, to avoid liability or to avoid having to fix bugs on multiple OSes).
I'm aware that making changes like this can mess up a program, but this is used only to go through the parts catalog and to examine part diagrams, which helps in determining part locations or placements or helps the parts guys because I can help them find the page a part is on quickly if I've done my research before calling them. I'm not saving data or modifying anything on a disk drive or elsewhere (although I do sometimes take a screenshot and print it out).
I cannot download ewa-net.jnlp and just run it whenever I want. I have to go through the HTML login page, then run the program from their site, so I can't just run the program from the command line or something like that. (Unless that replaces running it with JavaWS right after I log in.)
Now I'm using an iMac, using Snow Leopard. I tried finding and changing the osname on here, and it didn't work.
Right now whenever I need to use the EPC, I have to start up a Windows VM in Parallels and about the only reason I use that Windows VM is for this program.
Is there some way I can trick Java so when I run this program, it thinks it's on Windows? I'm aware this could crash, but since the catalog worked fine on Linux, I want to at least try it on OS X.
I thought maybe I could use a wrapper script that runs JavaWS, but I'm not quite sure what to do and, as I said previously, changing the osname setting didn't seem to work.
Is there anything that might help me trick this program into thinking it's on Windows?
It depends on exactly what is applying the Windows restriction.
It is possible for a JNLP file to specify elements for specific operating systems only, thus effectively restricting it to a particular OS. So if the JNLP file contains something like this...
<resources os="Windows XP">
<j2se version="1.5+" />
<jar href="/example.jar" />
</resources>
...then that could be what's preventing you from running it on Mac OS X. Have a look at the JNLP file (I'm unable to see it, as a non-US resident I can't sign up myself) and see if that's the cause. If it is maybe you can edit it. Why is it that you said you can't download ewa-net.jnlp? If you can download the JNLP file, edit it to have os="Mac OS X", then double-click it to run it (or right-click and choose Open With > Java Web Start).
Alternately, the reason why changing osname didn't work for you could be that you changed it in the wrong installation of Java. Apple moved the installation location of Java sometime (I think) after Snow Leopard was released. So you may find your installation in either of these locations:
/System/Library/Frameworks/JavaVM.framework/Versions
/System/Library/Java/JavaVirtualMachines
If you only updated one of these locations, you may have to do it in the other location too.
Related
How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it tries to load classes?
In particular, what file paths is it TRYING to access, only to perhaps discover whatever it's looking for is not there, at least as it interprets the specification given? There was a way to get that information, but I can't find it now.
Note that this is Java version "1.8.0_333" on Windows 10.
I've tried every flag known to me, via the -h and -X flags, and I strongly suspect what I'm looking for is (was) an X flag that's been removed, just as the -X help output warns. And so, there must be an OS way to figure this out, I sure hope!
You might ask why? Whatever for? What are you trying to do? Well, that's the bulk of this question's text. To wit:
As one of the very early users of Java (I started with 1.1) way back in the '90s, I had an issue moving an application suite I'd written for my company on Linux to MS Windows and I got it working by using Cygwin. Along the way, this same sort of issue came up and I quite vividly recall having found a mechanism for getting the Java launcher to articulate just what file specifications - paths - it was actually using in searching for the appropriate class. And through using this, I found that the CLASSPATH was being specified incorrectly, and with some experimentation, I got it working reliably. Now I need to do that again!
This flag I'd used was immensely helpful in figuring out just what the file specification format CLASSPATH needed to be (we're not talking semicolons here) this combination of OS, Java, and Cygwin. After some hours of what I hope was reasonable hunting, I'm wondering if this capability has been removed at some point? Either that or "I'm looking for the wrong thing." Heck, since the source is available (I think!), maybe some brave soul has hacked the java utility to do such a thing?
It may help to understand that for this application I wrote for my company, it was a major goal to have the source work pretty much the same on all Windows and Linux / Unix systems (and at the time, macOS), and just use a configuration file to tell the code what's different. And that wasn't easy to figure out, but with this flag, it wasn't that hard, either.
But, unfortunately, I haven't needed this knowledge since I figured it all out all those years ago, and apparently, this little kernel of knowledge is very hard to find today. Or, it's no longer pertinent to the modern version(s).
I don't think this has anything much to do with the actual problem, but it may help in people's thinking if they understood the scenario: The current situation is that I have a fully functional installation of this software on Windows 7 to use as a comparison for how to configure things on Windows 10 (and hopefully younger). The Windows 7 is running a pretty modern Cygwin installation and very nearly the most modern Java - just a sub-version away from the new installation from last week on a Windows 10 box. (Everything's bright and shiny new on the new box.)
The required format for CLASSPATH on the nearly identical but fully functional Windows 7 system is:
CLASSPATH="C:/opt/OurInstallationDir/lib"
And that's it.
This value is picked up in several places as the code later needs to launch Java itself to do some unusual things. However, the java command that gets it all going is launched from a C program - not that that matters for this problem - but the C program (compiled under Cygwin, but perfectly runnable from any Windows environment) helps ensure that the Java environment is secured (policy file contents and so forth) before getting into Java, else it refuses. And this program on Windows 11 launches Java just fine, it's just giving it a CLASSPATH that isn't useful, apparently, even though the files are there where they should be, etc.
Configuring things as before just doesn't work, even from the command line. No version of specifying CLASSPATH seems to work if it's more than a dot; the only thing that works, is being in the /lib directory when starting and using "-cp ." ... But that's just not going to fly for so many reasons! To be a little more clear, I've tried reversing the slashes, using /cygdrive/c/, and whatever else I could think of. But, at least we know that if you're in the directory and use -cp, it will find and launch the program. So, there's nothing wrong with the Java, just pointing the java utility at it.
Again: How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it's trying to load classes?
You use this construct on the JVM:
java -XX:+TraceClassPaths -cp "C:\opt\SomeDirectory\lib" myClass
I was able to get confirmation of what Java was using, not only for my CLASSPATH, but "internally" by using the above.
The fact that it echoed back both what I was doing and what it was doing somehow gave me the insight to check everything about it. Java itself doesn't work (at all) if it's installed in a location that it thinks has a link in it, and it's own fetches go right back to the system disk specification.
From that I found that Java on Windows won't take a CLASSPATH that has a link in it!
Simply ensuring that the whole tree was specified "from the top" of the drive it's on works. If it's not, it won't.
It's now working happily using the syntax noted above.
This is quite different from every other application I've seen on Windows. But, well, it's Java!
This really came from a pointer from Mark Rotteveel who commented above about this article: How to track when class is loaded and destroyed in jvm? And therein I learned how to get the list of all the options the presently in-use JVM supports. All Java developers should be aware of this in my opinion, so thanks to Mark for that.
I've been working on an online game for a while now and I've recently decided that I want to share it with some of my friends for testing. Now I decided that I want to make an installer for it, just to make it easier/fancier to get the game. I originally wrote it in Java and used Launch4j and Inno Setup to make my setup.exe but when I initially run it, windows smartscreen thinks it could be dangerous since its "unknown". What should I do in order to prevent this from happening
???
Since Windows detect that the installer has an unknown origin, the Windows Defender Smartscreen blocks this kind of executable.
If you want to eliminate this problem, I suggest you to apply a digital signature with your information to the executable. In this case, Windows doesn't raise the Defender Smartscreen on its start.
I think you should disable Windows Defender SmartScreen: How to do it.
Also you can sign your .exe file in order to prevent Windows Defender SmartScreen from blocking your app.
I made a simple command-line based game in java, only two classes (using Eclipse). But I was wondering how I can make this into a usable application for anyone, without running it through eclipse (ie send it to someone who knows nothing about java but would still be able to play the game)? Thanks!
You want to create a runnable jar file.
Eclipse has an option for this in the "Export" menu. For more options, search for "executable jar file" here or on Google.
You want to make sure that you also include any jar files your code depends on as well (Eclipse can also do that for you).
Users will be able to start this by double-clicking on the file on most platforms. If you need better integration (such as a custom icon), you will need to bundle it up further into an OS-specific executable. But for starters, a simple runnable jar works fine.
send it to someone who knows nothing about java
You need to get them to at least install the Java runtime on their machine (if it is not already there).
Just to be clear, "command-line" and "knows nothing about java" are probably not going to work very well for you given that:
java is OS agnostic, therefore, if you send (presumably) a jar file to say...your grandma and she has a mac and you have a PC chances are her getting it to work is not going to be "out of the box easy" so to speak.
Left with this, I think you have a couple choices...first off, you do need to package your classes - a runnable jar will work fine. Aside from that, you will most likely have to build OS specific scripts (batch scripts for Windows, shell scripts for unix, etc.) and you will have to hand these out with your jar file. That being said, the intended user will still need to have java installed, and the batch scripts themselves are not likely to be trivial endeavors.
Your next option would be to use JNLP. However, I don't think JNLP has a command line mode, so you will likely have to simulate a console with something like a JTextArea.
As far as I see it, your last option it to use one of the many products (not sure if there are any free ones) that package java into native code. I think Exe4j is one such example - but, like I said, I am not sure if there are any free ones and I am not sure how hard they are to use.
Best of luck, and if you can't get your jar to work you should probably move that to its own question.
Since Windows 7 the directory windows/system32/drivers/etc is specially hidden. Windows 7 itself doesn't show it, but it is there if I open it manually.
Today I was playing around with a Java JFace Eclipse example (http://www.ibm.com/developerworks/library/os-ecgui1/) and was wondering that java also doesn't show the etc directory.
So how can I get all directories/Files, when using file.listFiles() ?
Any ideas?
The File.listFiles() method should include normal "hidden" files in the result. If it does not, it is because of something going on at the operating system level to hide the files from the application (and not just the user).
I could not find anything in either java.io.File or the Java 7 java.nio.* extensions that mention accessing "specially hidden" files.
It could be a privilege related thing ... and if that's the case the solution is to execute the Java application with elevated privileges.
But the simple solution is for your application to keep its nose out of the Windows drivers directory tree.
As I wrote, I played around with an JFace Example, that builds up a Java based Windows Explorer.
I agree with you, that a Java application should normally not do something in the Windows driver directory tree.
The "specially hidden" files there, are visible with other programs like Total Commander without running this programs with other then normal rights.
I assume, that Windows has some API functions to get that information.
I'm just interested in a Java based solution that can show me everything, that's on my disk...
I built a Java application that is delivered on USB sticks. To ensure compatibility, I ship an appropriate JVM on the sticks. I made an EXE that simply invokes this JVM with the application jar.
Now the problem: some virus scanners act aggressively and just remove the executable!
I tried an exe made with a "Batch file to Executable" tool and one written myself in C (invoking ShellExecute); both versions are detected and eliminated by Norton SONAR but I can imagine other virus scanners might react similarly.
I initially opted for a windows shortcut but these don't seem to support relative paths. A batch file is not acceptable either since I don't want the command console to be shown.
You could try using one of the many configurable java launchers - they may be less likely to be picked up by AVs:
NSIS
Janel
JSmooth
Launch4J
WinRun4J
(full disclosure: i work on winrun4j)
Use start/b java.exe ... in a batch file. There will be a short flicker but the window will quickly go away.
As for the virus scanner removing your file: Use a stick that has a hardware switch which can make it write protected. It's for your own safety: just because there is a virus scanner doesn't mean there is no virus. If no one can write to the stick, no one can mess with it.
If you launch your app using javaw.exe you shouldn't have an associated console window at all so that might get round the need to convert your bat file into an .exe.
You could also consider distributing your app as a Webstart app, whereby the associated jnlp file describes the minimum required version of the JVM.
Since the program won't have to change very often: Submit it as a false-positive to the AV vendors, then it will probably be white-listed quite rapidly. Or at least you might find out what it is that they find so objectionable.