자바로 로그에 대한 좋은 설명과 예제가 있었음

http://www.javapractices.com/Topic143.cjp

Home | web4j | Poll | Feedback | Source Code | Links

package myapp.business;

import java.util.logging.*;

/**
* Demonstrate Java's logging facilities, in conjunction
* with a logging config file.
*/
public final class SimpleLogger {

  public static void main(String argv[]) {
    SimpleLogger thing = new SimpleLogger();
    thing.doSomething();
  }

  public void doSomething() {
    //Log messages, one for each level
    //The actual logging output depends on the configured
    //level for this package. Calls to "inapplicable"
    //messages are inexpensive.
    fLogger.finest("this is finest");
    fLogger.finer("this is finer");
    fLogger.fine("this is fine");
    fLogger.config("this is config");
    fLogger.info("this is info");
    fLogger.warning("this is a warning");
    fLogger.severe("this is severe");

    //In the above style, the name of the class and
    //method which has generated a message is placed
    //in the output on a best-efforts basis only.
    //To ensure that this information is always
    //included, use the following "precise log"
    //style instead :
    fLogger.logp(Level.INFO, this.getClass().toString(), "doSomething", "blah");

    //For the very common task of logging exceptions, there is a
    //method which takes a Throwable :
    Throwable ex = new IllegalArgumentException("Some exception text");
    fLogger.log(Level.SEVERE, "Some message", ex);

    //There are convenience methods for exiting and
    //entering a method, which are at Level.FINER :
    fLogger.exiting(this.getClass().toString(), "doSomething");

    //Display user.home directory, if desired.
    //(This is the directory where the log files are generated.)
    //System.out.println("user.home dir: " + System.getProperty("user.home") );
  }

  // PRIVATE //

  //This logger will inherit the config of its parent, and add
  //any further config as an override. A simple style is to use
  //all config of the parent except, perhaps, for logging level.

  //This style uses a hard-coded literal and should likely be avoided:
  //private static final Logger fLogger = Logger.getLogger("myapp.business");

  //This style has no hard-coded literals, but forces the logger
  //to be non-static.
  //private final Logger fLogger=Logger.getLogger(this.getClass().getPackage().getName());

  //This style uses a static field, but hard-codes a class literal.
  //This is probably acceptable.
  private static final Logger fLogger =
                     Logger.getLogger(SimpleLogger.class.getPackage().getName());
} 

© 2006 John O'Hanley (Canada) | Source Code | Contact | Sponsor This Site | License | RSS

Over 53,000 unique IPs (and 106,000 sessions) last month.

- In Memoriam : Bill Dirani -

이번에 자바코딩을 하다가 제가 문득 잊고 사는 것을 하나 배웠지요.

하나는 바로 operator precedent (연산자 우선순위)구요.

저도 모르게 + 연산자가 우선순위가 높다라는 사실을 늘 잊어버린적이 많죠..  14개 연산자 등급중 4위라는 사실입니다.. ㅡ.ㅡ;

a & 0xFF00 >> 8 + 1* 2
=> 연산순서
(1)  1 * 2
(2)  8 + 1 * 2
(3) 0xFF00 >> 8 + 1* 2
(4) a & 0xFF00 >> 8 + 1 * 2

이렇게 됩니다.~

까먹지 않기 위해서 다시 공부합니다~

우선순위 연산자
1 . () []
2 ! ~ ++ --
3 * / %
4 + -
5 < < >> >>>
6 < &$60;= > >=
7 == !=
8 &
9  
10 ㅣ
11 &&
12 ㅣㅣ
13 ?:
14 = += -= * = /= %= &= = ㅣ= <<= >>= 

또 하나는 바로 쉬프트 연산입니다.
쉬프트 연산중 자바의 특성과 관련된 쉬프트가 있습니다. 즉, 최상위비트(Left Most bit )가 1일때 (즉, 음수) 쉬프트연산을 우측으로 할 지를 잘 결정해야 할 것 같더라구요.

