LIRe의 소개( LUCENE 기반의 image retrieval library)

Lucene Image Retrieval의 약자이다. 


이름처럼 Image에서 몇가지 descriptor를 추출한 다음

Lucene에 각 descriptor를 하나의 필드로 해서 indexing 및 retrieval하는 

자바기반의 라이브러리로 보면 된다. 


즉 CBIR (Content Based Image Retrieval)용 오픈소스이다. 

CBIR 오픈소스는 찾아봐도 많지가 않은데 뭐 이유야 여러가지가 


있겠지만 아직까지 CBIR이라는 분야가 아직 많이 알려지지 않은


점이 가장 큰듯하다.

LIRe의 소스는 http://www.semanticmetadata.net/lire/에서 받을수 있다.

현재 최신버젼은  0.8이다. Demo와 Src 버젼으로 나눌수 있는데 

Demo 버젼은 GUI쪽의 부분을 주로 포함하고 있고 Src 버젼은

기본 LIRE의 src를 포함하고 있다. 헤깔리기 쉬운 부분이 GUI의 소스 또한

Demo 버젼에 포함되어 있고 Src 버젼에는 GUI부분의 소스가 없다. 

Demo의 실행법은 간단한데 

> java -jar liredemo.jar 를 입력하면 다음과 같은 창이 뜬다. 

 GUI 작동법은 어렵지 않으니 직접해보면 된다. indexing 속도가 생각보다 느려서 

 마음에 썩 들지는 않지만 CBIR 오픈소스가 있다는 자체에 감사해야 하는 상황인지도


 모르겠다. 

 LIRe가 이미지를 인덱싱하기 위해 사용하는 Descriptor는 다음과 같고 인덱싱하는


 필드명 또한 Descriptor명을 그대로 사용한다.

( net.semantic.metadata.lire.DocumentBuilder를 참고하자)

1. Scalable Color

2. Color Layout

3. Edge Histogram

4. Color Correlogram

5. Color Histogram

6. CEDD ( Color and Edge Directivity Descriptor )

7. FCTH ( Fuzzy Color and Texture Histogram )

8. TAMURA

9. Gabor

10. SIFT

11. SIFT Histogram

 11가지의 Descriptor를 사용한다. 

 각각을 검색해보면 각 Descriptor당 한개씩 논문이 나올정도로 CBIR에서 적통적으로

 사용하는 Descriptor들이다. 

 SIFT 알고리즘 하나만 해도 직접 구현하기는 상당히 까다로운데 

 암튼 저자가 많은 노력을 기울임에는 틀림이 없다. 

 각 Descriptor의 구현은 net.semantic.metadata.lire.imageanalysis 패키지에 들어있다. 

 패키지를 보면 다음과 같을 것이다. 

 CBIR쪽에 관심이 많다면 각각의 소스를 분석해보자. 꽤 심플하게 코드를 구현하여서

 분석하기는 어렵지 않을것이다.

