Java development with an iPhone touch pad for the Atari 2600 from an urban hip-hop perspective

Java

I haven’t posted an update in a while and I looked back then realized that I almost forgot about this series I started. Hi, I’m Cliff. I like to post topics of interest, start a random series and abandon it part way in. If you’ve been here before then you probably already knew that. Today We’re going to take a deep look at the UDP component of my streaming audio experiment. Actually, it never was my experiment, instead I borrowed it off of some forum I found online but that’s irrelevant. In my last post I explained how audio is captured on the server at a high level and covered the basics of how audio works. I also hinted at two key methods in the program, sendThruUDP() and receiveThruUDP(). These two methods send audio bytes over the network from the server and receive them on the client respectively.

Rapid audio packets
Going back to my last post I highlighted the following block of code:

This is what we, in silicon valley, call a tight loop. It is a while statement based on a a literal boolean value which will never be false, meaning the loop will continue indefinitely. The reason it is tight is because using a literal removed the need for an additional conditional step, which would slow down the iteration. I hinted at the importance of speed when I illustrated this loop. When streaming audio and/or video data real time you want to do everything possible to reduce overhead in sending the data over the network. With this in mind, let’s look inside sendThruUDP();

There’s a lot happening inside this method even though there are very few lines of code visible. Here we see code which starts by creating a DatagramSocket object. It then creates a DatagramPacket object and stuffs the packet object full of sound packet bytes using the constructor parameters. We also pass the length of the packet byte array along with the IP address and port of the client that we are streaming to. On the same line that we create the DatagramPacket we call send on the DatagramSocket instance, passing this newly created DatagramPacket object. The send() method will take this Packet, which contains the raw audio data, and send it to the IP address and port info that is recorded inside the DatagramPacket. We end the method by closing the datagram socket then continue with the loop that originally called it.

The work of object constructor/destruction
Our first series of major problems are right here in this method. Remember what I said above about reducing overhead? Well there is a ton of overhead in this method, much of it is in the form of constructors. An object constructor usually contains the most expensive parts of any program as such you want to call them as infrequently as possible. Java attempts to make programing fun and simple by removing the many details of what your operating system and hardware are doing behind the scenes but in reality it helps to have a cursory understanding of what happens in general. Start with DatagramSocket(). This isn’t just a magical object. (Let’s try to imagine what ultimately needs to take place for sound to fly from one machine to another.) In reality the object has to establish communication bridge between your program and the operating system and eventually with your network card. This work would most likely happen in the constructor. Now consider the DatagramPacket object constructor. It doesn’t have to do as much work, however it does need to set aside (or allocate) a chunk of memory to hold the audio data. You may tend not to ignore it but allocating memory also takes some time. (As a Java programmer you are not supposed to think about memory allocation because it’s done auto-magically for you!) The operating system has to scan the available RAM and sometimes shuffle things a bit to find room for what you want to do. Finally the call to sock.close() adds even more overhead. The close() call destroys all of the bridge work that was established in the constructor.

Visualization
To visualize what is happening, imagine you wanted to carry a bunch of wood from Home Depot to your condo. Pretend you needed a truck and that there was a bridge between Home Depot and where you lived across town. Let’s say the truck could only carry so many blocks of wood and required several trips back and forth between your home and Lowes. (Yes, I started the analogy with Home Depot but work with me, Lowes is easier to type.) The bridge represents the Datagram socket, the truck would be the DatagramPacket, and the repeat trips would be the while loop calling the method. What this method does is build the bridge, then build the truck before driving a single load of wood home. It then places dynamite under the bridge and under the truck completely demolishing them before exiting and returning to Home Depot for the next load. (The sock.close() method is represented by the sticks of dynamite in my analogy.) Hopefully you can imagine how inefficient it is to move all of the wood from Lowes to your apartment. If there were a crew of wood workers at your home they would be annoyed by how long it took for each load of wood to arrive, thus there would be a lag in their productivity. On each trip they would likely takes a coffee break and watch an episode of Judge Judy.

