communication of devices using serial port in java - java

How to do this kind of communication?
What libraries are available?
How is the data seen as bits?

Serial on Java is a bit tricky to get started, but once you've got it up and running, it's quite straightforward.
Serial is not implemented in a uniform way on different OS's, so Sun's approach was to develop the JavaComm specification and a reference implementation. For better or worse, Sun appeared to lose interest several years ago, and dropped Windows support in 2005.
So, the reference implemetation has largely been 'superceded' by a project called RXTX. RXTX works with Windows, Linux, BSD, Mac etc, so this is normally reason enough to use it.
Both these implementations require use of a native library (.so or .dll), which needs to be installed & configured in a per-platform way.
See this link for a balanced introduction, including code samples:
http://en.wikibooks.org/wiki/Serial_Programming/Serial_Java
Here is the RXTX project: http://rxtx.qbang.org/wiki/index.php/Main_Page
HTH
Edit: in answer to your final question, the javacomm SerialPort class provides getInputStream() and getOutputStream() methods, so you can use these as you normally would in java.io

Java Communications API.
Starting here might get to you info you need:
http://www.oracle.com/technetwork/java/index-jsp-141752.html

Related

Platform-Independent Java <-> C# Interoperability

We want to use existing C# sources within our Java project. So far, this would not be a great problem since using e.g. Java Native Interface (JNI) is quite straight forward.
The problem is that the software shall also run on non-windows OS. So, we can compile the C# sources with Mono in order to make them executable on e.g. Linux. But how about the integration within Java? JNI or any COM-based solutions for C# <-> Java interoperability are OS-dependent and only work e.g. on Windows.
One possible solution would be the implementation of webservices. Has anybody another idea of how to solve this problem? I would be very thankful for alternative suggestions!
Thanks very much!
Regards
This is maybe not an "answer" as such, more a bit of discussion of how I viewed a similar (I think) situation.
I had a major investment in a C#/.Net-based client-server style system. So when I decided that I also wanted to support an Android "client" app I looked into various options. To me the most important factor was to maintain my C# classes as the defining classes for the object interchange between the existing system and the to-be-written Java Android app.
What I eventually settled on, and tweaked to my liking, was a system where Google Protocol Buffers is the interchange media. (If you're not familiar with them they are a sort of JSON-like interchange format.)
https://developers.google.com/protocol-buffers/
At the .Net end I use ProtoBuf-Net, written by Marc Gravell (he works here at SO, I believe). It includes the ability to take .Net objects and generate .proto files, the defining file for Protocol Buffers.
https://code.google.com/p/protobuf-net/
At the Android end I use ProtoStuff, written by David Yu. There is a part of his code that takes a .proto file and generates the corresponding Java classes.
https://code.google.com/p/protostuff/
One problem I encountered was that this didn't work well for my .Net classes that are derived classes, which was most of them. I created a workaround that is described in my comment to the answer here:
How to get protobuf-net to flatten and unflatten inherited classes in .Net?
This is now working to my satisfaction.
Note that I haven't talked at all about how the Android app connects to the Windows-based system and how the communications is performed. That was secondary for me - my primary consideration was making the C# class definitions the definitive definitions and having Java classes created from them automatically, and then the object-to-object interchange. (In the event I'm using a home-made TCP/IP communications link, but the actual communications could be anything, probably also web services.)
Hope this helps.
So I did a lot of research on this topic and want to share my findings with you:
One (from a technical point very attractive) option is to use commercial bridges between Java and .Net. For sure, the most popular products are JNBridge and Javonet. Both products seem to be quite easy-to-use, have good support and seem to be very sophisticated. Especially JNBridge already supports bridging between Java and Mono too, which allows the portation to also non-Windows OS, which is one of our main requirements as stated above. Javonet also wants to integrate Mono and is going to release this feature soon. However, both solutions are commercial and one needs to weigh their features against the respective costs. Nevertheless, from a pure technical point of view, they look great and also state to enable very fast communication between Java and .Net (faster than with web services).
Another option is to connect Java and .NET via COM. Since COM is generelly defined platform-independently, this could work on multiple OS. There are lots of open source projects that could be used for such an implementation, such as EZJCOM, J-Interop, JACOB or JCOM. The main restriction (expecially for our project) is that Mono only supports COM-interoperability under Windows (yet). So, this is not really an option for us. But if you want to create Java-.NET interoperability on Windows only, this is a good way.
The straighforward way of integrating Java and C# is to use Java Native Interface (JNI). You can also find manifold implementations that make JNI more easy to use, the most popular one is probably jni4net which seems to be a very active and frequently used project. But there are also others with specific pros and cons, such as Caffeine, Espresso or csjni. Finally, JNI is not 100% platform independet. It is applicable on different platforms, but you have to generate platform-specific code which makes it clearly less usable for our purposes. If you limit your application to Windows, jni4net seems to be a very good choice.
The third option could be to run both the Java and the .Net part within a Common Language Runtime. Ikvm.net is one possible and very popular solution therefore (as mentioned above by Samuel Audet). The drawback of this option is the loss of features and efficiency of the JDK.
The last and surely most generic alternative is to set up webservices between the Java and the .Net world. For this solution, one needs to find appropriate ways for serializing/deserializing objects from/to Java and .Net. There are manifold possible solutions for that available. RenniePet mentioned a sophisticated solution based on Protocol Buffers. Others exist as well such as http://java-cs-bridge.sourceforge.net/. This option might have a potential drawback when considering communication runtime, but may be the way to go for us.
Hope this may help anyone in the future that is confronted with the same problem.