즉,

 
shift는 총 3가지 종류가 있는데, left shift, right shift, zero fill right shfit가 있습니다.

-----------------------------

public class Shift {
    public static void main(String[] args) {
        int b, c;
        int a = 0xFF000000;
        b = a << 1;
        c = a >> 1;
       
        System.out.println("b:" + Integer.toHexString(b));
        System.out.println("c:" + Integer.toHexString(c));
    }
}

결과
b:fe000000
c:ff800000

------------------------------

public class Shift {
    public static void main(String[] args) {
        int b, c;
        int a = 0xFF000000;
        b = a << 1;
        c = a >>> 1;
       
        System.out.println("b:" + Integer.toHexString(b));
        System.out.println("c:" + Integer.toHexString(c));
    }
}

결과
b:fe000000
c:7f800000

c언어의 경우는 다음과 같이 테스트를 해볼 수 있지요.

int main()
{
    int b;
    int c;
    int a = 0xFF000000;
    b = a << 1;
    c = a >> 1;
   
    printf("b:%x\n", b);
    printf("c:%x\n", c);
}

b:fe000000
c:ff800000

근데 말이져..

c언어에서. 자바의 >>> 연산자가 따로 없는 듯 하네요... 저한테 c책이 없는데, 확인해 볼 길이 없네요.

즉, shift 연산을 할 때, arithmetic 값이 아닌, logical 값일때에 대한 shift는 c언어에서 따로 제공하는 것은 없지 않을까란 생각이 듭니다. 즉 c언어는 2의 보수표현의 arithmetic값에 치중되어 있지 않나 생각이 들어요.

예문을 보면, 원하는 것은 eF80000 값인데, 이 값으로 한번에 변환시켤 줄 수 있는 방법이 떠오르지 않네요. 늘, 코더가 저걸 생각하고, (a >> 1) & 0xeffffffff 이렇게 하는 수 밖에 없지 않나 생각드네요..

혹시 다른 방법 있으면 멀까요?

CRC-16/32

CRC(Cyclic Redundancy Check)는 시리얼 전송에서 데이타의 신뢰성을 검증하기 위한 에러 검출 방법의 일종이다.

간단한 에러 검출방법으로는 parity 비트에 의한 방법과 check-sum에 의한 에러 검출 방법이 있지만 parity 비트에 의한 방법은 데이타 중에 한꺼번에 2비트나 4비트가 변하게 되면 검출을 할 수 없고, check-sum에 의한 방법은 한 바이트에서 +1, 다른 바이트에서는 -1로 에러가 생기는 경우만 해도 에러는 검출 되지 않는다. 즉, 이들 방법으로는 에러를 검출해 낼 수 있는 확률이 대단히 낮다.

CRC에 의한 방법은 높은 신뢰도를 확보하며 에러 검출을 위한 오버헤드가 적고, 랜덤 에러나 버스트 에러를 포함한 에러 검출에 매우 좋은 성능을 갖는 것을 특징으로 한다.

이러한 CRC 방법으로 보통 2가지 종류가 사용 되는데, 원칩 마이크로 프로세서와 같이 간단한 용도에서는 CRC-16 이 사용되고, 이보다 더욱 정확한 에러 검출이 필요한 경우에는 CRC-32를 사용한다.

ZIP, ARJ, RAR 과 같은 압축 프로그램이나 플로피 디스크 등의 데이터 검증 용도에 널리 사용되고 있다.

기본 원리

n 비트의 주어진 정보가 있을 때, 이를 k 비트 만큼 자리를 올리고 미리 약속한 k 비트의 키 값으로 나누면 r 비트의 나머지가 남게 된다. 송신측에서는 원래의 정보 비트를 k 비트 자리 올린 것에 r 비트의 나머지를 더해서 n+r 비트의 데이타를 만들어 보낸다.
수신측에서는 수신된 n+r 비트의 데이타를 키 값으로 나누어 보고 나머지가 정확히 0 이 되는지를 검사하면 된다.