We’ve found one major source of lag in our program but now let’s look at the client logic. Recall how I highlighted the run() method in the client?

This is another tight loop which is intended to be fast. It calls the receiveThruUDP() method on each iteration to receive bytes from the network into a byte array variable then pass them to the speaker.inside the receiveThruUDP() method we have the following:

This method begins by creating a DatagramSocket. It then creates a byte array of 1000 bytes, and then goes on to create a DatagramPacket where it passes the empty sound packet byte array, it’s length, and the IP and port we are streaming to. Next it calls receive on the socket passing the empty datagram packet. The receive method will will the packet with the sound data that was sent from the server. Finally the method ends by calling close on the socket and returning the received data to the calling code. Again, the logic in the method is intended to be fast. However, based on our learnings from above we can probably identify some very similar inefficiencies in this method. Creating a socket establishes a bridge with your operating system and your network card, creating the sound packet array and the Datagram Packet each need to allocate memory, closing the socket destroys all of the communication bridge that was set up in the beginning, then the entire process is repeated on each iteration.

How do we optimize these inefficiencies? The simplest thing would be to remove all calls to object construction from the inefficient methods. You also don’t want to call close in either the send or receive method. Instead you want to create the objects when the program starts and reuse these objects inside the send and receive methods. There are likely other inefficiencies in the program but these are, by far, the most critical. Like I said earlier, I was amazed the program ran and produced any audio at all as the logic is terribly inefficient. The fun part of the project was working incrementally through both the client and the server while running the app and hearing the incremental improvements real time. In other words, I was running both the client and the server and listening from the client. I would then make little small optimizations on either the client or server, recompile and re-run. The compile and run step happens quickly causing only a brief interruption in the audio. The result felt like I was massaging the sound into the correct shape… truly amazing!

I’m going to continue on this path of discovering the capabilities and possibilities of network streaming. Stay tuned for additional updates.

Yesterday, in my arrogance I spoke about some old UDP audio streaming logic I found online yesterday. I suggested that I could see where the choppiness problems were and fix them. Today I couldn’t help myself. I dove in and ran the code between two Mac computers to hear how it sounded. I was amazed that the code worked at all without any modification! Hi, I’m Cliff. You’re here because you wanna hear how it sounds to break your voice up into tiny little ones and zeroes on one device then reassemble them on another. I’m here because I’m just fortunate enough to be able to do this task. Picking up from yesterday I can proudly announce that I have indeed solved the mystery of choppy audio! It took about 20-30 minutes of copyin/pasting the original code and tweaking it to sound natural. My goal is to give you the answer to the mysterious choppy problem but…! Before I do so, let’s try to understand what the code is actually doing. There are two components, a server and a client.

The Server
We’ll Look first at the server. It starts off in the main() method and prints information about the audio system’s connected devices to the console.

These API calls [above] create a special DataLine.Info object instance which describes the format of the audio we wish to capture from the microphone. We call a getAudioFormat() method where the details of the audio format are encoded and returned in a special AudioFormat object instance. Without going into too much detail, understand that audio can come in many shapes and sizes depending on if you want stereo, mono, high fidelity or whatever. The AudioFormat class models things such as sample rate sample size, number of channels, etc. The format is given to the DataLine.Info constructor which creates an instance that we pass to the AudioSystem API via the getLine() method. At this point we have a connection to the microphone which we can open() and start() to capture audio samples.

