We Keep Coding

Exception: Unmarshalling unknown type code occurred at run time

I am working on Android app and we are working as a team. I am facing a serious issue. And that is when ever I try to get the data from intent it gives me following exception
Parcel android.os.Parcel#355932a: Unmarshalling unknown type code
4784211 at offset 712
I know on SO there are a lot of helping material related to this issue, but my case is different and quiet mind boggling .....
Here is a quick code to see how I am getting my object
try {
if (data.hasExtra("KEY_MY_MODEL")) {
MyCustomModel newSelectedModel = data.getParcelableExtra("KEY_MY_MODEL");
//DO SOME THING WITH OBJECT
}
} catch (Exception e) {
e.printStackTrace();
}
Case1:
I am getting exception on first line if (data.hasExtra("KEY_MY_MODEL")) {
and this is quiet funny because when I inspect the intent object (data) while debugging and if I look into intent object using debugging I can see all my custom object.
The keys of getting object are same, if in any case the key is wrong I think the code inside the if condition must not get run. as it will return false.
But instead of returning false it is giving the above mentioned exception.
Case2: As I told you we are working in team, the same set of code is running perfectly on other system, but when I run app from my system and install app on device, it is giving the exception I mentioned above.
This is very much frustrating. I think there is something wrong with proguard, as I read on S.O but its still not helpful. Any Idea why this is happening? This looks like a big bug.
Note: I am using A.S 3.5 and on other system A.S 3.5 is in use, even we have same set of sdk, configurations and other things are quiet
identical on both sides...

It seems to be a ProGuard issue
Just add this line in proguard.rules.pro/txt
-keepclassmembers class * implements android.os.Parcelable {
static ** CREATOR;
}

Tomcat webclassloader fails to find a class

In a Tomcat 7 I have a pretty standar jar file on WEB-INF/lib. Inside this jar I have this class called Parser, and next to it (on the same dir) I have another one called AutomaticLocalLoader. Compilation gives no problem at all. In run time the AutomaticLoader class is found, and when It needs the Parser class, I get a NoClassDefFoundError
The Parser and AutomaticLoader class have been working without this problem for 15 years!! in many diferent vers of java and tomact; and now out of the blue, I am getting this NoClassDefFoundError, only for the Parser class. I already put a copy on a directory inside the WEB-INF/classes path and still got the same error. I already created my own ClassLoader to see if I get some error loading the class from the WEB-INF/classes directory by myself, but I can load it without problems.
log.info("Leer " + aFlInstructions[i].getAbsolutePath());
LoaderTest A = new LoaderTest();
A.test("com.hds.resolve.model.aguila.AutomaticLocalLoader");
LoaderTest B = new LoaderTest();
B.test("com.hds.resolve.model.aguila.Parser");
if(!bOverrideInputDir)
Psr = new Parser(aFlInstructions[i]);
else
Psr = new Parser(aFlInstructions[i], new String[] { StrLocalDirectory } );
The LoaderTest class, try to create the Class Object for the given name using Class.forName. If NoClassDefFoundError, then try to load the class using my own classloader and then create the class.
For the AutomaticLoader, it succed at the first try. For the Parser class if fails, then successfully load it with the custom classloader. Of course when the code reach the "new Parser" part, the old webclassloader still fails and throws the NoClassDefFoundError.
Both Parser and AutomaticLocalLoader belong to the same package and are stored on the same jar inside WEB-LIB.
Funny enough, the error does always happen on production... but never in my machine. I do not use customs classloaders except for doing this debug. Also, trying an old version of the software seems to fix the error. No idea why.
I think I can hack a solution messing with the tomcat's webclassloader, but I really would prefer to understand what is going wrong with this code.

java BufferdImage dosen´t load

So right now I´m trying to load an Image on my Harddrive in a BufferdImage in my Code. Yet I think I did everything right but my trycatch only leaves the catch.
Code for better understanding :
private static BufferedImage image;
public void initPictures() {
try {
image = ImageIO.read(new File("Pictures/blue.png"));
} catch (IOException ex) {
System.out.println("Will not load");
ex.printStackTrace();
}
}
The initPictures() is called in my Constructor of the Class. And you can see here that my picture that I try to load is in the E:\Dropbox\Dropbox\Java Projekte\FallingBlocks1\build\classes\Pictures folder on my OS. So the "Pictures/blue.png" should be good.
Windows Folder Picture:
So my Qustion here is : What am I missing?
EDIT : added ex.printStackTrace(); nothing changed thought.
EDIT : also tried to load other pictures int the "image", with no other results

There are two possibilities:
1. Your program may not be running in the folder that contains the "Pictures" folder.
To find out where your program is running, do a System.out.println(System.getProperty("user.dir")); to see what folder you're running in. If it prints something other than E:\Dropbox\Dropbox\Java Projekte\FallingBlocks1\build\classes, you know it's an issue with the path you're providing to ImageIO.read(file). For kicks, you may also want to see what new File("Pictures/blue.png").isFile() is returning.
2. Your image might not readable.
If you try the first test out and you know for certain that the path you are providing is correct, then it's likely that your image file is either corrupt or cannot be read (could be caused by access restrictions, connectivity problems, hardware issues, etc.). Try pointing to a different image and see what happens.

File.canWrite is not working as per expectations

i am trying to check whether a file is writable or not. i have changed the file permission by myself for all users. but if i try to run the program, it show "true" as a response. if i allow the permissions, then also it is showing "true".
Whats is my problem?
try
{
File file = new File("D:/myproject_log/delivery_report_edr.out");
if(!file.canWrite())
{
System.out.println("you can't write!!!");
}
else
System.out.println("you can write!!!");
}
catch(Exception e)
{
e.printStackTrace();
}

It is working fine. I copied your code and run it twice. First I got You can write, then right click on the file folder, go to properties and select read only and run the program again and I got you can't write
So as per the documentation of the method canWrite() it gave me the expected output. Please confirm your settings once again and check.

Have you tried using the java.nio.file.Files#isWritable method. as well as File#canWrite ?

I have also found that File.canWrite() cannot be trusted, especially over network drives, often returning true even though a file write will fail or vice-versa. I made my own method that actually tries to write a dummy file to the dir. That is simple to write and foolproof. Maybe they fixed it though.

I had the same issue with a file located in c:\programFiles\folder and the File.canWrite method returned true and i was getting the same exception.
when i changed the permission of write as allowed true for USER defined in security tab of Folder properties, It gave me no exception.

JUnit tests fail when creating new Files

We have several JUnit tests that rely on creating new files and reading them. However there are issues with the files not being created properly. But this fault comes and goes.
This is the code:
#Test
public void test_3() throws Exception {
// Deletes files in tmp test dir
File tempDir = new File(TEST_ROOT, "tmp.dir");
if (tempDir.exists()) {
for (File f : tempDir.listFiles()) {
f.delete();
}
} else {
tempDir.mkdir();
}
File file_1 = new File(tempDir, "file1");
FileWriter out_1 = new FileWriter(file_1);
out_1.append("# File 1");
out_1.close();
File file_2 = new File(tempDir, "file2");
FileWriter out_2 = new FileWriter(file_2);
out_2.append("# File 2");
out_2.close();
File file_3 = new File(tempDir, "fileXXX");
FileWriter out_3 = new FileWriter(file_3);
out_3.append("# File 3");
out_3.close();
....
The fail is that the second file object, file_2, never gets created. Sometimes. Then when we try to write to it a FileNotFoundException is thrown
If we run only this testcase, everything works fine.
If we run this testfile with some ~40 testcases, it can both fail and work depending on the current lunar cycle.
If we run the entire testsuite, consisting of some 10*40 testcases, it always fails.
We have tried
adding sleeps (5sec) after new File, nothing
adding while loop until file_2.exists() is true but the loop never stopped
catching SecurityException, IOException and even throwable when we do the New File(..), but caught nothing.
At one point we got all files to be created, but file_2 was created before file_1 and a test that checked creation time failed.
We've also tried adding file_1.createNewFile() and it always returns true.
So what is going on? How can we make tests that depend on actual files and always be sure they exist?
This has been tested in both java 1.5 and 1.6, also in Windows 7 and Linux. The only difference that can be observed is that sometimes a similar testcase before fails, and sometimes file_1 isn't created instead
Update
We tried a new variation:
File file_2 = new File(tempDir, "file2");
while (!file_2.canRead()) {
Thread.sleep(500);
try {
file_2.createNewFile();
} catch (IOException e) {
e.printStackTrace();
}
}
This results in alot of Exceptions of the type:
java.io.IOException: Access is denied
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:883)
... but eventually it works, the file is created.

Are there multiple instances of your program running at once?
Check for any extra instances of javaw.exe running. If multiple programs have handles to the same file at once, things can get very wonky very quickly.
Do you have antivirus software or anything else running that could be getting in the way of file creation/deletion, by handle?

Don't hardcode your file names, use random names. It's the only way to abstract yourself from the various external situations that can occur (multiple access to the same file, permissions, file system error, locking problems, etc...).
One thing for sure: using sleep() or retrying is guaranteed to cause weird errors at some point in the future, avoid doing that.

I did some googling and based on this lucene bug and this board question seems to indicate that there could be an issue with file locking and other processes using the file.
Since we are running this on ClearCase it seems plausible that ClearCase does some indexing or something similar when the files are being created. Adding loops that repeat until the file is readable solved the issue, so we are going with that. Very ugly solution though.

Try File#createTempFile, this at least guarantees you that there are no other files by the same name that would still hold a lock.