이 때 k 가 16 비트이면 CRC-16, 32 비트이면 CRC-32 가 되고 키 값으로는 수학자 들에 의해 정해진 값을 주로 사용한다.
CRC-16 에는 0x8005, CRC-32 에는 0x04c11db7 이 많이 사용된다. 그리고 r 비트의 나머지를 Frame Check Sequence(FCS)라고 부른다.

다항식 표현 방법을 통해 CRC 계산 방법을 살펴보자.

(1) 2진 다항식으로 표시

예) 비트열 101 --> 다항식 x² + 1

정보 다항식: 데이터 비트열의 다항식으로 P(x) = p_n x^n-1 + ... + p₃x² + p₂x¹ + p₁
CRC 다항식: CRC 생성을 위한 다항식으로 G(x) (미리 정해진 키 값)
몫: Q(x)
나머지: R(x)
전송 데이타: T(x)

(2) CRC 계산 방법

P(x)를 k 비트 만큼 자리를 올리고( P(x)에 x^k를 곱하는 것과 동일) G(x)로 나누면

x^k P(x) = Q(x)*G(x) +/- R(x) 이다.

(k는 CRC 다항식의 최고 차수)

R(x) = d_k x^k-1 + .. + d₂x¹ + d₁ ( R(x)의 최고 차수는 k-1)

비트열 d_k ... d₂ d₁ 을 FCS(Frame Check Sequence) 라 함

위 식에서 x^k P(x) + R(x) 는 Q(x)*G(x) 와 같다.

즉, x^k P(x) + R(x) 는 G(x)의 배수이므로 G(x) 로 나누면 나머지가 0 임을 알 수 있다.

결과적으로 전송되는 데이터 비트열 : p_n ... p₃ p₂ p₁ d_k ... d₂ d₁

즉, 전송 T(x) = x^k P(x) + R(x)

예) 데이터 비트열 110011 즉 P(x) =x⁵+x⁴+x¹+x⁰, CRC 다항식 G(x) = x⁴+x³+1, 즉 11001일 경우 FCS와 전송되는 비트열은?

x^kP(x) = x⁴ (x⁵ + x⁴ + x¹ + 1) = x⁹ + x⁸ + x⁵ + x⁴, 비트열로 표시하면 1100110000

                 100001
         _____________
11001 | 1100110000
           11001
          ____________
                   10000
                   11001
          ____________
                     1001    

x^kP(x) = Q(x)G(x) - R(x)에서

Q(x) = x⁵ + x⁰ 이므로,

R(x) = x³ + x⁰, ---> FCS는1001

따라서 전송되는 비트열 1100111001

연산의 최적화

CRC의 계산은 일반 나눗셈 명령을 이용해 구현할 수 없다. 1비씩 shift 하면서 XOR 연산을 통해 나머지를 구해야 한다.
하지만 정보 비트에 대해 하나하나씩 연산을 하는 것에는 분명 속도 개선의 여지가 있다.
실제 계산 시에는 모든 바이트에 대해 CRC 다항식에 대한 CRC 값을 계산해 표로 만들어 두고 들어오는 데이타를 인덱스로 삼아 계산 값을 바로 얻는 방법을 사용한다.

CRC-16 C소스 : crc16h.c
CRC-32 C소스 : crc32h.c

8051 어셈블리 CRC-8 소스 : 8051crc8.zip
8051 어셈블리 CRC-16 소스 : 8051crc16.zip

CRC(cyclic redundancy checking) : 주기적 덧(붙임) 검사