lucene의 MoreLikeThis를 사용한 간단한 추천 시스템 만들기

 Lucene의 contrib중 queries 폴더에 보면 MoreLikeThis와

 FuzzyLikeThisQuery등이 포함되어 있다.

 사실 추천 시스템이라 말하기 좀 민망하긴 하지만 어찌됐던

 MoreLikeThis를 이용하여 문서 추천시스템을 만드는 것도 가능하다.

 MoreLikeThis는 주어진 다큐먼트의 Term Frequency Vector를 만들고

 이를 통해서 새로운 쿼리를 만드는 기능을 한다.

 즉 인덱싱된 문서중 주어진 문서와 가장 유사한 문서를 찾을수 있도록

 만들어 준다.

 TF를 이용해 문서의 key term을 추출하는 방식은 매우 고전적인 방식이지만

 아직도 많이 쓰인다. 궁금한 분은 다음의 논문을 읽어보도록 하자.

  "Newman, M.E.J. and M. Girvan, 2004. Finding and evaluating community structure in networks. Phys. Rev. E., 69: 026113"

 Lucene In Action 1판, 2판에 모두 MoreLikeThis에 관한 내용이 포함되어

 있으니 책에 있는 코드의 핵심 부분만 간단히 살펴보자.

  IndexReader reader = IndexReader.open(directory);
  MoreLikeThis mlt = new MoreLikeThis(reader);

  ...

  for ( int docID = 0 ; docID < numDocs; docID++){
    ...
    Query query = mlt.like(docID);
   TopDocs similarDocs = searcher.search(query,10);
    ...
  }

  1. 우선 IndexReader를 인자로 주어 MoreLikeThis 객체를 생성한다.

  2. 인덱스된 전체 문서에 대해서 각 문서의 term frequency vector를
      생성하고 이를 통해 query를 만든다.

  3. 주어진 쿼리로 인덱싱된 문서에서 다시 검색을 한다.


 즉 위의 코드는 인덱스된 모든 문서에 대해서 가장 유사한 문서들을

 찾는 역할을 한다.

 MoreLikeThis 객체의 like 메소드는 overloading되어 있어서

 사실 4개의 인자를 받을수 있는데 다음과 같다.

 1. 인덱싱된 문서의 번호


 2. File 객체


 3. reader 객체


 4. url 객체

 2,3,4 번의 경우 직접 term frequency를 구하여 term frequency vector를 만들고

 1번의 경우에는 IndexReader의 getTermFreqVector() 메소드를 이용하여

 term frequency vector만든다.


 lucene 내부에서 사용하는 term frequency vector는 TermFreqVector

 인터페이스를 implements 하거나 implements한 클래스를

 상속하여 만들어진다.

 IndexReader의 종류에 따라 사용하는 TermVector 클래스가 다르므로

이는 나중에 다른 글에서 설명하겠다.


 그럼 org.apache.lucene.demo에 들어있는 SearchFiles를 약간 수정하여

 인덱스된 문서들중 주어진 URL의 문서와 가장 유사한 문서를 찾는 예제를

 간단히 만들어 보겠다.

 1. 우선 다음의 import 구문을 추가한다.

 import org.apache.lucene.search.similar.MoreLikeThis;
 import java.net.*;

 2.  Search시에 사용하는 Query 객체와 관련한 구문을 다음과 같이 수정해보자.

 MoreLikeThis mlt = new MoreLikeThis(reader);
 mlt.setMinTermFreq(2);
 mlt.setMinDocFreq(2);

 Query query = mlt.like(new URL("http://wittgena.blogspot.com/2011/07/lucene-incremental-indexing.html"));


 사용법이 매우 간단하다.

 나머지는 모두 동일하고 while(true){} 구문만 제거하면 될것이다.

 MoreLikeThis에 필드는 따로 지정해주지 않았는데 지정해주지

 않으면 "contents" 필드를 기본값으로 사용한다.

 나의 경우 위의 코드로 linux kernel의 documentation 폴더의 일부 문서를

 인덱싱한후 돌려보니 대략 15개의 문서가 검색이 된다.

 각자 코드를 수정하여 실행해보자. 코드를 첨부한다.

 다운로드


 ps. mahout을 이용하여 lucene에서 term vector를 추출하는 방법도 있다.
      이는 나중에 다른 글에서 설명하도록 하겠다.
      lucene의 TermVector 객체를 알아두면 textmining에
      lucene을 사용할수도 있고 여러모로 유용하다.

lucene에서 n-gram, shingle 사용하기

 lucene에는 n-gram tokenizer와 shingle analyzer가

( 정확히는 shingle analyzer wrapper)

 포함되어 있긴 하지만 3.0.1 버젼을 기준으로 할때 contrib쪽에 포함되어 있다.

 n-gram과 shingle을 가끔 혼동하시는 분도 계신데 둘은 약간 다르다고 볼수 있다.

 n-gram이 한 문자를 기반으로 하는 반면에 shingle은 한 단어를 기반으로 한다.


 "you can select"을 예를 들어보면,

 n-gram 방식으로 bi-gram으로 한다면 yo, ou, uc, ca, an 이 될 것이고

 shingle 방식으로 2-shingles로 한다면 you can, can select가 될 것이다.

 검색을 해보니 lucene에서 n-gram을 사용하는 법에

 관한 블로그는 이미 있는 듯하여

 나는 lucene에서 shingle을 사용하는 방식을 간단히 설명하겠다.

 lucene의 contrib쪽에 보면 analyzers 소스 폴더가 있다.

