So what's the fuss about protected?

Let's look at the following two files:

File: A.java

package a;
 
public class A {
  protected void prot1() {}
 
  protected void prot2() {}
}

File TesterA.java

package a;
 
public class TesterA {
  void test() {
    A a = new A();
    a.prot1();
    a.prot2();
  }
}

Pay attention to method test in TesterA. It may look incorrect, but it will compile without any problems! Every function marked protected is accesible throughout the whole package - as it were public. Seems similar to default? Indeed it is! Protected is nothing else, but a default that can also be inherited outside package. Default on steroids! :-)

Here's an example how we can extend A in different package:

File: B.java

package b;
 
import a.A;
 
public class B extends A {
  @Override
  protected void prot2() {
  }
 
  // we leave prot1 untouched, we don't override it
 
  void test() {
    prot1();
    prot2();
  }
}

It's not the end yet! We should pay attention to few more important details. Again, code:

File: TesterB.java

package b;
 
public class TesterB {
  public void test() {    
    B b = new B();
    // b.prot1(); // won't compile
    b.prot2();
  }
}

Why prot2 will compile and prot1 won't? For an explanation we should analyze what happens when we inherit protected method and don't override it. In this case method becomes accessible only inside class that is extension of superclass. That is what happens in our case with prot1 method: it is accessible inside class B (which extends A), but not in class TesterB.
Story is different with prot2 method. When we override it with protected method it becomes "public" for all classes in package b. As a result we can access prot1 in class TesterB.

Also remember that we can extend class B in third, different package and still inherit prot1 even though it wasn't overridden in class B. Here's example:

File: C.java

package c;
 
import b.B;
 
public class C extends B {
  void test() {
    prot1(); // works
    prot2();
  }
}

That's all! Phew. Complicated? Yes, a bit. Try it yourself in compiler. It will clarify immediately.

Good luck.

I'm studying for SCJP (1.6) exam. Today I've decided that it will be fun to publish some of my "findings" about Java language. Maybe someday they will become nice guide for other SCJP learners? Who knows. Bottom line for understanding this is a bit of experience in Java programming. So, for the start commonly misunderstood feature of Java language: default modifier.

File: A.java

package a;
 
public class A {
  void def() {} // no access modifier (a.k.a. default)
}

File: TesterA.java

package a;
 
public class TesterA {
  void test() {
    A a = new A();
    a.def(); // !!
  }
}

See that? Line with two exclamation marks? Code compiles without a glitch. Seems that default means public! Before you let yourself die of a heart attack calm down and let me tell you the rest of a story: it is indeed public, but only throughout a package. This "trick" won't work if you put TesterA class in different package.
Surprising, isn't it?

PS. There is of course a rationale behind this behavior, we could also discuss if this is a good behavior, but it is beyond scope of this post.

Today I had to recover some data from my previous "Android ROM". Luckily I made a backup using recovery image with nandroid.
It isn't so obvious what tools to use to extract nandroid image. At the beginning I thought that I simply mount backup image under Linux using loop device, but it turned out that you need special tool for that. I even haven't had luck mounting it directly from phones shell. It seems that nandroid created images aren't just standard partition dumps. Ok, so here is procedure:
- data partition is backed up (as you may suppose) to data.img - this is a file we will be working with
- to extract data you need to download unyaffs tool
- you have to compile it by hand: "gcc -o unyaffs unyaffs.c" (under Windows cygwin/mingw may help)
- after successful compilation run it with data.img as parameter - it will extract partition dump to the working directory
- database of your application can be found in data/full_app_name/databases directory
- you can list content of this database using sqlite3 command line tool or presumably (haven't tried it myself and it may depend on what application data you are recovering) copy it back to your Android device running current ROM (rooted phone may be needed).

Viola! At the end - quite simple!

I've recently bought a car. A beautiful BMW E36 2.0 Coupe 1996. I've decided that I will try to maintain a wiki page about it. All of you who know polish can now read about my plans, current works etc. related to car here. Enjoy. :)

Since 208 days, the day of last news, website was updated a lot of times. All changes can be traced on Recent changes site. The most often updated sections of this site is Projects.

As you can notice site has changed again. This time it isn't only engine replacement buy also complete site move to another server. Reason is simple - I am searching for something that will satisfy all my needs (including simple and effortless administration). Wordpress (my latest blogging engine) was very powerful, but because I had it installed on my own server it still took to much time to make updates and maintain engine (e.g. plugins incompatibility after update was a pain). Because I tested Wikidot contributing another site running on this engine, I decided that it will be the best solution for me.