CRC는 통신 링크로 전송되어온 데이터 내에 에러가 있는지 확인하기 위한 방법 중의 하나이다. 송신장치는 전송될 데이터 블록에 16 비트 또는 32 비트 다항식을 적용하여, 그 결과로 얻어진 코드를 그 블록에 덧붙인다. 수신측에서는 데이터에 같은 다항식을 적용하여 그 결과를 송신측이 보내온 결과와 비교한다. 만약 두 개가 일치하면, 그 데이터는 성공적으로 수신된 것이며, 그렇지 않은 경우 그 데이터 블록을 재 송신하도록 송신측에게 요구한다.

ITU-T(이전의 CCITT)는 송신블록에 부가될 코드를 얻는데 사용되는 16 비트 다항식에 대한 표준을 제정했다. IBM의 SDLC와 다른 프로토콜들은 CRC-16과 다른 16 비트 다항식을 사용한다. 16 비트 CRC는 두 개의 비트가 동시에 에러가 난 경우를 포함하여, 일어날 수 있는 모든 에러에 대하여 99.998% 검출을 보장한다. 이 정도의 검출보증은 4 KB 이하의 데이터 블록 전송에는 충분한 것으로 평가되고 있으며, 그 이상의 대량 전송에는 32 비트 CRC가 사용된다. 이더넷과 토큰링 프로토콜에서도 모두 32 비트 CRC를 사용한다.

다소 덜 복잡하고 에러 검출능력도 다소 떨어지는 방법으로서 체크섬 방식이 있다. 이러한 방법을 사용하는 프로토콜 목록을 보려면 모뎀 에러교정 프로토콜을 참조하라

16비트 CRC 값 계산 코드

디바이스와 데이타를 교환하는 프로그램을 작성할 때 crc 체크가 제대로 되는지 확인하기 위하여 테스트용으로 16비트 crc 값을 생성하는 짧은 코드를 만들어 보았다. 사용 방법은 crc값을 만들고자 하는 데이타를 파일로 저장하고 아래 함수의 인자로 파일명을 전달해 주면 된다.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <conio.h>
 
unsigned int CRC16R(char data, unsigned int crc16);
 
void main(int argc, char *argv[])
{
        FILE *in;       
        //unsigned char data[250];
        unsigned char *data;
        long len,fl,i;
        int tc;
        unsigned char temp;
        
        unsigned int crc1,crc2,crc16;
        
        crc1=0;
        crc2=0;
        crc16=0xffff;
 
        if(argc<2){
                printf("usage : crc <filename>\n");
                return;
        }
 
        if((in = fopen(argv[1],"rb")) == NULL){
                printf("can't open %s\n",argv[1]);
                return;
        }
 
        // read from file
        fseek(in,0L,SEEK_END);
        fl = ftell(in);
        fseek(in,0L,SEEK_SET);
 
        data = (unsigned char *)malloc(fl);
        memset(data, '\0', sizeof(data));
 
        for(len=0;len<fl;len++) {
                tc = fgetc(in);
                if (EOF==tc) {
                        fclose(in);
                }
                data[len]= (unsigned char)tc;
        }
        
        data[len]='\0';
 
        // calc. crc
        for     (i=0;i<len;i++){
                temp = data[i];
                crc16=CRC16R(temp, crc16);
                printf("0x%2x, 0x%4x\n", temp, crc16);
        }
 
        crc1 = crc16 ＆ 0xff;
        if (crc1 <0x80) crc1 ^= 0xff;
        crc2 = ((crc16>>8)&0xff);
        if (crc2 <0x80) crc2 ^= 0xff;
 
        printf("crc16 is 0x%4x\n",crc16);
        printf("crc1 is 0x%2x\n",crc1);
        printf("crc2 is 0x%2x\n",crc2);
 
        free(data);
        getch();
}
 