이 analyzers에 n-gram과 shingle 둘다 포함되어 있다.


 우선 "ant build-contrib" 명령어를 통해 contrib쪽을 빌드하면

 build/contrib/analyzers/common 폴더 밑에 lucene-analyzers-x.x.x-dev.jar 파일이

 생성된다. ( x는 버젼명이다. 즉, 나의 경우는 3.0.1이 된다.)

 이 jar파일을 classpath에 포함한후 src/java/org/apache/lucene/demo의 IndexFiles.java

 에서 다음의 두 부분을 수정한후 빌드해 보자.

 1. import 부분에 다음을 추가한다.
  import org.apache.lucene.analysis.shingle.*;

  2. IndexWriter 객체의 생성 부분을 다음과 같이 수정한다.

  (대략 60 ~ 70 라인 사이에 있다. )
IndexWriter writer = new IndexWriter(FSDirectory.open(INDEX_DIR),
                                                //new StandardAnalyzer(Version.LUCENE_CURRENT),
                                                new ShingleAnalyzerWrapper(new        StandardAnalyzer(Version.LUCENE_CURRENT),3),
                                                true,
                                                IndexWriter.MaxFieldLength.LIMITED);

  IndexWriter의 생성자에서 무엇이 수정되었는지는 쉽게 알수 있을것이다.

 의미는 기본 analyzer로 StandardAnalyzer를 사용하고 shingle의 최대 크기를 3으로

 한다이다.

 이후 나머지 searcher를 이용한 검색과정등은 모두 동일하다.

Lucene의 Ranking Algorithm 변경

 lucene은 사실 그렇게 쉽지 많은 라이브러리이다.

 lucene의 ranking algorithm을 변경하는 방법은 여러가지인데  이중 가장

 기본적인것이 TF-IDF cosine similarity 공식 (또는 scoring fomula)을 변경하는

 것이다.  그 외에도 Query에서 가중치를 주거나 Searcher에서 HITS Collector의

 순서를 변경하는 방법, Document의 Field별 가중치를 다르게 주는법(boosting) 등등등

 여러가지가 있다.

 일단 scoring fomula를 수정하는 방법을 살펴보자.

( Lucene in action의 3장을 보면 이 내용이 잘 설명되어 있다.)

 우선 src/java/org/apache/lucene/search 폴더에 보면 DefaultSimilarity 클래스가 있다.

 메소드를 보면 computeNorm(), lengthNorm(), queryNorm, tf(), sloppyFreq(), idf()

 등등이 있다. 이 클래스는 IndexWriter 클래스에서 사용하는데 DefautSimilarity

 클래스를 상속해서 새로운 Similarity 클래스를 만들면 간단히 공식을

 변경할수 있다.

 물론 변경후 반드시 IndexWriter에 등록을 해주어야 한다.


 다음과 같이 DefaultSimilarity 클래스를 상속하여 새로운 클래스를 만들어보자.

import org.apache.lucene.search.*;

public class MySimilarity extends DefaultSimilarity {
public float tf(float freq){
return (float)(Math.sqrt(freq));
}

public float idf(int docFreq,int numDocs){
return (float)(Math.log(numDocs/(double)(docFreq+1))+1.0);
}

}

TF와 IDF를 계산하는 공식만 수정하는 간단한 소스이다.

 이제 IndexWriter 객체에 등록한다.



 IndexWriter writer = new IndexWriter(FSDirectory.open(index),
                                  new StandardAnalyzer(Version.LUCENE_CURRENT),              
                                  create,
                                  new IndexWriter.MaxFieldLength(1000000));
 writer.setSimilarity(new WikiSimilarity());

 당연한 얘기겠지만

 인덱싱을 하기전에 IndexWriter에 등록을 해주어야 한다.

 이제 수정된 공식으로 다큐먼트를 인덱싱하게 된다.

