Test run failed: java.lang.IllegalAccessError

7

This happens when you have 3 projects in your eclipse dev environment.
1) Library project : here you have common stuff between other projects
2) Android project : here you have your android app, which has the Library project as a project in your build path
3) Android Test Instrumentation project : here you have your test cases which run on your android device.

Naturally you will include 1 and 2 as dependent projects to 3, in 3’s properties->java build path -> projects.

Instead you need to edit the project properties on 2. On 2, Properties->JavaBuildPath->OrderandExport, check the Library project for exporting.
AND
Dont include the library project into 3, instead just include 2 in 3. Since 1 is exported in 2, you will be ok. And this error will go away.

I referred to this blog for this issue.

Advertisements

EOFException OutputObjectStream readObject() peek

0

This blog talks a bit about a exception we see in java frameworks, and applications when we use ObjectOuputStream.readObject. The following are the possible causes
Possibility 1) In a setter you have the assignment the other way around

private Object value ;
setValue(Object newValue) {
newValue = value ;
}

Possibility 2) Data is null when passed into your code
Possibility 3) End of file has reached, and InputStream has no other way of telling you that the outputstream has been “closed”. So dont just throw the exception, handle it right here and right now.
Possibility 4) Something obvious is missing, put out your code snippet on a comment, I’ll review it for you

ObjectInputStream / ObjectOutputStream java and sockets

0

This is to give generic advice to people writing code that has Object level streaming on sockets. I went thru some pain to get my piece of code working and by this blog I hope to give some quick tips to you.

Tip 1 ) If you expect to read/write objects between a client to your server, then create just one objectoutputstream and outputstream on your client. Similarly create just one objectinputstream and inputstream on your server for that client. Many code fragments will give you reason to believe that you need to create a objectinput/outputstream for every message that you pass. No, you dont. Its wasteful and not needed. Moreover it will return a java.io.StreamCorruptedException: invalid type code: AC exception. AC being the header that is passed from outputstream to inputstream. The inputstream expects only one header for that stream. And the constructor of outputstream creates that :). Sorry, went too deep..

Tip 2 ) If you are doing so much of sockets, I am sure you are using a threadpool to ensure that you dont get screwed on perf. So watch what you lock in a synchronized block. Most often you have locked even the “processing” of data that you received on your objectstream. All you need to have in your sync block is your wait’s, notifies, your calls to add/remove data from the shared queue. Everything else should be outside the sync block. Remember if you are using a threadpool, you are using a shared queue, and all your threads need access to that sharedqueue, so release it asap.

Tip 3 ) Exception handling :). You thought u got a hold on it. Nope. it can be really crazy if you dont. Do some thinking here. You dont want to do a generic, printstacktrace on all. You want “handle” errors correctly. Infact this starts of a new discussion. You need a errormanager framework that handles errors for you. I know, it becomes crazy when you have 10+ dev’s and none of them know how to handle errors. I’ll share some tips to help centralize and control that issue. If you are interested to know more, put some commends on this blog, so that I know its worth my time.. :).

Tip 4) Documentation and Coding. I read some good articles recently which hinted at documenting/commenting only the why’s and not the how’s and what’s.

Tip 5 ) Create all your threads upfront. Dont create threads as and when you get client requests. Remember, clients expect quick response, if multiple clients are going to get alive at the same time, you dont want your server waiting for cpu time to create threads. It will slow down all the clients.

Tip 6 ) EOFException peekByte. Most probably you dont have a InputStream ready. Remember readObject is a blocking call. You dont need to call inputStream.available() to check if there are bytes.

Android and Junit (adding new run configuration gives “argument error”)

0

So eclipse is throwing out a ugly error that has no meaning. “Argument error, details saved in some hs_#@#$@@.log” file. Dead irritating.

I am sure you tried what I did, added a junit4 (or 3 for that matter) java file, for testing your app. And tried to create a run configuration, using Android Junit Loader. Well, I did the same. For some reason, if you have your test java file as part of your android project it does not work.

To fix it, create a Android-Junit-Project, and move your files here. Dont forget to mark client as a dependent project on your new android junit project.

This will work.