unsigned int CRC16R(unsigned char data, unsigned int crc16)
{
        int i;
        unsigned int temp_crc16;
        unsigned char temp_data;
 
        temp_crc16 = crc16;
        temp_data = (unsigned char) data;
 
        temp_data <<=1;
        for ( i = 8; i > 0; i--){
 
                temp_data >>= 1;
                if ((temp_data ^ temp_crc16) ＆ 0x0001)
                        temp_crc16 = (temp_crc16 >> 1) ^ 0x8408;
                else
                        temp_crc16 >>= 1;
        }
        return(temp_crc16);
}

출처: http://home.dasomnetwork.com/~leedw

Checksum의 이용
컴퓨터 소프트웨어 분야에서의 "checksum"은 바이트 스트림에서 계산된 하나의 값입니다. checksum은 바이트의 signature, 다시 말해서 연산을 이용한 바이트들의 결합이라고 할 수 있습니다. 중요한 것은, 바이트 스트림에서의 변화와 변조가 높은 확률로 간파될 수 있다는 것입니다.

checksum의 예는 데이터 전송에서 찾을 수 있습니다. 어떤 응용프로그램이 100바이트의 정보를 네트웍을 통해 다른 응용프로그램으로 전달할 때, 그 응용 프로그램은 바이트의 값에서 계산된 32 비트 checksum을 추가합니다. 이 정보를 받는 쪽에서 이 checksum은 받은 100 바이트를 기초로해서 다시 계산됩니다. 수신하는 쪽의 checksum이 발신 쪽에서 보내온 것과 다르면, 데이터가 어떠한 방법으로 변조되었음을 알려줍니다.

checksum은 (전형적으로) 계산한 데이터보다도 훨씬 더 작습니다. 그렇기 때문에 대부분의 에러를 가려 내기 위해서는 확률적인 모델에 의지합니다. 바이트 순서에서 숫자를 계산하기 위해서 연산법칙이 적용되었다는 점에서 checksum은 해쉬 코드와 아주 유사하다고 할 수 있습니다.

java.util.zip.CRC32 클래스는 checksum 연산의 표준의 하나인 CRC-32를 구현하고 있습니다. checksum의 사용 방법에 대해서는 다음 응용프로그램을 보십시오.
텍스트 파일에 몇 가지 스트링을 입력하고 있으며, 이 문자열 리스트가 입력 후 변경되었는지 알고 싶은 경우, 예를 들자면, 누가 파일을 편집하기 위해서 텍스트 에디터를 사용했는지 알아 보고 싶은 경우를 생각해봅시다. 응용프로그램을 포함하는 프로그램이 여기에 두가지 있습니다. 처음 프로그램은 파일에 문자열 세트를 입력하고, 문자열에서 checksum을 계산합니다.

    import java.io.*;
    import java.util.zip.CRC32;

    public class Checksum1
    {
        // 파일에 기록할 이름들의 목록
        static final String namelist[] =
        {
            "Jane Jones",
            "Tom Garcia",
            "Sally Smith",
            "Richard Robinson",
            "Jennifer Williams"
        };

        public static void main(String args[])
                           throws IOException
        {
            FileWriter fw = new FileWriter("out.txt");
            BufferedWriter bw = new BufferedWriter(fw);
            CRC32 checksum = new CRC32();

            // 목록의 길이를 입력
            bw.write(Integer.toString(namelist.length));
            bw.newLine();

            // 각 이름을 기록하고 checksum 업데이트
            for (int i= 0; i < namelist.length; i++)
            {
                String name = namelist[i];
                bw.write(name);
                bw.newLine();
                checksum.update(name.getBytes());
            }

            // checksum 기록
            bw.write(Long.toString(checksum.getValue()));
            bw.newLine();

            bw.close();
        }
    }

이 프로그램의 출력은 "out.txt" 파일에 다음과 같은 내용물로 되어 있습니다;

    5
    Jane Jones
    Tom Garcia
    Sally Smith
    Richard Robinson
    Jennifer Williams
    4113203990