perl로 작성한 간단한 cosine similarity 소스

 요즘에는 python이 인기가 더 많은듯 한데 개인적으로 python을 별로

 좋아하지 않는다. 사실 매우 편협한 이유인데 들여쓰기와 함수의 시작

 과 끝이 { }로 구분되지 않는다는 점때문이다.

 간단히 Cosine similarity를 구하기 위해서 python이나 perl과 같은 스크립트

 언어로 스크립트를 짜야 할 때가 많은데 다음의 cosine similarity를 구해주는

 간단한 perl 스크립트를 이용해 보시라.


 사용법은 간단하다.

 document.txt 라는 파일을 만들고 파일에 여러 다큐먼트를 다음과 같은

 포맷으로 합친후 스크립트를 그냥 실행하면 된다.

 <TITLE> doc1 </TITLE>

 This is document1.

 <TITLE> doc2 </TITLE>

 This is document2.

 소스는 별로 어렵지 않으니 다큐먼트를 합치기가 귀찮다거나 아니면

 알고리즘을 수정하고 싶다면 간단히 수정해보아도 공부하는데 도움이

 될듯하다.

 기본적으로 소스에서는 IDF를 log2 ( N / DF )로 계산하고 있다.

#!/usr/bin/perl

use strict;

open(IN, "document.txt") or die;
my $nstory = -1;
my @words;
my %granddict;
my @weight;
my @unit;
my $i;
my $j;
my @cosine;
my $word;
my $sum;
my $df;
my @tf;
my $n;
my %df;
my $len2;
my $len;

#Step 1: Compute the term frequencies

