I'm not aware of any service or easily installed and used software that will accomplish what you want.
I suspect you will get a lot of advice that you have already said you don't want from a lot of people who won't bother reading your entire post. In the future, if you try asking the question again, I suggest you start a "self-moderated" thread. That way you can delete all the undesired advice.
Thanks danny, i appreciate your feedback (no easily installed and used software ), as for the self moderated thread, the whole point of defining non-viable solutions or un-needed advice is to avoid having to moderate a thread.
Anyways, i guess there is always Fiverr.com, i have managed to get a ton of development done through them for next to nothing with BitcoinJ so if over the next day or two nobody else has a viable solution, i will hire some guy from India or Pakistan for $5 to copy/paste a few lines from BitcoinJ to make what i need since i have no clue what any of the stuff in the BitcoinJ zip file is and they seem to read it like a kid reads cat in the hat.
Unfortunately, part of the problem is that at the protocol level, there is no such thing as an "address" or a "balance". There are only "outputs" and scripts that set up requirements that must be met in order to reassign the value from those outputs. The concept of a "balance" or even a "bitcoin" for that matter are just abstractions that we humans use to make it easier to talk about transferring control of value.
Therefore, the only way to find the "balance" of a very long list of "addresses" is to have a database of all currently unspent outputs, and then check every address against the scriptPubKey of each unspent output. Any software to do this would need to stay synchronized with the blockchain, and therefore would need to be kept running or the user would have to wait for synchronization every time they start it up. Any service to do this would need to be able to handle the HUGE number of requests to search the entire database for every address for every potential user of the service.