마지막 줄의 숫자는 스트링 문자에서 찾아낸 모든 바이트를 결합한 것을 계산한 checksum입니다.
두번째 프로그램은 파일을 읽습니다;

    import java.io.*;
    import java.util.zip.CRC32;

    public class Checksum2
    {
        public static void main(String args[])
                           throws IOException
        {
            FileReader fr = new FileReader("out.txt");
            BufferedReader br = new BufferedReader(fr);
            CRC32 checksum = new CRC32();

            // 파일에서 이름의 수를 읽어낸다
            int len = Integer.parseInt(br.readLine());

            // 파일에서 각 이름을 읽어내고 checksum을 업데이트
            String namelist[] = new String[len];
            for (int i = 0; i < len; i++)
            {
                namelist[i] = br.readLine();
                checksum.update(namelist[i].getBytes());
            }

            // checksum을 읽어낸다
            long cs = Long.parseLong(br.readLine());

            br.close();

            // checksum이 일치하지 않으면 에러를 출력하고, 그렇지 않으면 이름의 목록을 출력
            if (cs != checksum.getValue())
            {
                System.err.println("*** bad checksum ***");
            }
            else
            {
                for (int i = 0; i < len; i++)
                {
                    System.out.println(namelist[i]);
                }
            }
        }
    }

이 프로그램은 파일에서 이름의 명단을 읽어내고 이름을 출력합니다. "out.txt"를 텍스트 편집기로 편집하여 이름 중 하나를 바꾸면, 예를 들어서 "Tom"을 "Thomas"로 바꾼다면, 이 프로그램은 다른 checksum을 계산할 것이고, checksum 에러 메세지를 낼 것입니다.

이제, 누구든지 고의로 텍스트 파일을 변조 시키고, 새로운 checksum을 계산하고 그것 역시 변조시킬 수도 있다고 생각할 수도 있습니다. 이것은 사실상 가능한 일이긴 하나, 결코 쉬운 일은 아닙니다. 그것은 CRC-32 checksum 연산이 일반 사용자에게 그다지 쉬운 것이 아니고, 새로운 checksum 값이 무엇이어야하는지 계산하는 것이 어렵기 때문입니다.

checksum을 사용하는 또 다른 방법은 java.util.zip 에 있는 CheckedInputStream과 CheckedOutputStream 클래스를 사용하는 방법입니다. 이 클래스들은 입출력 스트림에서 실행되는 checksum 의 계산을 지원합니다.
　

출처 : http://www.javastudy.co.kr/docs/techtips/000411.html

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl

http://www.theserverside.com/news/thread.tss?thread_id=39606

http://www.cs.umd.edu/class/spring2006/cmsc433/lectures/threads2.pdf

See The JavaTM Virtual Machine Specification, 4.1 ClassFile.

================
A class file contains a single ClassFile structure:

    ClassFile {
        (...cut...)
        u2 minor_version;
        u2 major_version;
        (...cut...)
    }

The items in the ClassFile structure are as follows:

(...cut...)
       minor_version, major_version

       The values of the minor_version and major_version items are the minor and major version numbers of the compiler that produced this class file. An
       implementation of the Java Virtual Machine normally supports class files having a given major version number and minor version numbers 0 through
       some particular minor_version.

       If an implementation of the Java Virtual Machine supports some range of minor version numbers and a class file of the same major version but a higher
       minor version is encountered, the Java Virtual Machine must not attempt to run the newer code. However, unless the major version number differs, it will
       be feasible to implement a new Java Virtual Machine that can run code of minor versions up to and including that of the newer code.

       A Java Virtual Machine must not attempt to run code with a different major version. A change of the major version number indicates a major
       incompatible change, one that requires a fundamentally different Java Virtual Machine.

       In Sun's Java Developer's Kit (JDK) 1.0.2 release, documented by this book, the value of major_version is 45. The value of minor_version is 3. Only
       Sun may define the meaning of new class file version numbers.

http://www.kaffe.org/pipermail/kaffe/1999-March/088319.html