while(<IN>){
    chomp;
    my $title;
    if ( /<TITLE>(.*)<\/TITLE>/ ){
        $title = $1;
        ++$nstory;
        print "Title of story $nstory = $title \n";
    } else {
        $_ = lc;
        s/--/ /g;
        s/ - / /g;
        s/[,.";!()?:_\[\]]//g;
        s/\s+/ /g;
        s/^\s+//g;
        @words = split(/ /);
        foreach $word (@words){
            if ($word =~ /^;?(.*?)'?$/){
                $word = $1;
            }
            ++$tf[$nstory]{$word};
            ++$granddict{$word};
        }
    }
}

foreach $word (sort keys %granddict ) {
    $sum = 0;
    for $i ( 0 .. $#tf ){
        if ($tf[$i]{$word} > 0){
            ++$sum;
        }
        $df{$word} = $sum;
    }
}

$n = $#tf + 1;
foreach $word (sort keys %granddict){
    for $i (0 .. $#tf){
        $weight[$i]{$word} = $tf[$i]{$word}*log($n/$df{$word})/log(2);
    }
}

for $i ( 0 .. $#tf ) {
    $len2 = 0;
    foreach $word ( sort keys %granddict){
        $len2 += $weight[$i]{$word}**2;
    }
    $len = sqrt($len2);
    foreach $word ( sort keys %granddict){
        $unit[$i]{$word} = $weight[$i]{$word}/$len;
    }
}

for $i ( 0 .. $#tf ) {
    for $j ( 0 .. $#tf ) {
        $sum = 0;
        foreach $word ( sort keys %granddict ) {
            $sum += $unit[$i]{$word} * $unit[$j]{$word};
        }
        $cosine[$i][$j] = $sum;
    }
}

print "\n";
for $i ( 0 .. $#tf) {
    for $j (0 .. $#tf) {
        printf "%.4f ", $cosine[$i][$j];
    }
    print "\n";
}

 참고로 소스의 출처는 Practical Text Mining With Perl 이란 책이다. 

 (저작권에 걸릴려나.. ) 

 책이 text mining에 관한 기초 실무로는 딱 좋으니 관심있는 분들은

 한번 보시라.

java class file structure analysis

ClassFile {

  u4 magic;

  u2 minor_version;

  u2 major_version;

  u2 constant_pool_count;

  cp_info constant_pool[constant_pool_count-1];

  u2 access_flags;

  u2 this_class;

  u2 super_class;                                       

  u2 interfaces_count;

  u2 interfaces[interfaces_count];

  u2 fields_count; field_info fields[fields_count];

  u2 methods_count;

  method_info methods[methods_count];

  u2 attributes_count;

  attribute_info attributes[attributes_count];

}

jvm specification second edition에서는 클래스 파일의 구조를 위와 같이 표현해 놓았으며 이를 분석해 보면 다음과 같다.

u2 -> unsigned 2byte 

u4 -> unsigned 4byte

magic => 매직넘버 (일반적으로 0xcafebabe 인 고정값 ) 

minor_version => jdk의 minor 버전

major_version => jdk의 major 버전

constant_pool_count => 전체 constant pool의 개수를 나타내며 실제로 constant pool의 개수보다 1개가 많은 값을 가진다.

cp_info constant_pool[] => 실제 constant pool array를 나타내며 다음과 같은 종류가 있다.

cp_info { 

  u1 tag;

  u1 info[];

}

cp_info 의 tag 값이 constant type을 나타내며 각각의 type에 따라 info 에 나오 는 구조가 달라지게 된다.

access flag => class 의 접근자를 나타낸다.

this_class, super_class => class의 이름. 다만 여러 상수값들은 전 부 constant_pool 에 저장되어 있으므로 실제로는 constant_pool의 특정 index값 만을 가지고 있다.

interface_count => 클래스 파일이 implements를 사용한 경우 interface의 개수를 나타내게 된다.

interfaces[] => 실제 인터페이스 정보를 가지는 구조체

Constant Type                                  Value

CONSTANT_Class                             7

CONSTANT_Fieldref                          9

CONSTANT_Method ref                   10

CONSTANT_Inter faceMethod ref   11

CONSTANT_Str ing                            8

CONSTANT_Integer                           3

CONSTANT_Float                              4

CONSTANT_Long                              5

CONSTANT_Double                          6

CONSTANT_NameAndType          12

CONSTANT_Utf8                               1

fields_count => 이후에 나올 클래스 멤버 변수등의 field의 개수

field_info fields[] => 실제 필드 정보를 가지는 구조체가 되며 field_info의 구조 는 다음과 같다.

field_info { 

  u2 access_flags; 

  u2 name_index; 

  u2 descriptor_index;

  u2 attributes_count; 

  attribute_info attributes[attributes_count];

} 

field_info 는 변수에 대한 접근자, 이름, descriptor 등을 가지며 실제 필드의 내

용은 attribute_info 형태로 저장되어 있으며 attribute_info 에는 여러 종류가 있다.

attribute_info { 

  u2 attribute_name_index;

  u4 attribute_length; 

  u1 info[attribute_length];

}

attribute_info.attribute_name_index 는 attribute의 종류를 나타내며 attribute의 종류는 다음과 같다.

SourceFile , ConstantValue, Code , Exceptions , InnerClasses, Synthetic , LineNumberTable, LocalVariableTable, Deprecated attributes

이 값들은 constant pool에 utf-8 형태로 저장되어 있으며 따라서 attribute_name_index는 constant pool의 특정 index를 가리키게 된다.

실제 kvm의 class loader의 경우 attribute의 type이 결정되면 결정된 type에 맞게 attribute_length 만큼 info[] 정보를 읽어들이게 된다.

method_count => method 의 개수.

method_info methods[] => 실제 method의 정보를 나타내며 method_info 의 구 조는 다음과 같다.

method_info { 

  u2 access_flags; 

  u2 name_index; 

  u2 descriptor_index; 

  u2 attributes_count; 

  attribute_info attributes[attributes_count];

}

access_flag => method 에 대한 접근자

name_index => method의 이름을 utf-8로 가지고 있는 constant pool에 대한 in dex

descriptor_index => method 구별을 위한 descriptor값을 utf-8로 가지고 있는 

constant pool에 대한 index (method의 return 값은 descriptor에 포함되지 않음

)

attributes_count 와 attribute_info의 경우에는 field_info 와 동일

attributes_count와 attributes[] 가 한번더 나오며 이는 클래스 파일에 대한 추가적인 정보를 가진다. 이곳에는 주로 Code attribute, InnerClass attribute, Deprecated attribute, Synthetic attribute, SourceFile attribute등이 나온다.

직접 간단한 클래스를 작성하여 위의 사항들을 확인해보자.

public class DefaultClass { 

  private int filed;

  public DefaultClass() {} 

  public void function() {}

}

위와 같은 DefaultClass.java를 컴파일한후 나오는 DefaultClass.class 파일을 바이너리로 열어서 확인해보면 다음과 같다.

0000000: cafe babe 0000 0032 0010 0a00 0300 0d07 .......2........ 

0000010: 000e 0700 0f01 0005 6669 6c65 6401 0001 ........filed... 

0000020: 4901 0006 3c69 6e69 743e 0100 0328 2956 I...<init>...()V 

0000030: 0100 0443 6f64 6501 000f 4c69 6e65 4e75 ...Code...LineNu 

0000040: 6d62 6572 5461 626c 6501 0008 6675 6e63 mberTable...func

0000050: 7469 6f6e 0100 0a53 6f75 7263 6546 696c tion...SourceFil 

0000060: 6501 0011 4465 6661 756c 7443 6c61 7373 e...DefaultClass 

0000070: 2e6a 6176 610c 0006 0007 0100 0c44 6566 .java........Def 

0000080: 6175 6c74 436c 6173 7301 0010 6a61 7661 aultClass...java 

0000090: 2f6c 616e 672f 4f62 6a65 6374 0021 0002 /lang/Object.!.. 

00000a0: 0003 0000 0001 0002 0004 0005 0000 0002 ................ 

00000b0: 0001 0006 0007 0001 0008 0000 0021 0001 .............!.. 

00000c0: 0001 0000 0005 2ab7 0001 b100 0000 0100 ......*......... 

00000d0: 0900 0000 0a00 0200 0000 0400 0400 0500 ................ 

00000e0: 0100 0a00 0700 0100 0800 0000 1900 0000 ................ 

00000f0: 0100 0000 01b1 0000 0001 0009 0000 0006 ................ 

0000100: 0001 0000 0009 0001 000b 0000 0002 000c ................ 

0000110: 0a .

이제 컴파일 후의 실제 class file 구조를 위의 스펙에 맞는지 확인해보자.

각각의 값은 다음과 같다.

MAGIC : cafe babe 

minorVersion : 0000 

majorVersion : 0031 

constantPoolCount : 001c (28) 

[constantPool] 

0.Method tag : 0a (10)   class_index : 0008  name&type_index : 0011 (17)

1.Class tag : 07 name_index : 0012 

2.Method tag : 0a (10) class_index : 0002 name&type_index : 0011 (17)

3.Method tag : 0a (10) class_index : 0002 name&type_index : 0013 (19)

4.Method tag : 0a (10) class_index : 0002 name&type_index : 0014 (20)

5.Method tag : 0a (10) class_index : 0002 name&type_index : 0015 (21)

6.Class tag : 07 name_index : 0016 

7.Class (22) tag : 07 name_index : 0017 (23) 

8.UTF8 tag : 01 length : 0006 bytes[length] : 3c 69 6e 69 74 3e

9.UTF8 <init> tag : 01 length bytes[length] : 0003 : 28 29 56 ()V

10.UTF8 tag : 01 length : 0004 bytes[length] : 43 6f 64 65 Code tag : 01

11.UTF8 length bytes[length] : 000f (15) : 4c 69 6e 65 4e | 75 6d 62 65 72 | 54 61 62 6c 65

LineN umber Table

12.UTF8 tag : 01 length : 0004 bytes[length] : 6d 61 69 6e main

13.UTF8 tag : 01 length : 0016 (22) bytes[length] : 28 5b 4c 6a 61 | 76 61 2f 6c 61 | 6e 67 2f 53 74 | 72 69 6e 67 3b | 29 56 ([Ljava/lang/String; )V tag: 01

14.UTF8 length bytes[length] : 000a (10) : 53 6f 75 72 63 | 65 46 69 6c 65 SourceFile

15.UTF8 tag : 01 length : 000e ( 14 ) bytes[length] : 54 65 73 74 44 | 72 69 76 65 2e | 6a 61 76 61 TestDrive. java

16.NameAndType tag: 0c (12) name_index : 0009 descriptor_index: 000a (10)

17.UTF8 tag: 01 length: 0008 bytes[length] : 54 65 73 74 54 | 68 69 73 TestThis

18.NameAndType tag: 0c (12) name_index : 0018 (24) descriptor_index: 000a (10)

19.NameAndType tag: 0c (12) name_index : 0019 (25) descriptor_index: 000a (10)

20.NameAndType tag: 0c (12) name_index : 001a (26) descriptor_index: 001b (27)

21.UTF8 tag: 01 length: 0009 bytes[length] : 54 65 73 74 44 | 72 69 76 65 TestD rive

22.UTF8 tag: 01 length: 0010 (16) bytes[length] : 6a 61 76 61 2f | 6c 61 6e 67 2f | 4f 62 6a 65 63 | 74 java/ lang/ Objec t tag : 01

23.UTF8 length bytes[length]: 000a (10) :70 7269 6e74 |53 7461 7274 printStart

24.UTF8 tag: 01 

length bytes[length]: 000a (10) :70 7269 6e74 |53 7570 6572 print Super

25.UTF8 tag : 01

length : 0003 bytes[length] : 41 64 64 Add

26.UTF8 tag : 01

length : 0005 bytes[length] : 28 49 49 29 49 (II)I

access_flag this_class super_class interfaces_count fields_count methods_count

: 0021 ( ACC_PUBLIC | ACC_SUPER ) : 0007

: 0008 : 0000 : 0000

: 0002 [Method#1]

access_flag: 0001 (ACC_PUBLIC)

name_index descriptor_index attr_count: 0009 : 000a (10): 0001 

attr_name_index : 000b (11) => "Code"

[Code Attr]

attr_length max_stack max_locals code_length code[code_length] : 2a b7 00 01 b1 exception_table_length : 0000 attr_count : 0001

[LineNumTable] attr_name_index : 000c (12) => "LineNumberTable" attr_length : 0000 0006 line_number_table_length : 0001 start_pc : 0000 line_number : 0012 (18)

[Method#2] access_flag name_index descriptor_index attr_count

: 0009 (ACC_PUBLIC | ACC_STATIC ) : 000d (13)

: 000e (14) : 0001

[Code Attr] attr_name_index attr_length max_stack max_locals code_length code[code_length]

10 0a | b6 00 06 57 b1 exception_table_length

: 0000

: 0000 001d (28) : 0001

: 0001 : 0000 0005

: 000b (11) => "Code" : 0000 0041 (65)

: 0003 : 0002

: 0000 0019 (25) : bb 00 02 59 b7 | 00 03 4c 2b b6 | 00 04 2b b6 00 | 05 2b 08

attr_count : 0001 [LineNumberTable Attr] attr_name_index : 000c (12) => "LineNumberTable" attr_length : 0000 0016 line_number_table_length: 0005

[ line_number_table[0] ] start_pc : 0000 line_number : 0016

[ line_number_table[1] ] start_pc : 0008 line_number : 0018

[ line_number_table[2] ] start_pc : 000c line_number : 0019

[ line_number_table[3] attr_count attr_name_index attr_length sourcefile_index

end of file

start_pc : 0010 line_number : 001b

[ line_number_table[4] ] start_pc : 0018 line_number : 001d

: 0001 : 000f (15) => SourceFile

: 0000 0002 : 0010 (16) => TestDrive.java

: 0a