I would like to read RPMs of the (Windows 7) system fans in Java (like, for example, the application SpeedFan does) to use them for an Arduino based LED project (make fan appear slowly moving by PWMing leds). However, the system has a fan controller so I have to read the rpm continuously. Found nothing after Googling, only a tutorial of how to read the RPM directly from the yellow wire on an Arduino (however, this is not a solution, because I wouldn't like to do hardware modifications on the system itself). Anyone got ideas?
I think best solution is using JNI or JNA. With it you can use all WinAPI functions, as a result you can get all info what you want. If in the future you'll want read another system info you already have base structure, it's good scalability.
Also you can try find third-party program and get needed info from it, but it's bad idea because maybe in the future when you'll setup another version your third-party program maybe will not work.
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 would like to get the path to the working directory of a specific process (for example for the PID of the process). I am Not Talking about the working or current Directory of the process where my Java Code is running. Its a simple task with Linux, but for Windows i cant find a proper solution. Furthermore, it would be nice, if its a Command or a Framework for Java, because i will need the path in my Code. I am not looking for the path to the executable, also Not for a solution with wmic or process explorer.
Already thanks for the help.
I already tried commands like tlist and wmic, but those solutions cant be utilize in my code. I am looking for a solution that i can use without special installations on Windows.
JNI and JNA provide means to call directly into native libraries from Java code, and it is feasible to use these to call out to Windows libraries.
There is a github project that appears to be close to the need: https://github.com/kohsuke/winp. Perhaps you can add the needed code and send up a pull request, or fork the project.
Note that any solution here is going to be windows-specific, meaning the application using it will not run on another platform. Given the nature of the question, that doesn't sound like it would ever be a concern.
I read SO q&a about launch java as windows service wrappers, but can't find/choose product, suitable for my requirements :
Wrapper reads all java launch parameters from config file. In registry must be only commands to run wrapper itself - path to exe and maybe path to config. Always grant admin rights to change app parameters in registry is not comfortable.
Working dir and path to application also must be in config. I want to place all wrapper files deep into program, because user not intrested in it.
No dependencies(.net, python, etc). I don't want to extend requirements of my program.
Free for every windows OS, include win64.
Simple and lightweight. Size of my program with all 3rd party jars is 12Mbytes. I don't want to add 20Mbytes wrapper.
Automaticaly restart if app process dies.
Preferably single exe files for all windows platform.
I try and lookinkg throught different wrappers and tired a bit. Best suitable till now is:
jslwin (http://jslwin.sourceforge.net), but i don't know how mature it is(version 0.99). Also parameter lists in config is a bit complex(need to edit parameters quantity).
winrun4j (http://winrun4j.sourceforge.net), but i don't know how mature it is(version 0.45). Also it needs a special class for working as a service.
Also i try or look throught:
YAJWS (http://yajsw.sourceforge.net/) too big (30mb), can't make it work with custom files layout.
Advanced Installer (http://www.advancedinstaller.com) too big (50mb).
nssm (http://nssm.cc/) store launch parameters in registry(no config)
winsw (https://kenai.com/projects/winsw) .net required, stops after process dies
commons-daemon, procrun (http://commons.apache.org/proper/commons-daemon/index.html) store launch parameters in registry(no config), can't understand this product, i think it's complex.
jsmooth (http://jsmooth.sourceforge.net) complex and old(last update 2007)
javaservice (http://forge.ow2.org/projects/javaservice/) old (last update 2006)
runasservice (http://runasservice.sourceforge.net/) requires .net
windows rktools - sc, instsrv, srvany (http://support.microsoft.com/?scid=kb%3Ben-us%3B137890&x=16&y=7) - store launch parameters in registry(no config)
jwrapper (http://www.jwrapper.com/) seems not what i need. It packs java program in exe file with JRE. It's not about windows services.
firedaemon (http://www.firedaemon.com/) not free. And maybe it's not what i need.
launch4j (http://launch4j.sourceforge.net/) cool ability "search or download java". Maybe i add something like this to simplify installation, but it is still not about subj.
Java service wrapper (http://wrapper.tanukisoftware.com/) not free for win64.
Tell me please which wrappers suits my needs? Or maybe i think wrong about wrappers above and some of them suits my needs to?
I have had similar issues over the years. Its not that they all are inferior, its that they are all pretty hard to integrate nicely with your own project.
You may want to check out stork: https://github.com/fizzed/stork
It'll help create launchers for your Java console or daemon apps, and they will work across all major platforms. There is also a maven plugin in case you wanted to tie it into your existing build process.
I'm not sure if JWrapper will fulfil all the requirements like 1 and 2 in the way that you want it since rather than you dictating how it does the launch and where it puts things etc JWrapper instead handles that stuff in its own way but it does produce executables for win/mac/linux and more importantly it does support windows service installation as well as macos and linux daemon installation:
http://www.jwrapper.com/guide-installing-a-service.html
The service support though is for paid licenses, the free version doesn't currently support it.
Disclosure: I work for JWrapper
I have recently found out that anything Swing(NetBeans, IDEA) is excruciatingly slow to paint the UI over Remote Desktop(RDP).
Can you guys give me any suggestion for something that will work properly over RDP?
Actually, contrary to everything I've seen - mostly the "Dsun.java2d.noddraw=true", which is mentioned in a number of places, it is actually setting it to false that fixed the drawing issues(for me at least). Go figure.
RDP is optimized for native Windows apps and, regrettably, newer versions of RCP (like Vista/Win7's default RDP) is even more hostile to non-native apps than older (XP/Server 2003) versions. Here's a good link:
http://devnet.jetbrains.net/thread/280673
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4204845
One workaround is to get a screaming fast CPU/graphics board, tons and tons of memory and a super high-speed network connection :)
Another is to:
Select "32-bit true color" in your Terminal Services settings
Select "Modem"
Reduce screen resolution (heck, use 1024x768 if possible)
Here are some additional tips:
http://www.codinghorror.com/blog/2006/04/remote-desktop-tips-and-tricks.html
Try setting "Dsun.java2d.noddraw=true"
http://ubuntuforums.org/archive/index.php/t-1129187.html
http://www.mindfiresolutions.com/Solving-DIRECT-DRAW-ddraw-problems-in-Java-Swing-730.php
I am launching a java swing application from Linux, and display it as a Windows frame thanks to MobaXterm.
If you haven't done it already, please have a look at the following documentation :
https://docs.oracle.com/javase/8/docs/technotes/guides/2d/flags.html
Using -Dsun.java2d.noddraw=true did not fixed my issue, but setting xrender to true did.
So here's the code I used on Linux :
export _JAVA_OPTIONS='-Dsun.java2d.xrender=true'
java -jar my_java_application.jar
Maybe it's not only Swing that paints slow over Remote Desktop. However, Eclipse is based on SWT, based on native widgets, so it is not Swing.
You should give JavaWIDE a try. It is an IDE designed for access to a JDK without it installed on a system, with a built-in storage system so you just need access to the internet. It's not exactly a program for accessing everything on the computer but it will do a good job with your programming. It may take a while however, as the compiling is done on a separate server.
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.