can we detect the unique serial no of USB Pen Drive in java? [duplicate]

Looking for a way to read the unique ID / serial# of a USB thumb drive;
please note that
- I am looking for the value of the manufacturer, not the one Windows allocates for it.
- I need to support multiple OS (Windows, Unix, Mac), thus needs to be a Java solution
The idea is to be able to distinguish between different USB thumb drives.
RXTX is the way to go. In the world of model trains, JMRI (Java Model Railroad Interface) has become very popular. JMRI runs on all platforms (Windows, Linux and Mac) and communicates with a variety of USB based devices (command stations). RXTX is in fact used by JMRI.
You might give a look at the following projects:
javax-usb and jusb. They seem to support Linux and Windows.
Anyway, since USB access in Java requires the use of native libraries, you might not achieve the required portability.
I've never tried using it (it's been on my todo list for a good few months now), but there is the "marge" project on java.net:
http://marge.java.net/
This should let you connect to bluetooth devices (although I don't think it is 100% feature complete, there is demo code on there), and then the ClientDevice class has a "getBluetoothAddress" method which I believe should be unique to that device
http://marge.java.net/javadoc/v06/marge-core/net/java/dev/marge/entity/ClientDevice.html
As I say though, I've never tried it...
I have never investigated this thoroughly, but from memory the RXTX library implementation of the javax.comm packages are supposedly very good and now have USB support.

java p2p video library?

is any such library available either commercial or open source?
Just wanted to update this thread and note that we've created such a library at Frozen Mountain; it's called IceLink. The server portion (STUN/TURN, which is used for NAT traveral and IP discovery) is available on Java (in addition to .NET, Mac, etc) and there's a full Java library implementation for the actual P2P communication and audio/video encoding/decoding/rendering. It's also WebRTC-compliant, and communicates nicely with Chrome, etc.
We've released out VP8 Java wrapper as well: https://jvp8.codeplex.com/
(Disclaimer: I work # FM).
After google searching this a bit as well as from my experience, I don't know of any. If you do find one, I would probably also wonder about its fidelity. Maybe it would be a good idea for you to start your own open source project for this.
As of today, there is no such open source library.

is there a "best practice" to access another process in the OS through java?

I've been reading Skype4Java (java api for skype) and noticed they use jni to access the skype client.
intuitively I'd assume that there already is a standard library in java that has an OS-sensitive jni implementation to access other processes. I set up to look for one, but couldn't find it.
Is there such a library? if not, is there a best practice to access another process in the os, not necessarily a skype client?
From Java 1.4 onwards you can use memory mapped files to exchange arbitrary information with another process. See java.nio.MappedByteBuffer for details.
I think that maybe you need to define what 'access' means to you. IF you are talking about plain old inter-process communication, then sockets or JNI are really your best bet.
Garth's comment about using memory mapped files is interesting - I've used MMFs and virtual files for IPC between C applications many times, but it never occurred to me that Java's MMF implementation might be compatible with the native OS virtual file system. These kinds of virtual files usually require non-trivial setup, so I'd be surprised if it would work...
All said, unless you are pumping massive amounts of data between apps, using sockets is probably the most universal and effective way of doing it. Be sure you account for endianness between the host OS and Java VM :-)
This is not quite what you're looking for, but will probably help a great deal nonetheless: the Java Native Access project on java.net.
Don't forget sockets...

Is .NET a write once, run anywhere (WORA) platform like Java claims to be?

I remember Sun's slogan so vividly... "Write Once, Run Anywhere". The idea being that since programs are compiled into standard byte codes, any device with a Java Virtual Machine could run it. Over the years, Java seems to have made it onto many platforms/devices.
Is this the intention or was it ever the intention of .NET. If so, what kind of efforts are being put forth to make this a reality?
To correct some comments by others here, .Net was ALWAYS intended to be multi-platform. That is why Microsoft separated the namespaces into "System.*" (which were platform-neutral) and "Microsoft.*" (which were Windows specific).
There is Mono which runs on Linux, Solaris and OS X. In practice .Net is still pretty much a Windows-only platform. It's not really in Microsoft's interests to push it to be WORA, on the contrary. Appearing to be cross-platform however is. A lot of people have been really paranoid about Mono on Linux. MS's supposed strategy is to first let it grow to be an important part of the Linux application platform and then release the lawyers. I wouldn't bet my future on .Net's portability.
The answer is a very shaky Yes. The moment you include an external library, the answer changes to No.
For example, Microsoft has no 64-bit JET driver. JET is used by .NET to access MS Access databases.
Any applications compiled for the Any CPU target that use MS Access databases will fail on a 64-bit version of Windows.
(This is ignoring that said applications are not portable to Mono.)
Microsoft has never made those claims but they ARE making moves in the WORA arena. Silverlight 2.0 for example will use a subset of the .NET framework and be available on Windows, Linux (through the Moonlight project), MacOS, Windows Mobile, and Nokia handsets.
As others have mentioned, the Mono project has also brought the framework to multiple environments.
To put this in context, in many people's view Java never delivered on its "Write Once Run Anywhere" promise either.
At best what you got was "Write Once Debug Everywhere" or "Write Once Looks like crap Everywhere"
The successful CLR based applications have all been written using a graphical framework that is native to the target platform.
For example the following highly successful linux applications where written using c# bindings to GTK called GTK# and not using winforms like you would expect:
Banshee - music player like itunes
fspot - photo manager
TomBoy - notes program
GnomeDo - Quick launcher and dock
Equally successful windows .net applications are not written using GTK# (even though it is cross platform) they are written using winforms or WPF.
When google came to make Chrome they didn't try to use a cross platform GUI framework, instead they choose to use native GUI frameworks on each platform. Why? because that way the application, fits properly into it's environment, that way it looks, feels and acts like its native to the operating system its on.
Basically when you try to have write once run anywhere you have to make serious compromises and what you end up with is something that doesn't really work right anywhere.
The industry has largely given up on the lofty goal of write once run anywhere, as a nice idea which didn't work out in practice.
The best approach with mono/.net is to share your lower level binaries and to use a native gui framework on each target platform. GTK# on linux, winforms or WPF on windows, CocoaSharp on Mac. This way your application will look and feel like a native app.
With Mono we're getting pretty close, and with SilverLight we're allready there.
I don't think the official "intention" of .NET was WORA. I think that you could safely say that .NET was designed so that it would always run on future MS OS's. But there is nothing that precludes .NET from running on other platforms. Mono is an example of an implementation of the .NET runtime for an OS other than Windows.
Yes, this was a goal of .NET although I don't think it had the same emphasis as it did in Java. Currently, the only effor that I know of is the Mono project that is creating a version of the CLI which runs on Linux.
Interestingly enough, Silverlight actually has a slimmed down version of the CLR which can run on both Windows and Mac, which allows the same Silverlight app to run on both platforms unchanged.
It's theoretically possible, since the CLR (.Net's "virtual machine") complies with an open standard (the CLI). The question is what other implementations there are of that standard. Mono is another work in progress, but it's the only other one I know of.
I think that the idea with .NET is that it is a "Write Once, Run Anywhere (that Microsoft chooses)". However, the Mono project is slowly changing the situation.
It will never be supported on as many platforms as Java, IMHO.
The only effort is Mono, not sponsored by Microsoft.
Check here on SO and on the official site
In theory, yes. .Net Assemblies are bytecodes, which are converted to native code upon startup, using a JIT ("just-in-Time") compiler.
In practice, there aren't many platforms beyond Windows which have a .Net JIT compiler. There's one for Linux, called MONO.
Don't know about Mac, Sun etc...
Theoretically, the language is designed to be compiled into bytecode like Java which is interpreted by the Common Language Runtime, a mechanism that also allows several languages (not just C#) to work together and run on the .NET framework.
However, Microsoft has only developed the CLR for Windows. There are other non-MS alternatives being developed, the most prominent being Mono, a CLR implementation or a number of platforms (see the link).
So in theory yes, in practice - we'll see.
Yes and no. Parts of the .NET environment are standards and could be openly adopted.
For example, the runtime (CLR) has a portable version called Mono which is multi platform, open source and is used by (for example) Second Life.
The intention, or at least the pitch, was for this to be the case. The reality is that .NET can't really run on other platforms. The only major exception is Mono, which is an open source project. It's essentially a rewrite of the .NET runtime (the equivalent of the java virtual machine) that works on Linux, Solaris, Mac OS X, Windows, and Unix.
It's been fairly successful, but it's not officially supported.
If you're thinking of getting your monolithic Acme corp employer to adopt .Net and Linux, forget it. Realistically, with .NET, you're on Windows machines, period.
Yes, .NET has the Common Language Runtime (CLR) which is the .NET equivalent to the JVM. Microsoft does not support it on as many platforms as Java but with the help of the Mono project it is possible to achive cross platform applications with the usual caveats.
Bear in mind that .NET is more than just the CLR. It is a whole platform.
Since .NET is only available (officially) on Windows, then not, it isn't write one, run anywhere. However the Mono team are making a good go at helping spread .NET beyond Windows, but they are always way behind the official stuff.
I don't think that it was the original plan, for Microsoft, to create runtimes for every platform and device, but they encouraged this by using a documented (?) intermediate language.
Multiplatform was of course in the vision.. right now mono does a good job of implementing the runtime for other os.
Mono
Short answer -- no, Microsoft only supports MS operating systems (including Windows Mobile) for .NET.
Long answer -- there are public open-source projects to replicate the .NET framework for linux and other OSs, notably Rotor and Mono. They don't support everything, but you can deploy a lot of .NET code, including silverlight.
That depends on your definition of "Anywhere".
There are several flavors of Java virtual machine and of .Net framework.
And most of the time you can't just write code for a desktop vm/framework and expect it to run on a mobile phone one.
So. in a sense, even Java is not really pure "Write Once, Run Anywhere".
It is true, however, that Java's VM is currently running on several operating systems while .Net framework runs only on Windows devices.
There is one interesting initiative called "Mono" which offers .Net support on Linux, Solaris, Mac OS X, Windows, and Unix. Read here: Mono Site
dotNet can be, because of the CLR which is similar in function to the JVM.
But i dont believe MS had any intention of it being.
http://www.mono-project.com/Main_Page
might be useful, but its not a MS product.
Btw, much like how the wide spectrum of j2ee containers cloud the WORA concept for j2ee apps, ASP.NET apps running on anything besides IIS wouldnt really work the same across disparate platforms.
I don't think this was ever really a design goal of .NET - Microsoft has no particular interest in people writing software for non-Windows platforms ....
However, there is The Mono project (http://www.mono-project.com), which is "an open development initiative sponsored by Novell to develop an open source, UNIX version of the .NET development platform."
It was most assuredly meant to be WORA. It's just MS figured Anywhere and Everywhere would be Windows by now. Who knew Linux and the MacOS would still be around. But judging by all the Macs at the PDC, I guess they were either half right or half wrong!
If WORA was really an original goal, then I guess we'd see .NET implementations on all the major platforms by now, fully supported by Microsoft. I seem to recall that at the time Sun was shouting WORA from the rooftops, Microsoft's riposte was "Write Any (language) Run on One (platform)" (WARO:-). As somebody else mentioned, I think they've always been firm backers of WORASLAIW (Write Once Run Anywhere So Long As Its Windows)
As you point out, they seem to be changing tack a bit with Silverlight to try and get a piece of the Flash/Flex action now that the battlefield has shifted significantly away from the desktop and towards the browser.
But it IS multiplataform Win9x/WinNT/Mobile
Given responses from others I'm still unclear as to whether it was an actual intention of Microsoft to have .NET be a WORA initiative. The only way to really know I guess is to have somebody from the Microsoft .NET team chime in on this.
Since we cannot definitively know the original WORA intentions of .NET we can point to efforts that are attempting to make this a reality (as previous answers have talked about).
[Mono](http://en.wikipedia.org/wiki/Mono_(software))
This effort is an initiative happening outside of Microsoft.
Mono is a project led by Novell (formerly by Ximian) to create an Ecma standard compliant .NET compatible set of tools, including among others a C# compiler and a Common Language Runtime. Mono can be run on Linux, BSD, UNIX, Mac OS X, Solaris and Windows operating systems.
Silverlight
This effort is being heavily pursued by Microsoft. Silverlight 2.0 implements a version of the framework that is the same as .NET 3.0 and seems to be an attempt to successfully deliver the framework to multiple platforms through the browser.
It is compatible with multiple web browser products used on Microsoft Windows and Mac OS X operating systems. Mobile devices, starting with Windows Mobile 6 and Symbian (Series 60) phones, will also be supported.
While it does not specifically address bring functionality to GNU/Linux there is apparently a third-party free software implementation named [Moonlight](http://en.wikipedia.org/wiki/Moonlight_(runtime)).
This seems to be what we currently know, but as stated earlier, it would be very helpful if somebody from the .NET team could pitch in on this one to properly clarify if WORA was in fact an original initiative.
If Microsoft were serious about dotnet on other non windows platforms they would have released the class libraries for reuse by others ajoiding the need to rewrite the same libs again. Sun on the other hand has done this meaning less barriers are present ifnone wishesto port to another platform. Natually with java one still needs to write a vm and do the native stuff but it helps avoid a headache that is reimplementing the entire class library. The standardization of the language wS a marketing ploy to grab jon technical folk. A language without libs is worthless. Try doing your next project withnknly the prjkitive types ... That's right write your own string class etc and tell me how helpful a standardiSe language is without any libs available...
I think the idea was to create inter-operability between the different programming languages, not WORA.
.Net Core makes .Net "almost" Write Once Run Anywhere.
But there are subtle differences -
.Net Core is not really .Net
With .Net Core, you write once but build multiple times, once for each specific target OS. Whereas in Java binaries are built once and can be run on any supported OS.
dotnet build --runtime ubuntu.18.04-x64

Categories

Resources