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.
Related
I'm attempting to write a desktop application that connects to bluetooth smart / BLE devices, for example, Polar Heart monitor.
Is there a generally recognised way to do this, Java API or library?
This is for a desktop application not android. Everything I see online is year(s) out of date or specifically android. I would rather try to avoid writing some platform specific JNI shenanigans.
Thanks.
I've used NRJSerial in a desktop application (Linux based) with Java. It has native in it but I didn't have to deal with that directly. There are ways to read from the USB/Serial port in Java but I found this to be portable and easy.
A word of warning though - it's low level. I was dealing with a PulseOximeter that just dumped binary so it wasn't too bad. If you start to get into GATT and so on it will be a decent amount of work to handle that.
If you plan on using a linux based system you can use bluez5.
Bluez5 exposes interfaces in the DBus thus interaction with bluez can be done with the dbus bindings of your choice(C, python, C#Mono.. ). Using the dbus-api you'll be able to scan, connect, pair, notify, read/write, advertise and much more
You can find a description of the dbus api exposed by bluez here (I suggest looking at the adapter-api, device-api and gatt-api) : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc
Before diving into the code you can play around with bluetoothctl (a tool that you can use for pairing, connecting, services discovery, gatt attributes reading & writing etc).
Also, you can find the source code of bluetoothctl here : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/client/main.c
bluetoothctl was built using GLib GDBus (dbus bindings for Glib in C) and you will find code examples for pretty much everything you'd like to do with bluez.
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.
I'm afraid the answer to my question is no, but I'm asking it anyway just in case.
What I would like to do is stream audio from a chrome browser to a server written in Java via WebRTC. My understanding is that to accomplish this I need a Java implementation of peerconnection. All I've found so far is the libjingle Java API for android but that hasn't been particularly useful for integrating into my server app (I'd prefer an actual Java implementation, not just a C++ wrapper).
If a library to do what I want really doesn't exist does anyone have any pointers for how I might approach actually implementing the WebRTC spec myself? When I look at such a large spec I don't really know where to start.
You can use IceLink. We (I helped develop it) wrote a Java implementation for it, as well as .NET and Objective C.
This is a complete Java WebRTC signal server written with Java i/o sockets. https://code.google.com/p/jfraggws/ Just make a project, include the .Java file and include rt.jar in the project. Next set the port on the Html 5 client and plug in your servers IP. You now have java webrtc.
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.
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