About the author

Brian Keating is a developer addicted to Microsoft Technologies.

Month List

RecentComments

Comment RSS

Watch that error stream with Java process executions

clock October 19, 2011 09:55 by author Brian Keating |

 

I’m executing a windows process from java and I was bitten by a nasty oversight in one of my project today.
Everything’s been working fine for some time, but today the application I’m calling started spitting out errors to the error stream.

However I’d not been reading the errorstream in my code and it appears to be the culprit for hanging the process execution.

I don’t really care about the error stream or even the inputsteam myself as the thirdparty application does its own logging.

The solution was a follows: I used a SteamGobbler class to purge the input and error streams. Hope this helps someone.

image

 

 

image




Android

clock August 31, 2011 00:53 by author Brian Keating |

 

So it took me 2 hours (downloads on 2mbps included) to create an Android app in eclipse.

Wonder is that something I should be proud of giving I’ve been in software for nearly 15 years now…. 2 hours for a hello world… 

image

Listening to .net rocks and Xamarin podcast got me thinking, I really should see what’s involved in creating an Android app, after all I’m a registered Microsoft and Apple developer, I can create Wp7 apps in my sleep, I’ve even flirted with iOS, why not give Google and Android a shot.

I was going to install MonoDroid for VS2010, but hey i’m doing a hello world, no need for all this cross platformability. I’ve been doing a fair bit of java lately and eclipse doesn’t frighten me anymore so I just downloaded and installed the tools, and created the above app.. baby steps..

Any downsides? yes,, Now I wanna buy a Android tablet Who me?.




“Knock, knock.” -- “Who’s there?” -- long wait... -- “Java.”

clock June 13, 2011 09:09 by author Brian Keating |

 

So whose faster? Well C# or Java if you are talking “RAD”, but who executes faster?

IMO, C# and Java can be just as fast or faster because the JIT compiler (JIT or just in time is a compiler that compiles your IL the first time it's executed). JIT compiler can make optimizations that a C++ compiled program cannot because it can query the machine. It can determine if the machine is Intel or AMD; Pentium 4, Core Solo, or Core Duo; or if supports SSE4, etc.

A C++ program has to be compiled beforehand usually with mixed optimizations so that it runs decently well on all machines, but is not optimized as much as it could be for a single configuration (i.e. processor, instruction set, other hardware).

Additionally certain language features allow the compiler in C# and Java to make assumptions about your code that allows it to optimize certain parts away that just aren't safe for the C/C++ compiler to do. When you have access to pointers there's a lot of optimizations that just aren't safe.

Also Java and C# can do heap allocations more efficiently than C++ because the layer of abstraction between the garbage collector and your code allows it to do all of its heap compression at once (a fairly expensive operation).

Now I can't speak for Java on this next point, but I know that C# for example will actually remove methods and method calls when it knows the body of the method is empty. And it will use this kind of logic throughout your code.

So as you can see, there are lots of reasons why certain C# or Java implementations will be faster.

Now this all said, specific optimizations can be made in C++ that will blow away anything that you could do with C#, especially in the graphics realm and anytime you're close to the hardware. Pointers do wonders here.

Of course, C# (or Java, or VB) is usually faster to produce viable and robust solution than is C++ (if only because C++ has complex semantics, and C++ standard library, while interesting and powerful, is quite poor when compared with the full scope of the standard library from .NET or Java), so usually, the difference between C++ and .NET or Java JIT won't be visible to most users, and for those binaries that are critical, well, you can still call C++ processing from C# or Java (even if this kind of native calls can be quite costly in themselves).