How Audio works
For those of you who are very green to programming and/or audio I’ll explain briefly how audio, or sound in general works in computer systems. This all may seem pretty complicated but audio is one of the simplest concepts you can learn and is actually pretty cool when you understand it’s basic building blocks. Sound is merely the vibration of matter which our ears detect using little tiny hairs. The speed of the vibration makes the different noises that we hear. The vibrations come in various wave forms with different frequencies. Computers record and create sound using a process called digitalization. This is where frequencies, which are analog in nature, are converted to and from digits. It captures digital audio by using a microphone which is a piece of hardware that measures vibrations, or wave forms in the air. It takes a series of samples of the intensity of the wave at specific intervals and it creates or synthesizes audio by sending recorded samples to a speaker which includes a paper cone that vibrates based on the size of the digits in the sample. In short, the bigger the digits are in the sample the more intense the paper cone vibrates. You can think of the digits 16 as causing a small vibration where the digits 128 would cause a much more intense vibration of the paper cone inside the speaker. If a bunch of samples are sent quickly to cone the vibrations happen quickly, if they are sent slowly then the vibrations occur slowly. The combination of the speed and intensity of the vibrations of the paper creates noise or sound that we hear. I’m over-simplifying and glossing over a lot but that is the basics of sound. The samples and sample speed are the key to sound!

Here we see a byte buffer is created (with a strange not-round length of 1000 instead of 1024) and we enter a loop where we continually pass the buffer between two methods, targetDataLine.read() and sendThruUDP(). The first method reads a block of samples from the microphone, which (as described above) measures the vibrations in the air and writes these samples to the buffer. The second method sends the buffer of samples over UDP to the client.

The Client
We’ll now turn our attention over to the client. The client is a RadioReceiver which extend Thread. As it turns out, this is unnecessary complexity as there is no work being done other than playing back the captured audio samples. We can safely ignore the Thread part and pay attention to the code inside of the run method, which is invoked indirectly by the call to r.start() in the main method below.

The run method below declares a byte array which is used in a while loop. Inside the while loop we load the byte array variable with the result from the receiveThruUDP() method. This method attempts to capture sample data sent over the network and return it to the caller. In short the byte array is loaded with the samples captured from the network which were originally captured and sent from the server. We then pass the array of samples to a method called toSpeaker. This method eventually hands the samples to a Java API called SourceDataLine.write(). This Java API will eventually send the samples to the speaker which causes the paper cone to vibrate and recreate the sound on the client. See the run snippet below:

That’s the basics of how the whole operation works. There’s not a terribly large amount of code and I haven’t described the UDP networking pieces at all. I’ll continue this series explaining UDP next. in the mean time, keep looking to see if you too can figure out where things are slowing, **ahem**, chopping up. Keep in mind how I explained the key components of audio, sample intensity and the frequency, or speed of the samples.

So it’s a Wednesday night & I won’t be able to sleep unless I get this post out. Overtime I get to talking about Agile and TDD I go overboard. Hi, I’m Cliff. You’re here because you wanna know what this TDD style learning thing is all about. I’m here because I shot off my mouth over Twitter ’bout some stuff I had no business talking about. Now I gotta make something out of my tall order claims. Here I will attempt to stretch the limits of a simple programming construct as well as the limits of your imagination in my explanation.

The approach I’m going to explain is something I learned from Dierk König in the Groovy In Action book, I take no credit for the awesome technique and I’m not sure of its origins. The technique is language agnostic, will out live your written wiki documentation and stays up to date as the code evolves. So now that I got your attention, let’s get started. (Disclaimer, though it is language agnostic I will be explaining using Java syntax. Different languages/platforms may behave differently.)

What’s an assert?

