Is there a way to get the location of an installed application without searching through the file system?
EDIT: Sorry for not making the question clear enough, What i am trying to is like figure out where firefox is installed from within an java application. I would like to initiate an install for an extension.
EDIT: Firefox has a registry key in HKLM\Software\Mozilla\Mozilla Firefox\\Main\InstallDirectory key. There is also a CurrentVersion key in that same HKLM\Software\Mozilla path that you can get the version number from.
On Linux you can use Runtime.exec() to call the which system program, eg which firefox would return something like /usr/bin/firefox. This won't work on Windows, and unfortunately doesn't appear to work on OS X either, despite it being UNIX-based.
The only way to do this on Windows is via a registry read. Jeff Storey's post has the reg key you need. As for doing this from Java, my original response was going to be: you can't without using JNI.
But then I did some googling, and found this library
The approach is a bit novel b/c it involves accessing parts of Sun's implementation of the Preferences API that aren't generally available. This is, certainly, not going to be compatible for different JVMs, and could break as Sun's JRE evolves - but... well - I'll bet it would be useful for at least a couple of years, maybe longer. And it's a lot easier than writing the JNI yourself...
Related
I have a java application (tomcat-app) using a JNI connection to a C-library in the background. In a very random way this java application crashs. I saw in the system events, that is crashed based on ntdll.dll, which is a system library in Windows/System32.
Can somebody tell me, what functions ntdll.dll offers, for what is it used for and why java needs this ntdll.dll?
I have used Google for finding a solution, but this crash can occur on nearly all Windows-Systems, i combination of a lot of applications (it seems that it is not just a windows-java problem). The standard solution was to reinstall/update the system and/or applications. But is there an explication, why this ntdll.dll makes so much trouble?
Do you think, that it would help, if i put a ntdll.dll in a higher version into the java directory or the directory of the c-library, so that java or c-lib can take this newer version, instead of the Windows/System32-version?
Thanks a lot for your advices.
ntdll is a low level windows system api which provides hundreds of windows api functions like memory management, loading DLLs and system-exceptions.
You must not use a different version than the one on your system as it is tightly coupled / integral part of the windows operating system version you are running on.
Without further information it is hard to tell what the problem might be, but maybe you are using an incorrect calling convention in the JNI wrapper which leads to an imbalanced stack.
It seems, that the JNI calls were correct (we have used an external library, which has used JNI). Furthermore we have found a workaround for this problem. A functional update of Windows has raised the version of ntdll.dll. This has solved the problem; crashes of java.exe never appeared again.
I'm writing java swing app. I need my app connect to server CentOS 5.5, using username + *.ppk file (I don't have password). Then, my app execute some command line on this server.
Is this possible ? What library is best for it ?
There is a number of libraries that support what you're trying to achieve in different ways.
Connecting to an SSH server via Java is no big thing anymore these days.
Those are some libraries that you might consider:
Ganymede
http://www.cleondris.ch/opensource/ssh2/
Ganymede was made by some students at the ETH Zurich and works quite well. I personally use it in a project that runs on a very old machine using Java 1.3. It doesn't require anything besides a JRE. It is, however, not very active anymore. There is that company that seems to support it (Cleondris), but I wouldn't know how reliable they are. Doesn't matter much though since it's open source anyways. If you need to run your app on old java versions or need to know, that your app runs withou the Java Cryptography Extension (JCE), you could chose this.
JSch
http://sourceforge.net/projects/jsch/
JSch too is a mature piece of software and just works. If you've ever used ant to do SSH/SCP related tasks, you probably know it already. It's always a bother since you have to provide it to ant manually :-)
The project is well maintained, as it seems and widely used. I used it in a lot of modern UI/Batch applications and was/am always happy with it. It does use JCE though and I did once experience problems with that (on an older JRE, but still). If you plan to distribute your software to clients unknown to you, this might be a problem. JCE needs stuff installed / configured inside the JRE installation itself. Probably works 99% of the time, but still...
SSHTools
http://sshtools.sourceforge.net/
Never used this one but heard good things. May be worth a try.
Converting ppk to OpenSSH format using Java
As this is obviously possible, it's only a matter of implementing it. Fortunately for you, there are actually multiple implementations around. It might even be implemented in one of the suggested SSH libraries, but I didn't check.
A quick google search revealed two choices to me:
trilead-putty-extension
https://github.com/kohsuke/trilead-putty-extension
Seems to me like a very nice choice. Even though it's an extension to Trilead SSH library (which, it seems, isn't available anymore), it's not a lot of code and could easily be integrated into an existing project. There is one class that does the work and can convert a ppk key into a openssh one. String to string, so no surprises there. Should really be a piece of cake.
I don't know what happend to Trilead. The company doesn't mention it anymore on their website, but it certrainly existed at some point (http://techtavern.wordpress.com/2008/11/13/about-trilead-ssh-open-source-project/).
By the way: The guy who wrote it is the one who also wrote Jenkins/Hudson. http://kohsuke.org/
"ChillKat" Java Library
http://www.example-code.com/java/ssh_ppk_to_pem.aspn
Well... this just as an alternative. Doesn't seem worth the effort and overhead to download a "multi-purpose" library just for that. You could maybe extract the relevant parts or let yourself be inspired by it. Maybe the trilead extension doesn't work and you have to pick this one, but I wouldn't consider it first choice.
You can of course always convert the .ppk file manually, as explained here: http://www.lmolnar.com/geek/how-to-convert-puttys-private-key-ppk-into-opensshs-private-key-format-in-linux/
And other places, I guess. There is the graphical tool puttygen too, which is included in putty-installer or downloadable standalone via the putty website (http://www.chiark.greenend.org.uk/~sgtatham/putty/).
Would you like to know more?
Check this: http://linuxmafia.com/ssh/java.html or write a comment.
If converting the .ppk to a less proprietary format (i.e. .pub rsa or dsa) is an option, then give a try to puttygen (usage: "puttygen keyfile.ppk -o id_rsa -O private-openssh") from the putty-tools package.
Then use SSHTools, a java API for SSH (and more)
One of options is to use SSHBlackbox package of our SecureBlackbox product. It supports loading of Putty keys and full scope of SSH-related functionality (SFTP requires SFTPBlackbox package). SecureBlackbox comes with extensive samples and support.
The current JSch version does not support *.ppk files,
but JSch can use those files by using jsch-agent-proxy via Putty's Pageant.
Install and open puttygen
Click on "Load an existing private key file"
Click on menu item "Conversions" -> "Export OpenSSH key"
Save file, and use this in your Java app
I want to replace the current Java process by a new one just like the Unix exec does. There has been already a similar question here, but I'd prefer a solution consuming as few memory as possible (the accepted answer suggest to use ClassLoaders, which could lead to memory leaks; a similar simple solution would be to use another process just to start the proper one). It can be surely done in a platform-dependent way using JNI, and I think I can do it for Unix (and a solution for Unix seem to already exist), but I know nearly nothing about the corresponding Windows API. What Windows function should I call? Has anybody done it already?
With Windows there are many subsystems to choose from that run on the base OS, so it helps to have some sense of what you are aiming for. For example, if you can use the C run-time library then you can just use the _exec() family of functions which are very similar to their unix cousins. Perhaps you can modify jniexec to work with windows using these.
The Win32 API doesn't include the concept of 'exec'. THe POSIX API does. The low-level WinNT API has the building blocks, but it's quite complex to use them, and, at least in the past, required recourse to undocumented functionality.
How can I retrieve a hard disk's unique ID using Java+JNI on Linux, Windows and Mac?
To sum it up: you can't do this with just Java
I do not think there is a simple, uniform way to do that.
You can however create seperate logic for all cases; on linux you could check /proc (using the java.io package). There are probably similar ways on OS X and Windows, or, if not, you could execute a shell script or batch file on these systems and parse the output.
Or you could use JNI, though that would mean building your module for all environments.
You could use Java+JNA (https://github.com/twall/jna/), but then you'd have to figure out how to gather that information by using native libraries on each of the platforms you'd like to support.
The benefit is that you wouldn't have to compile any C/C++ code for each of the platforms. If you decide to go with that option someone else might be able to tell you how to figure out the harddisk IDs on the different platforms using C/C++ code/libraries.
AFAIK, on Linux you need to read something from /proc or /sys, on Windows I would look through MSDN and see what you could find that is usable in Visual Studio (C++) and for Mac someone else would have to fill in. Solaris/BSD should probably be supported too if you do it right. In fact, for most of the POSIX-compatible OSes out there I think you should be able to do it somewhat uniformly.
As already in indicated, you can't within the boundaries of the question. However, you might be able to do it with a combination of java and native code specific for each platform via the JNI layer.
I may be wrong, imho, this canNot be done without using JNI.
Build your app in two parts
Native component that will use either a script/application to query the hardware, and output to a file
Your java app to read from the file and do whatever
We run batch files on our OpenVMS Alpha and Integrity servers. Up until now they have been written in COBOL. As you can imagine there are many reasons why will not be able to maintain that process.
At the same time we have a team of developers that use Eclipse and know Java very well. Is there away to use Eclipse with OpenVMS?
Maybe it's because I don't keep up with COBOL, but I am not sure why you're convinced you have to abandon it. I realize it's not the "in" thing, but if you already have a large code base I'd think at least twice before switching to another language. If it's a lack of developers, I don't think you're going to run out that soon.
That said, googling Eclipse & OpenVMS gave this link:
http://www.sdtimes.com/SearchResult/32973
So it looks like you can still get Eclipse for OpenVMS from eCube. If I'm reading that article correctly, HP seems to want you to go the NetBeans directions. Personally, I'm still using Emacs (and not currently doing any Java), so won't make a recommendation; I just wanted to point out that there are other ways to develop Java than Eclipse.
I didn't find Java for VMS on Sun's site (someone feel free to correct me if you find it), but it looks like you can get the JDK from HP/Compaq at:
http://www.compaq.com/java/download/ovms/1.5.0/index.html
Edit: I meant, but forgot to say: Assuming you're using a JVM on the VMS side, you should be able to development with Eclipse on another platform, and copy the byte code to the Alphas.
Speaking from experience, if you do decide to rewrite your batch processes in Java I'd suggest you use a third party batching framework like Spring Batch instead of 'growing your own'.
Using a framework also constrains you to work within a standard and should provide non-functional requirements like re-runability, transactions and error handling.
We've (re)built a number of batch processes from various technologies to Java using a home-grown framework and I find we end up spending time on fixing/optimizing the framework rather than just focusing on the business logic.
Don't leave Cobol yet - call a-cobol-programmer-thinking-about-switching-to-the-modern-world and make a trade: you teach him Java, He maintains your legacy.
Shell scripts and java usually aren't a great mix. You may want to consider installing a JVM on your VMS servers, and using one of the JVM-hosted languages that handle that case better- jython, jruby, or groovy might be candidates to consider.
Eclipse relies on native Java extensions that do not appear to have been ported to OpenVMS. Don't give up though. Java runs on OpenVMS (at least 1.5 according to a Google search).
NetBeans has a Java only edition that should work on OpenVMS. On the NetBeans Download Page select the OS Independent Zip option for the platform.
Are you running the batch files on your OpenVMS system? If so, HP makes Java available for OpenVMS, not SUN; you will have to look at their site. You can develop your java code on a windows/linux machine and test it on your VMS system; you must be aware of the native extensions that you cannot use on the VMS implementation of Java.
Speaking with some experience in this area, I suggest developing with Eclipse on your Windows/Linux/Mac desktop, and pushing the code out to OpenVMS for testing/deployment. Eclipse won't run on OpenVMS because of some platform-specific components of its GUI.
Some caveats:
Make sure that you are using the same version JVM on your desktop as on OpenVMS.
The case insensitivity in OpenVMS can be a problem when using inherently case-sensitive Java .class files. Package everything in a .jar and deploy it that way.
The attributes on .jar files have to be set correctly or the OpenVMS JVM can't open them. The following command should do the trick:
SET FILE *.jar /ATTR=(RFM:STMLF,RAT:CR)
HP provides both a "fast" JVM and a "classic" JVM. Use the fast VM unless your memory needs are highly variable.
I realize this question is rather old, but I was shocked nobody mentioned this book covering Java on OpenVMS.
https://www.theminimumyouneedtoknow.com/java_book.html
What really matters when using an x86 editor on OpenVMS source is your file transfer software. OpenVMS (and many other midrange ASCII based platforms) use even though most PC developers say LineFeed Carriage Return, the data files typically store it in the other order.
You can read much more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/most-text-editors-get-tabs-wrong/
Your file transfer software will need to perform text mode file transfer changing the line ending characters OR your editor needs to both use and respect the better systems line ending characters. I thought there was something in Eclipse (via plug-in) to handle this. Notepadqq claims to have something.
Note this: They use Eclipse for development, not just editing.
That means they are running and debugging in their own PC based Eclipse universe and that ain't how it's going to work on OpenVMS. They are going to need a terminal into the VMS system and it needs to be a REAL VT-100 terminal emulator, not the worthless free stuff. You can read a little bit more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/diamond-edt-keypad-support/
and here
https://www.logikalsolutions.com/wordpress/information-technology/xterm-and-vt-emulation/
Depending on how old your system is, you might have Pathworks installed and running. Then a system manager can create a directory for each user that they can map as a network drive to the PC. This lets the PC user use the directory like any other network disk and it generally could be configured to handle the line ending issues with text files.
There is no way they can develop on OpenVMS using Eclipse. They can edit files then test on OpenVMS, but they cannot develop within the IDE which I suspect is what they really want to do.
The only GUI that ever existed for OpenVMS was DECWindows. You had to run it on either a VAXStation or a DS model Alpha workstation. I never heard of Eclipse being ported to it. In the latest port of OpenVMS to x86 there is no GUI. It is a server only OS.
Yeah, I spent two decades on the platform and even wrote this book for it.
Yes, there is a version of Eclipse that supports OpenVMS called NXTware Remote. It has support for Java and COBOL languages as well as Fortran, Basic and Pascal.
You can edit OpenVMS files using pretty much any editor, including Eclipse - just use Samba to make OpenVMS directories and files visible to desktops on the network. If you install Java for OpenVMS, then you've got folks using Eclipse, and compiling and running on OpenVMS.
As for ditching Cobol - why? There's still a ton of companies running it, and it will certainly last for decades more.