icmp4j

This library is simple. I like that. The only issue I have is minor, and a semantic one. Instead of getSuccessFlag() returning a boolean value, I'd recommend a method called isSuccess(). Actually, not INSTEAD; IN ADDITION TO (no need to break backward compatibility, eh?)

Hello everybody - this is a response from the author (shortpasta) to ashegoulding. You seem to have taken a good look at our library, but it also seems that you were a little drunk when you did that! I find your post comical and entertaining, so I will address your "points". 1. "Raw sockets in Windows": In Windows, the old version called shortpasta-icmp uses raw sockets, and icmp4j uses IcmpSendEcho. You can decide which to use. 2. "The library uses the ping executable": Wrong - as documented clearly on the website AND the sf.net Features section right on the home page, this library uses JNA for Windows, and the ping executable for all other platforms. As of build 1019, this library has native implementations for Linux, Mac, Solaris, and Windows. Plus this is open-source, so you can look under the hood. 3. "lib just doesn't work in such cases like output language is not englush": many of us did test several languages, and it works very well and on many platforms/languages. Plus we have found out that not only the text changes, but also the punctuation. So we were very careful about this... Also, this is documented. But since we have native implementations for all supported platforms, this is not even an issue. 4. "IcmpPingUtil.executePingRequest() as synchronized method": it is for Windows JNA implementation only, and for a very good reason which is documented right there in the code. It seems to me this is a pretty simple and smart way to handle the problem when you consider various possible solutions. When we eventually figure out how to deal with this properly (or some other kind soul does and reports the fix back to us), the synchronized will go away. 5. "AsyncCallback one, but it has its own problem with the garbage collector": If there is a real issue here, report it for everybody's benefit - we fix things very quickly. 6. "NativeBridge thingy which is not that feasible": I am not sure that you are seriously criticizing this, but this is called "Interface-based programming". Try googling it, and even better, try using it... Having said the above: 1. For every point you bring up, I invite you to realize the value of what was done and why. We do things with reason, and we document those reasons. 2. Your comments indicate that you completely disregarded our website [1-page BTW :)], sf.net Features documentation, and code-comments. We have been up-front and transparent on everything from day 1. 3. If you (or anybody) have a real issue with something, we will provide answers. Also, if anybody has a better way to do something, tell us... we will strongly consider it. 4. By build 1019, the "NativeBridge thing" that you don't understand, has several implementations including Windows native via JNA, Windows via the ping executable, Linux/Mac/Solaris native via JNI, Linux/Mac/Solaris native via JNA, Linux/Mac/Solaris via the ping executable, Android via the ping executable, and any platform via isReachable (). And if these are not good enough, you can always write your own implementation. 5. The 1019 version is distributed non-packaged (so that you can use only the files you need), and packaged as icmp4j-all.jar, which handles all platforms in a single jar. If you don't see why this is beneficial, read-up on it before posting. 6. Lots of other good folks have helped to fix and improve this library 7. This library remains the best implementation for the money out there as of today, Feb 3 2016. If anybody can claim otherwise, let us know and we'll bow our heads! 8. A lot of work has gone into this, and the library is used by a lot of individuals, .edus, orgs, companies, and so on. You are not forced to donate to it, and because you cannot back your statements, while on the other hand we can, you should not warn others against using it and donating to it. In conclusion... your comments are out of line, not constructive, and ultimately value-less to anybody trying to do their job. I could have dumped your post, but in a way it was funny, so why not let others laugh too? ;) Next time you post, I hope you contribute with constructive criticism that benefits everybody so that we can all ping together... Good night everybody! -- shortpasta To keep everybody honest, here is the original 1-star review, posted by ashegoulding on 11/25/2015: [ Never, ever consider to use this (s word)! I wouldn't give even one star, if i could. It uses raw socket in windows, and works fine. I'll give you that. But other than that, all the other platforms, it is just some child's prank. Like many other attempts to "ping" in java, this library is just a set of ping command parser. They made IcmpPingUtil.executePingRequest() as synchronized method... Hence no thread-safe blocking call of that method. You must use the method with AsyncCallback one, but it has its own problem with the garbage collector when used with the same AsyncCallback instance overtime. Mentioned about this being just a set of parser. Yeah. If the ping command output is different from the "general one", this lib just doesn't work (in such cases like output language is not englush, simplified versions in embedded systems ...) You (s word) could have made output filter using regular expression to filter out in those peculiar systems, but you made this "NativeBridge" thingy which is not that feasible. You want the other to implement their own "NativeBride"? so others can suffer that pain from coding? Putting "IT IS JUST A PARSER, DUDE" sign in your page was that hard? You explained this util like it uses some magic to ping across the platforms and you want for donation? If you are planning to use this in unix-like, don't and just parse the command in your own taste. DO NOT WASTE YOUR VALUABLE TIME ON THIS NON-SENSE. (…less) ]

Never, ever consider to use this (s word)! I wouldn't give even one star, if i could. It uses raw socket in windows, and works fine. I'll give you that. But other than that, all the other platforms, it is just some child's prank. Like many other attempts to "ping" in java, this library is just a set of ping command parser. They made IcmpPingUtil.executePingRequest() as synchronized method... Hence no thread-safe blocking call of that method. You must use the method with AsyncCallback one, but it has its own problem with the garbage collector when used with the same AsyncCallback instance overtime. Mentioned about this being just a set of parser. Yeah. If the ping command output is different from the "general one", this lib just doesn't work (in such cases like output language is not englush, simplified versions in embedded systems ...) You (s word) could have made output filter using regular expression to filter out in those peculiar systems, but you made this "NativeBridge" thingy which is not that feasible. You want the other to implement their own "NativeBride"? so others can suffer that pain from coding? Putting "IT IS JUST A PARSER, DUDE" sign in your page was that hard? You explained this util like it uses some magic to ping across the platforms and you want for donation? If you are planning to use this in unix-like, don't and just parse the command in your own taste. DO NOT WASTE YOUR VALUABLE TIME ON THIS NON-SENSE.