This question came up in the Twitter chat so we’ll start here. (BTW, I’m really starting to dig the #CodeNewbie chat because they ask the cutest questions like, “what’s an assert?”) The basic function of an “assert” is to check a value or an expression and its form (again in Java) is:

assert (expression) : "error message when false";

The expression can be any boolean expression and the message is whatever you want to see when the expression fails. You can have something like

assert 2+3 == 1024 : "I'm not good math";

Then when you run this code it would explode your computer sending shards of silicon in random directions. Actually it would merely fail the process and dump the error message and expression to the console:

The interesting thing here is the way the values are dumped to the console. I’ll explain why this is so significant in a moment but for now let’s move on. You could have something more involved like this (assuming you have a guessMyAge method that lives somewhere):

result = guessMyAge();
assert result == 39 : "I think I'm 39 years old last I checked."

If the guessMyAge function can work magic then the code would run without failing. However, if magic really doesn’t exist in my Macbook pro and it really couldn’t guessMyAge then I might see something such as:

java.lang.AssertionError: I think I'm 39 years old last I checked.. Expression: (result == 39). Values: result = 109

I would then say, “Nice try Macbook. I get to pick a prize now, right?” All dry jokes aside, you might notice a pattern here. To make it clear I’ll give another example. Pay close attention because I’m going to try to confuse you.

Let’s say you had a method named “fib” defined somewhere and I gave you the task of designing an app with this function. You might panic and be all, WTH??? What is “fib”??? Or you might try something like:

You would do this because you would be asserting the sentence string you give to the fib method is a “fib” or a false statement. Furthermore you might be guessing that the fib method does some sort of lie detection so you would assume passing a fib to a fib detector would return true indicating that you do NOT actually have bad breath. Again, unless your computer has magic inside you would probably get a compile error saying that the fib method takes an int parameter and returns an int value. (This is the confusing part where my example an my dry humor jump the shark.)

Sloppy humor aside. Let’s take the fib example again. This time we know that it takes an int parameter and returns an int value. We could do something like so:

int x = fib(1);
assert x == 0 : "I really don't know what this does";

Here we are setting the value of x to the return of the “fib” method without really knowing what “fib” is or what it does. We use the value in an assert and when we run it we get:

If you look carefully you have a valuable piece of information, “Values: x = 1”. You Didn’t know this before. We can copy and paste the value back into the assert and change the error message:

int x = fib(1);
assert x == 1 : "fib(1) should be 1";

That’s not so interesting. but watch what happens when repeat the code with a few different parameters.

x = fib(2);
assert x == 1 : "fib(2) should be 1";

x = fib(3);
assert x == 1 : "fib(3) should be 1";

x = fib(4);
assert x == 1 : "fib(4) should be 1";

We are changing the passed parameter in each case but keeping the assertion the same. After a little experience coding you might notice that usually when a different parameter is passed to a method you get a different value returned, so what gives? Think a moment. If you run this code and repeatedly copy the errors from the console back into the assert you would end up with this:

int x = fib(1);
assert x == 1 : "fib(1) should be 1";

x = fib(2);
assert x == 2 : "fib(2) should be 2";

x = fib(3);
assert x == 3 : "fib(3) should be 3";

x = fib(4);
assert x == 5 : "fib(4) should be 5";

Everything looks sort of predictable until the last line where the number jumps to 5. A few more iterations give you:

int x = fib(1);
assert x == 1 : "fib(1) should be 1";

x = fib(2);
assert x == 2 : "fib(2) should be 2";

x = fib(3);
assert x == 3 : "fib(3) should be 3";

x = fib(4);
assert x == 5 : "fib(4) should be 5";

x = fib(5);
assert x == 8 : "fib(4) should be 8";

x = fib(6);
assert x == 13 : "fib(4) should be 13";

x = fib(7);
assert x == 21 : "fib(4) should be 21";

If you have a background in computer science or have spent a lot of time programming in your career you might recognize the series of numbers emerging as the fibonacci sequence. What you have done is explore a method without knowing if was a lie-detector or a numeric series generator and through a process of iterating with different parameters and asserts you discovered its behavior. Furthermore you have documentation in the form of sentences describing the method. You could come back weeks or months later and see what the method does without looking at any of the code inside the method.

This approach works particularly well with methods in Java but how does that help you learn anything? Well, because the assert is so incredibly simple you can use it anywhere and with any programming construct. For example what does the following left shift operation do?

But what does that that actually do? A Java programming manual would say something like binary bit shifting. You can lookup the Javadoc for the Integer class to see how numbers print in binary form. Then you can use an assert to make the entire picture clear:

Clearly a left shift of 3 shows the “1” bit of the binary number 32 shifted over to the left by three positions. (It would be a little more clear if we added zero-padding but I’m keeping my examples simple.) The best part is that you get documentation as a secondary benefit of using the assert. You can print this next example and post it on your wall as a reference when learning how to bit shift. This is runnable documentation of how bit shift operators work:

Living documentation
I have another disclaimer. The above examples were all snippets that I actually hacked together using Groovy so they may behave slightly different in an actual Java program but the principle still applies. The idea was to focus on the assert and how it works. I used Groovy to avoid the boiler plate surrounding class definition. Now let’s look at an actual Java program to see how far we can stretch the secondary benefit. Suppose we were given a Java jar file that included the earlier “fib” method and told to use it. We could define a static block in our program and code all of the asserts inside of it as follows:

The static block documents what we discovered with asserts and runs as soon as the class file loads for the first time. As a result it doubles (triples?) as a sanity check. The assert has performed at least three tasks. We used it to learn the behavior of the method, it now documents what we know, and finally it works as a sanity check as the program runs. What if you get an updated copy of the jar file that contains the “fib” method and the behavior of “fib” changes? The asserts run with your code and dump the current behavior to the console. You merely repeat the process you used initially to discover the behavior and update the asserts accordingly.

How we learn programming languages
When learning a programming language you have two unknowns, syntax and runtime behavior. Learning the syntax is relatively trivial in many cases and usually the smaller part of the learning curve. Syntax is usually validated when you compile your program, and if you iterate adding small additions line by line as we did above then the compiler can almost function the same as the assert.

I find that the runtime behavior is far more tricky to learn and requires the experience of actually running variations of code. The bulk of the runtime behavior involves calling methods/functions in the language. Most languages have a set of functions and classes you must learn to achieve basic functions such as string concatenation, rounding, averaging, manipulating streams, etc. These functions make up the core of the language. In Java you have the Java API. Ruby has the Ruby API, ObjC/iOS uses the CocoaTouch API, and so forth. behave slightly different than what you would expect when you are first learning. Using the assert, you can discover the subtleties of how things behave and the end result is documentation that you can print and hang on your Christmas tree.

This post was intended to explain the power of assert. I actually stretched my examples a bit in a crude attempt to illustrate how assert can be used as a learning tool for beginners. In actually what I was really doing was a light weight no frills form of TDD. While you could start out with assert, In practice you really wouldn’t use a vanilla assert in a program this way. (at least not in Java) There a number of reasons, the first being that assert is disabled in Java and you must enable it by passing a flag on the command line. If you continue with a vanilla assert you will soon see other areas where it breaks down.

My overall intention is to introduce this new way of thinking. I use the assert as a gateway drug to unit test tools with more powerful assert abilities. It is indeed as simple and powerful as I depict in this post and it does have its place, specifically among other languages like Groovy where it is not disabled. (I particularly like the way Dierk used it in his book in lieu of traditional System.out.println statements.) If you find the approach at least somewhat interesting check back later when I attempt to use a more thorough approach to learning with TDD.

Last disclaimer: It is extremely late at night and I made only a feeble attempt at proof-reading/formatting. This is because I get super excited about the topic. There are definitely errors, misspellings/etc. so forgive me.

Then I notice… no, scratch that I don’t even notice that auto-complete has sprung into action and is offering me the proper completion at the top of the list, “getText()”. It happens in the most subtle way as my subconscious mind already knows what it wanted to do and it directs my fingers to accept the completion. What I end up with is:

Hi, I’m Cliff. You’re here because your IDE doesn’t do what my IDE does. I’m here because I’m ecstatic over what I’ve learned in the last 10 minutes. Look again at the above code snippets, both before and after and follow what happened in between. The important part is where the 1st line establishes a local variable of type “View”. To my amazement auto complete picked up and inferred it was a type of TextView when I started keying the 3rd line and it offered me not just any random or alphabetized list of suggestions but a preferred suggestion that matched exactly what was being conjured up in my grey matter. (For those unfamiliar with Android programming, a view does NOT include a “getText()” method.) And while I didn’t have to futz with the usual, “oh… I have to either declare my local type as a TextView or add a cast” my IDE does this inference then later performs the cast on my behalf keeping my cursor within the proper context so I can continue adding logic. It happened so “matter of fact” like and so quickly that I didn’t catch on until I had completed typing the line at which point I had to do a double take.

How does it know I need a TextView? Is it because of the preceding assert with the “instanceof” comparison? Does it just naturally assume most views will need to be eventually cast to a “TextView” type because that’s all most Android devs know how to use anyway? Is it reading through the xml layout and determining the type based on the integer id returned from my custom “findIdForStringIdentifier” that is taking a String constant id? Has Jetbrains quietly figured out how to read brainwaves over my Mac’s wifi antenna? I don’t know and I don’t really care!

I had done similar programming in other IDEs (Eclipse, Netbeans, X-Code, Visual Studio) but never have I ever had such an experience where an IDE literally read my mind, did the excessive back-spacing, parenthesis wrapping, casting, and continuation of thought for me. It’s these little nuggets that I keep finding in IntelliJ Idea that keep me addicted. I could go on for days on how wonderful this one… read it… ONE experience, out of hundreds of similar experiences, made my life today but I won’t. I’ve argued the merits of Idea to plenty of developers over the years but until you actually experience how do they put it…? “Development with pleasure” Until you actually live out a few of these scenarios you will continue to grind out code the usual way, hitting refresh/rebuild project to clear the red squiggles that really shouldn’t be there, dealing with arbitrary auto-complete suggestions, not truly being able to refactor code effectively as you could otherwise.

You’ve been down this road before. You’ve added a parameter to a constructor and now you have 2 parameters with similar names. You merely want to distinguish between them both. A quick lookup to see how the original parameter is used reveals that it is not an “id” rather it is a shortcut. After refactor/rename action in your IDE you wait for satisfaction which should only take seconds. Several minutes tick away while a progress bar fills, refills and is eventually joined by several other progress bars each taking their time to fill to completion. Hi, I’m Cliff. You’re here because you’ve been staring at your screen patiently waiting for several progress bars to bring you refactoring pleasure. I’m here for much of the same reason.

Every so often I hit an area in my code that doesn’t refactor exactly as I had anticipated. It happens much less frequently since I’ve moved back into Java development and can use the world’s best refactoring IDE. Still it does happen from time to time. This morning I was bit when I attempted to rename a class member named “id”. Apparently the my IDE is having trouble tracking down all 5 usages in the current file as it scans my entire project for these 2 very common characters. I’m not sure why it’s happening (it’s still running as I type) but I am guessing it is because I inadvertently left the “scan all non-code usages” option checked. I’ve had much worse war stories of refactoring under XCode which I will save for the future but I felt compelled to share today’s horror story since it is so rare that I have such headaches these days. Refactoring is actually my favorite part of development as I incrementally massage horrific code into easily managble bite-sized chunks but every so often it pays to watch which options you leave checked in the refactor dialog.

So I’m switching careers… I’m not getting a new job. I’m just finally getting into Android development, or so I thought. There’s one catch. I have this media server I developed that’s occupying all of my free/professional/personal/sleep hours. It’s not the media server occupying my time. Actually it’s my thirst for knowledge/expertise in the multi-media field that has me tied up. You see, I found out that the iPhone does something different when you request multimedia with the web browser. Not so different but to me it’s different. In my career I have not yet had to deal with progressive downloads. Mobile Safari likes to request multimedia in chunks rather than in its entirety. That feature has driven me to the dark edges of the HTTP manuals and beyond. Tonight, I finally have a rough implementation of a progressive download multimedia server. Apache seems to support this out of the box. But since my media server is implemented as a servlet under Tomcat I had to implement this myself. I found details on this page.

There ya’ go. Don’t say I didn’t get you anything for Christmas. If you missed it, your gift is here. Check it out and learn something new for Christmas. If I wasn’t so busy these days I’d elaborate more. You know, be more verbose and ramble about how HTTP is so tricky and why we need more high level abstractions. Last week was rough so I’m just gonna sign off with a “Hit me up party people!”

Maybe it’s me, but there seems to be a shortage of expert information on the net these days. I dunno about you but I constantly find myself running out of Google links and StackOverflow replies when looking for an answer to some rather valid technical issues. Am I the only one out there trying some of these crazy ideas or is the internet playing a savage game on me? Hi, I’m Cliff, and you’re here because you were waiting for me to post something crazy and far reaching. Maybe you were waiting on the, “How to tether your 8830 to your 1st Gen iPad” article. Maybe you were looking for info on how to install a Linux based firmware on your brand new Samsung 3D television. Whatever it is that brought you here, welcome to my little corner of the net where solutions to obscure technical issues are the norm.

I recently went on a journey into JNI land. I had visited many years ago plugging native MS Excel reporting into legacy RPG/400 programs via ILE wrappers around the POI project. Things were so much smoother back then. Flash forward to recent weeks as I wade through my old C manuals and skip through google links for Makefile tutorials. My project was to take a 3rd party native API, with C source code examples into the modern age. We need to use this API in a serious multi-user environment. To put it in simple yet technical terms, I needed to stream binary data from this API over the internet to a mobile device. Without being too specific and revealing let me give a generic example that colors the picture of what I’ve accomplished.

Say you have this blob of binary data. Go ahead, say it. Now say it once more but this time wait for a co-worker to walk by. Say the binary blob is generated from a native API that costs, oh about $2000 a seat. (The cost is not nearly as important as the seat.) Now say the API is not documented with any examples in the programming language of your choice. (Say that last sentence aloud with a girlie giggle between the 6th and 7th words.) Let’s pretend the only example given uses an old fashioned main function C reading cmd line arguments. Let’s pretend you have clients that need this blob on the other side of the internet. What are your options?

You could call the API using the command line example which writes to the file system. You could then read the generated file back across the internet using your favorite Ruby/Python/PHP programming toy. Then you would have to deal with file write collisions, the overhead of disk access, cleaning up the file after its written, file locks if you’re on Windows, and many other headaches.

You could modify the example to write directly to the internet. Then you have to deal with either implementing HTTP or talking to yet another 3rd party API written in the same language. You’d also have to deal with the language which you only use on the rarest of occasions… like never.

You could opt for the Language compatibility API that comes in the language of your liking with the additional purchase of two other vendor products. (API not sold separately.) You could do a number of different things each with their own drawbacks or you could do what I did… design a native interface.

I used JNI to write binary data from C back to a Java object. My first reaction was, “Gosh! How do I write a C++ output stream like thing to a Java output stream?” My second reaction was, “Don’t I need an input stream instead of an outputstream? Which end of which stream plugs in where?” (I always have that reaction when I deal with I/O streams.) the short answer, which applies equally to pure Java, C++, and Java/C++ is that you need threads to connect two streams… ALWAYS. There’s no safe way to deal with threads so thought a little harder. Because the output was delivered incrementally in my case, I opted to use a callback strategy. In other words, the API used callbacks to hand chunks of binary in array form to a calling application. I simply plugged in my JNI C code to accept these arrays and relay them to the original invoking Java object.

You have to be really careful with JNI native array conversion. There’s a proper way to copy bytes from C to Java and then there’s the whole, “is this a copy or a direct reference?” issue. Also you might get confused with array pinning in later VMs, but that really shouldn’t matter if you only need to materialize the data briefly in C.

In all, the general strategy for sharing binary data (A/V files, images, etc.) from C with Java requires byte arrays. You create a Java byte array in C like this: