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
We're designing an app that will run on Windows, OSX, iOS, and Androids. It would be really nice to at least have most of the code in a single language rather than having to use Objective C for the Apple versions, C# or C++ for Windows, and Java for Android.
We were looking at Flex (with all of its problems) as a way to avoid having to use a different language for each version, but Adobe has thrown in the towel and in the long run that's not going to do the job. Java used to promise to be universal, but it looks like Apple no longer supports it as a part of the distributed OS, and as far as I can tell Microsoft never supported it. We don't want our users to have to download and install something just so they can use our app.
Is there a solution? Or are we stuck with building the app in multiple languages?
HTML + css + JavaScript!
Run your app on a standard web server. All of the above have standards compliant web browsers, all of the above support JavaScript and AJAX. The only thing that really varies is screen size and this can easily be dealt with by using a custom .css file for each target browser.
You could host a web application on a server and use the app browsers to interact with the application.
Although not a native application, all devices would be able to use it.
The downside is that server connectivity would be required, however this may not be an issue.
"global" languages are most likely to use virtual machines, so you can't escape the "users have to have to download and install something just so they can use the app"... I think Java is your best bet if you don't want to deal with problems of languages that compiles into native machine code.
You could use C# on all those platforms:
"Normal" .NET on Windows
Mono on OSX
MonoDroid on Android
MonoTouch for iOS
(If you ever wanted to write an app for Windows Phone 7, you'd be fine there too.)
Of course the UI part will have to change significantly between different platforms, and I doubt that it'll be particularly seamless, but it's worth considering at least.
i am not very sure, but i have heard python is a universal language. I have tried this with both mac and windows, not sure about the other plactforms
I believe C++ code can be run on all those platforms: Windows has full support for it; Android has NDK; and you can use Objective-C++ on iOS (and I assume OSX as well!).
I wouldn't go so far as to claim it's the best option, but I figured it was worth mentioning.
Ultimately a lot will depend on the nature of the app you are developing. If it's a large app I'd strongly suggest doing some detailed consultation with someone with experience in the area: because of the vagaries of the different platforms, this is one area where experience counts for an awful lot.
There are multiple options, depending on your app requirements:
First, Web app, as many said before. It is the same as the greatest common divisor - very small
Second Build the core of your app in c/c++, and for the interface use a framework that fits your needs. These suggestions are really, really great. You can even develop the interface separately for each platform, in Java for Android, Objective C for iOS, etc
Do not forget that never, ever you will be able to make the same code run on all platforms. There will always be some part with #define MAC or #define ANDROID. It's just impossible to run identical code, even for the simplest app.
Unless is a
void main(void){}
Even a web app will have a code like
if(browser()==Safari) {}
else {}
I think the answer depends on what kind of app you are going to build.
If it's like twitter, a good web interface is the answer. Each client just need to handle the GUI work, with the platform's own language and lib.
If it's a game, no communication with server. I prefer C and a script such as Lua to build the core of your app.
"Is there a solution? Or are we stuck with building the app in multiple languages?"
No, no solution for this. We use different languages because they run in different platforms. Universal languages, such as HTML, have lots of constrains because to be universal you must cut all the differences. It is the intersection set of all platforms, which is very very small .
Using HTML and Javascript is likely to be the best approach. Another option which runs on these platforms is Java FX 2.0.
Is it possible to use OLE Automation in Java? If not, why is it not possible in Java?
I'm looking to automate the exporting of excel spreadsheets in different format (ie, .csv etc...)
Thanks for the answers in advance :)
Recently (March 2013), an independent contributor added support for generic COM Automation to JNA, which is the last man standing in terms of native platform API integration from Java. JNA is still very actively maintained, unlike Jawin/JACOB/etc.
See here for an example of how it is used. The pre-cooked bindings to the Office APIs are very simple so far, but looking at the code, it seems very easy to use the COM Automation APIs (IDispatch, Variant, etc) to do late binding to almost any COM interface.
I would like to see, however, a more complete binding of the Office COM APIs, since they are by far the most often used COM API in the world. Maybe there could also be an "MSExcel2007.java", "MSExcel2010.java", etc. to cover the different API versions. So it's very much a work in progress, but JNA is now as generally useful for COM Automation as JACOB/Jawin, with the bonus that it's extremely actively maintained (as of April 2013).
You can use JACOB. But there will be some pain involved as it's not documented very well and the performance is not the best. It can also be hard to get it running correctly for you environment depending on which version of Windows you are targetting. I would definitely not use it if you are building a scalable web application. Another option would be Apache POI which has really come a long way from its early roots and is used in alot of production ready tools like JBoss Drools. If you decide to go with JACOB then I recommend you read this SO thread:
Is there a good reference for using OLE Automation (from Java)?
There is a library called JACOB that allows precisely what you're looking for. What do you mean by "from the Java API?" You mean from from the official J2SE packages? I'm not sure how to answer that other than to say that J2SE doesn't include libraries for every conceivable need under the sun, especially those that only work on a single operating system. That's why third party packages exist.
Commercial, but they seem to have a free Open-Source and Academic license...
JExcel
JExcel Developer Documents
I have no affiliation.
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.