Java Access Modifier

While waiting for the lunch time lets do something very basic but quiet interesting; Java access modifier.

There are four access modifiers in Java: public, protected, private, and package access. Suppose we have a project with package structure as below:



There are four classes:
1. A superclass for other classes named SuperClass
2. A subclass of class SuperClass named SubClassA which resides at the same package as its superclass.
3. A subclass of class SuperClass named SubClassB which resides at different package as its superclass.
4. Another class at different package named Main.



The SuperClass has all four different level access method. We will see which methods are visible at any of the other three classes.



We can see that the public, protected, and package access level methods are visible in class SubClassA through both inheritance and reference.



Now we can see that there are only public and protected methods visible to class SubClassB through inheritance and only public method visible through reference. This happens because package level access, as its name suggest, only applies for classes reside at same package. Whereas protected applies for all of its subclasses.

There is a note here regarding overriding protected method. As we can see in class SubClassB, we override method protectedMethod from its superclass. Therefore, all classes at the same package with class SubClassB can access SubClassB's protectedMethod through reference. However, if we didn't override the protectedMethod, all other classes at the same package wouldn't be able to access it at all because protectedMethod would become private in SubClassB.



For a class at another package, as we can see in class Main, can only access public methods.

The access levels are simple and clear, aren't they? All method modifiers also apply to instance variables as well. OK, now it's time to go out for lunch.

Cassandra Architecture

Apache Cassandra is not another relational database in market. Instead of using relational model, it uses key-value map to store its data. The structure is more or less can be explain as in the following picture:



Cluster: Cassandra is designed to be distributed over several nodes/machines. A cluster consists of several nodes. I've only ever used Cassandra in a single node which is my computer.

Keyspace: A cluster consists of several keyspaces. Keyspace is the place where our data reside. A keyspace could have several Column Family or Super Column Family.

Column Family and Super Column Family: Both Column Family and Super Column Family is a collection of rows, just like a table is a collection of rows in relational database.

Row: A row consists of columns; key-value columns for a row in Column Family, or Super Columns for a row in Super Column Family.

Super Column: It is sort of container of sub-columns (which are of type Key-value Column).

Key-value Column: The most basic data structure in Cassandra where the actual data is saved as byte. The behavior is a lot like Java Hash data type.

Here are examples of Cassandra data retention and retrieval:

COLUMN_FAMILY_NAME[ROW_KEY_NAME][COLUMN]

User['user1']['name'] = 'Rochmat Santoso';
User['user1']['address'] = 'Surabaya';
User['user2']['name'] = 'Barbie';
User['user2']['address'] = 'Malibu';

SUPER_COLUMN_FAMILY_NAME[ROW_KEY_NAME][SUPER_COLUMN_NAME][COLUMN]

Province['province1']['info']['name'] = 'East Java';
Province['province1']['info']['capital'] = 'Surabaya';
Province['province1']['city']['sby'] = 'Surabaya';
Province['province1']['city']['mlg'] = 'Malang';
Province['province1']['city']['sda'] = 'Sidoarjo';

Province['province2']['info']['name'] = 'West Java';
Province['province2']['info']['capital'] = 'Bandung';
Province['province2']['city']['bdg'] = 'Bandung';
Province['province2']['city']['tgr'] = 'Tangerang';

Annotation

Setelah sekian lama akhirnya punya waktu juga untuk mencoba annotation. Beberapa catatan untuk annotation ini adalah:
- Tambahkan @Documented agar annotation ini bisa di-generate saat membuat javadoc karena defaultnya sebuah annotation tidak di-generate oleh javadoc tool.
- Tambahkan @Retention(RetentionPolicy.RUNTIME) untuk menyimpan data-data annotation pada saat kompilasi sehingga bisa dibaca saat runtime. Jika tidak disimpan maka kita tidak bisa membacanya.
- Ada beberapa macam tipe annotation tergantung tempat di mana annotation itu akan ditempatkan misalnya di class, method, field, parameter, konstruktor, dll. Gunakan @Target(value = ElementType.TYPE) untuk annotation yang diletakkan di Class atau interface. Beberapa tipe yang lain adalah @Target(value = ElementType.METHOD) untuk annotation pada method, @Target(value = ElementType.FIELD) untuk annotation pada field, @Target(value = ElementType.PARAMETER) untuk annotation pada method parameter, dll.

Berikut ini adalah contoh annotation dan cara mengaksesnya

Lucene Analyzer

There are several analyzer available in Lucene:

WhitespaceAnalyzer: It splits text into tokens on whitespace characters. It doesn't normalize the tokens and doesn't lowercase each token.

SimpleAnalyzer: It splits tokens at non letter characters and lowercases each token. It discards numeric characters but keeps all other characters.

StopAnalyzer: It acts almost same as SimpleAnalyzer except it removes common words. By default, it removes common words specific to English (the, a, etc).

StandardAnalyzer: It is the most sophisticated core analyzer. It has quite a bit of logic to identify certain kinds of tokens such as company names, email addresses, and hostnames. It lowercases each token and removes stop words and punctuation.

KeywordAnalyzer: It treats entire text as a single token.

Lucene Field Options

Field Indexing Option

Field.Index.ANALYZED : Use analyzer to break the field's value into separate tokens and make each token searchable. This option is useful for body, title, abstract text.

Field.Index.NOT_ANALYZED : Index the field but don't analyze the string value. Instead, treat the field's value as a single token and make the token searchable. This option is useful for URL, file system path, dates, personal names, card number, phone number. This option is useful for enabling "exact match" searching.

Field.Index.NO : Don't make the field's value available for searching

Field Storing Option

Field.Store.YES : Store field's value in the index. This option is useful for fields that we want to display along with the search result such as URL, title, database primary key. Without storing the field's value, we won't be able to retrieve it using document.get("fieldname") on searching.

Field.Store.NO : Don't store the field's value in the index. This option is often used along with Field.Index.ANALYZED to index large text field such as text body.

Here are some example of field indexing and field storing option:

Analyzed & Stored : title, abstract text
Analyzed & Not Stored : body
Not Analyzed & Stored : URL, file system path, dates, personal names, card number, phone number
No Index & Stored : database primary key
Not Analyzed & Not Stored : hidden keywords

Code Example:

Document document = new Document();
document.add(new Field("filename", file.getName(), Field.Store.YES, Field.Index.NOT_ANALYZED));
indexWriter.addDocument(document );