원문 : http://www.infoq.com/news/2014/02/google-java-coding-standards

구글은 최근에 자바 코딩 표준을 퍼블리싱했습니다.
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html 에서 확인할 수 있으며

특징으로는

• 모든 소스파일은 UTF-8 인코딩으로 저장.
• import 구분에 와일드 카드(*)를 사용하지 않기.
• 오버로드는 순차적으로 기술하기.
• 내용이 비어 있거나 한줄 짜리 코드라도 중괄호 사용하기.
• 들여 쓰기에 2개의 화이트스페이스 사용하기.
• 열은 80 또는 100 자까지 가능.
• C 스타일 배열 선언 하지 않기.
• switch 문에 default 문을 누락하지 않기.
• 제한자는 Java 언어 사양에서 권장하는 순서로 작성하기.
• 상수의 표기는 CONSTANT_CASE 형식이며 모든 상수는 static final 로 설정함.
• 그렇다고해서 모든static final 이 상수를 의미하지는 않음.

들여쓰기를 공백문자 2개로 정의한게 조금 특이하네요.

log4j에서 제공을 하지 않는 기능과 다양한 장점을 가지고 있는 logback 도입을 검토.


http://beyondj2ee.wordpress.com/2012/11/09/logback-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0-reasons-to-prefer-logback-over-log4j/

 

java thread에서 Exception을 던져 쓰레드를 생성/실행한 곳에서 익셉션을 받아 처리하기위해서는 Thread.UncaughtExceptionHandler 를 이용해야한다.

다음과 같이 말이다.
[code]

//테스트용 쓰레드 생성.
Thread t = new Thread(
  new Runnable{
    @Override
    public void run() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            System.out.println("Interrupted.");
        }
        System.out.println("익셉션 발생 시킴 ...");
        throw new RuntimeException();
    }

  }
);
//Thread에 UncaughtExceptionHandler 를 설정.
t.setUncaughtExceptionHandler(
  new Thread.UncaughtExceptionHandler() {
    @Override
    public void uncaughtException(Thread th, Throwable ex) {
        //쓰레드에서 던진 예외는 이곳으로 오게됨.
        System.out.println("Uncaught exception: " + ex);
    }
  }
);
t.start();
[/code]

쓰레드와 익셉션 핸들링관련 도식은 다음과 같다.

스프링 프레임워크가 3.0이 출시되고 4.0으로 버전업 하기까지 4년 가까운 시간이 흘렀습니다. 스프링 프레임워크의 프로젝트 리더인 Juergen Hoeller는 그의 블로그를 통해 첫번째 마일스톤이 완성되었음을 알렸습니다.
첫번째 마일스톤의 결과물의 다운로드 링크는 아직 제공하지 않았습니다. 
스프링 4.0의 테마는 Java SE8(아마도 Open JDK 8 build 88 이후 버전을 base로 작업하고 있는듯) 과 Java EE 7의 지원과 몇가지 사용성 기능 추가로 보입니다.

Juergen는 JAVA SE 8에 대한 지원이 개발되고 있으며 JDK 8 developer preview의 출시에 맞춰 2013년 9월경에는 release candidate 출시를 예상하고있습니다. 올 9월에있을 SpringOne에서 소개할 예정입니다.

다음과 같은 Java se 8의 기능이 지원됩니다
JSR-335 Lambda expressions.
JSR-310 Date-Time value types for Spring data binding and formatting.
Support for the new 1.8 byte code format (람다 표현식 지원을 위해 필요).

다음 JEE 7 기능 지원도 포함됩니다.
JSR-343 JMS 2.0.
JSR-338 JPA 2.1.
JSR-349 Bean Validation 1.1.
JSR-236 Java EE 7 Enterprise Concurrency support.
JSR-356 Spring's WebSocket endpoint mode.


http://www.infoq.com/news/2013/06/Spring_Framework_4.0_Announced

오라클이 Java EE 7 출시 준비를 마치고 오는 6월 13일 온라인 웹캐스트 이벤트를 진행한다고 합니다.
9 a.m. PT / 12 p.m. ET / 5 p.m. London or
9 p.m. PT / 12 a.m. ET (Thursday) / 2 p.m. Sydney (Thursday)
라고 하니 우리나라 시간으로는 6월 13일 목요일 오후1시입니다.

이번 온라인 이벤트에서는

Business Keynote (Hasan Rizvi and Cameron Purdy)

Technical Keynote (Linda DeMichiel)

Breakout Sessions on different JSRs by specification leads

Live Chat

Lots of Demos

Community, Partner, and Customer video testimonials

들을 다룰 예정이라고 하며 온라인 사전 등록 페이지에서 자세한 내용을 확인하실 수 있습니다.
관심있으신 개발자는 등록하시고 들어보시는것도 나쁘진 않을것 같습니다.

저는 breakout session 에서 json, websocket 1.0 , servlet 3.1 에 눈길이 가네요.

아래 배너 클릭 하시면 등록페이지로 이동합니다.  

하이버네이트와 같은 OR매핑 도구를 이용하게되면 개발자가 SQL 를 작성할 필요가 없어지고 ( 물론, createSQLQuery() 메소드를 통해 native query를 작성할 수 있지만 이번글의 주제와는 조금 다른 이야기이니 제쳐두자. ) OR매퍼에서 생성된 쿼리가 실행되는데 MSSQL과 hibernate를 이용할때는 한 가지 특수한 상황에 맞딱드리게 된다.

바로 select lock.
MSSQL, Sybase, DB2는 여타 DBMS와는 달리 select 쿼리에도 row level lock ( 트랜젝션이 몰리면 이 lock도 에스컬레이션해서 row -> page -> table lock으로 범위가 확대 )을 거는데 일반적인 web application을 개발하는데 select lolock은 DB성능을 떨어트리는 원인이되기때문에 대게 select 쿼리에 각 테이블에 with(nolock) 힌트를 줘서 락을 걸지 않도록 처리한다.

이제 Hibernate로 돌아와서, hibernate에 의해  generate된 쿼리에는 with(nolock) 옵션이 기본 적용이 되지 않는다.  MSSQL에서 그냥 이용해도 하이버네이트 캐시시스템의 덕으로 문제가 발생하지 않을 수도 있지만 쿼리 실행 시 부하를 줄일 수 있는 방안이 있다면 적용하지 않을 이유가 없다.

이와 같은 내용은 검색 엔진에 hibernate mssql nolock 등의 키워드로 찾아보면 많은 결과를 확인할 수 있다. 그 중에 https://forum.hibernate.org/viewtopic.php?f=1&t=934158 의 쓰레드를 통해 확인한 방법은 다음과 같다.

[code]
session.connection().setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
[/code]

물론, MSSQL의 READ COMMITTED 격리수준 등 더 깊이있는 주제들도 있지만 내가 DB Geek도 아니고... 프로그래머 입장에서 요 정도까지만..

메이븐 플러그인을 통한 빌드 후 원격 디플로이
Tomcat 6
http://stove99.tistory.com/71


Tomcat 7
http://dasida.tistory.com/1055951

Java에 대해 잘못 알려지거나 java 5.0 이전의 정보로 현재의 java에서는 무용지물인 상식들이 몇가지 있는데 그런 종류의 상식에 대해 올바른 답을 전달하는 글이 있어 정리합니다.
원문은 http://java.dzone.com/articles/incorrect-core-java-interview 입니다.
 
Java의 인자 전달 방식은?
이 질문은 자바 태생과 함께해온 오랜 질문 중의 하나로 제 과거 포스팅 '자바는 call by value? call by reference?' 에서도 언급했던 내용입니다. 하나의 기능에서 또다른 기능, 혹은 subroutine으로 인자를 전달하는 방식은 pass by value와 pass by reference 두 가지 방식이 존재합니다만 java 세상에서는 pass by value 만이 존재할 뿐입니다. reference의 값(reference by value)을 전달할 순 있지만 reference 자체를 전달할 순 없습니다. java reference는 Call By Sharing 으로 설명되기도 하지만 일반적으로 쓰이는 용어는 아닙니다.

Garbage collection이란 무엇이며 어떻게 동작하는가?
일반적으로 알려진 바로는 '어떤 변수에도 할당되지 않은 Object를 가비지콜렉터가 메모리에서 정리한다' 이죠. 맞는말이긴 합니다만 조금 더 정확히 기술하자면 Root context로 부터 더 이상 strong reference 되지 않은 Object가 가비지콜렉터의 대상이 됩니다. weak reference 혹은 soft reference Object가 그 대상인거죠.

또한 System.gc()는 Full GC를 수행하라고 VM에게 힌트를 주는것이지  System.gc() 호출 시점에 GC가 수행되는것은 아닙니다. ( finalize 메소드의 오버라이딩을 자제해야 하는 이유. )

Transient 와 Volatile 접근 제한자는 무엇인가?
알려진 내용은 다음과 같죠.
Transient 접근 제한자는 Object를 직렬화(serialize)하여 다른곳으로 전송하거나 객체를 저장할 때 Transient 제한자가 적용된 변수는 저장되지 않는다.  Volatile 접근 제한자는 해당변수를 컴파일러에게 해당 변수가 다른 프로그램에 의해 불규칙하게 변경될 여지가 있음을 알려준다.
사실은 이렇습니다.
transient 접근제한자는 오직 feild (클래스변수)에만 적용할 수 있으며, 지역변수에는 적용할 수 없습니다. static 변수에도 적용할수는 있지만 그 기능은 무시됩니다. trensient가 적용된 변수는 serialized 되진 않지만 writeObject(), readObject() 같은 커스텀 serialization을 통해 직렬화 할 수 있습니다.
volatile 접근 제한자 역시 feild에만 적용할 수 있으며, compiler가 아닌 JIT 쪽에 필드값을 참조할 때 메인 메모리상의 필드값이 캐시(CPU의 L1,L2캐시)에 복사하도록(캐시를 갱신) 명시하는 역할을 합니다. 멀티쓰레드 환경에서 서로 다른 쓰레드들이 갱신되지 않은 캐시로 프로그램이 오작동 할 수 있는 부분에 적용할 수 있습니다.

Integer 클래스와 int 의 차이점은 무엇인가?
Integer는 java.lang 패키지에 정의된 클래스이며 int는 Java 언어 자체에 정의되어 있는 primitive 데이타 타입이다.
딱히 틀린말은 아니지만 조금 더 정확히 표현하면 Integer는 int를 싸는(wrap) 참조 객체(reference to an object) 이고 autoboxing, unboxing이 도입된 이후의 Integer와 int의 가장 큰 차이점은 Integer는 null일 수 있는것과 == 연산자에서 Integer는 reference를 비교하거나 warpping된 값(int) 를 비교하는것 입니다. 아래 코드를 보시죠
[code]
Integer i1 = 1;
Integer i2 = 1;
// autoboxing이 적용되어 int값 비교로 true 출력.
System.out.println(i1 == i2);

Integer i3 = 3000;
Integer i4 = 3000;
// autoboxing이 적용되지 않고 reference 비교를 하기때문에 false 출력.
System.out.println(i3 == i4);
[/code]
신기합니다. 두 Integer 객체 비교에 어떤 경우엔 true가, 또 어떤 경우엔 false가 됩니다.
이 문제의 비밀은 java실행 옵션에 있는데요. SUN/Oracle JVM의 경우 integer값을 캐시하는 기본 최대값은 127입니다. 즉 127이내의 Integer를 비교하면 autoboxing이 적용된 int를 비교하게됩니다. 물론 이 옵션은
 -XX:AutoBoxCacheMax= or -Djava.lang.Integer.IntegerCache.high=2000
과 같은 방법으로 변경할 수 있습니다.

Thread의 상태는?
Thread는 ready, running, dead 의 상태를 갖는다고 일반적으로 알려져 있습니다만 java 5.0으로 넘어오면서 Thread.State enum이 추가되면서
NEW : 쓰레드가 시작되지 않은 상태
RUNNABLE : JVM에서 쓰레드가 동작중인 상태
BLOCKED : block되어 monitor lock을 기다리는 상태
WAITING : 다른쓰레드가 특정한 행위를 수행할때까지 기약없이 대기하는 상태.
TIMED_WAITING : 다른쓰레드가 특정한 행위를 수행할때까지 약속된 시간까지 대기하는 상태.
TERMINATED : 쓰레드가 종료된 상태.
의 6가지 상태로 구분됩니다.

모든 클래스의 base 클래스는?
java.lang.Object
아마 모든 Java 입문서에 나와있는 내용일겁니다. 물론 일반적인 자바객체는 java.lang.Object를 상속하고 있습니다.
하지만 이는 custom class에만 적용되는 이야기입니다. int.class, void.class와 같은 primitive 타입과 Object 그 자체는 super class가 없습니다.
[code]
Class parent = boolean.class.getSuperclass(); // returns null
[/code]

Java Beans란?
java beans는 '다양한 환경에서 재사용이 가능하도록 디자인된 소프트웨어 컴포넌트이다.' 라고 설명 되기도 합니다. 하지만 Java Beans를 좀 더 구체적으로 설명하자면 '직렬화 가능하고(serializable) 인자없는 생성자를 가지며, getter ,setter 메소드를 통하여 프로퍼티에 접근 가능한 Java Object이다.'정도가 될것입니다.

synchronized block vs. synchronized method.
일반적으로 synchronized block이  synchronized method보다 lock을 거는 주기가 더 짧다고 알려져있습니다. 옳은 말이긴하지만 항상 그렇게 동작한다고 보증할 순 없는데요. 아래는 일반적으로 사용되고 있는 코드 예시로 synchronized block에 lock으로 this가 아닌 다른 object를 사용하고 있습니다. 이런 경우 synchronized block은 synchronized method로 lock을 걸게 됩니다. 결국 synchronized block으로 lock 영역을 줄인 의미가 없어지게 되는거죠.
[code]
Map<Key, Value> map = Collections.synchronizedMap(new LinkedHashMap<Key, Value>());
// perform multiple operations in a thread safe manner
synchronized(map) {
    Value value = map.get(key);
    if (value == null)
        map.put(key, value = new Value(key));
    return value;
}
[/code]

자바의 아버지 제임스 고슬링 아저씨가 구글로 그 자리를 옮겼다고 합니다. 뭐 썬이 오라클로 넘어가면서 자연스레 오라클 소속이 되었다가 작년에 그만두었죠(http://kldp.org/node/114063). 일년의 공백 후 구글로 입사한 거니 딱히 자리를 옮겼다고 표현하기에도 뭐하지만요. 오라클의 자바 및 오픈소스 지원정책에 불만이 있었기에 오라클을 그만둔 그의 다음 포지션을 많은 이가 궁금해 했을 겁니다. IBM 정도가 아닐까 예상했는데.. 구글로 가는군요. 구글의 비공개 직위로 간다는데 이게.. 오라클과의 특허 분쟁 방어용으로 가는건지 혹은, 자바나 또다른 언어를 위한 것인지는 아직 알려진 바는 없습니다. 그의 강연이나 이전까지 보여준 독설이나 자바 옹호 행위에서 느낀 것은 고슬링아저씨가 위대한 사람이긴 해도 성인군자 스타일은 아니란 거죠. 오라클을 엿먹이기 위해 구글과 손잡았을 가능성도 전혀 배제하진 못하겠네요. 그 정도 창의력이 있는 사람이라면 앞으로도 혁신적인 일로 인류에 공헌하면 좋겠어요.

java / jsp 개발 시 거의 보기 어려운 익셉션으로 대게 아래와 같은 익셉션을 출력한다.
[code]
org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: 3 in the jsp file: /src/test/test.jsp
Employee cannot be resolved to a type
1: <%@ page language="java" import="java.util.*,com.employee.*" pageEncoding="ISO-8859-1"%>
2: <%
3: Employee ddd = new Employee();
4: %>
[/code]

익셉션 출력물 그대로 jsp 파일을 .class 파일로 검파일 하지 못했다는 의미이다. 왜 그럴까?
예상하건데 첫 번째 라인의 import 내용과 3번째 라인의 클래스 생성코드를 삭제하고 실행하면 페이지가 열릴 것이다.
그럼, 이 예외상황은 import한 클래스를 찾지 못한 것인가? 그렇지 않다. import 가 잘못되었다면 NoSuchClassFound 같은 익셉션을 보게 될 것이다.

위와 같은 오류를 만나면 아래 jsp를 적당한 이름으로 저장한 후 컨텍스트 루트, 즉 WEB-INF 디렉토리가 있는 경로에 소스를 올리고 jsp를 호출해 보자.
[code]
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   <html>  
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
    </head>
    <body>
sun.boot.class.path : <%= System.getProperty("sun.boot.class.path") %>
sun.boot.library.path : <%= System.getProperty("sun.boot.library.path") %>
java.library.path : <%= System.getProperty("java.library.path") %>
java.class.path : <%= System.getProperty("java.class.path") %>
getClassLoader() : <%= this.getClass().getClassLoader() %>
DocumentBuilderFactory : <%= javax.xml.parsers.DocumentBuilderFactory.newInstance() %>
/javax/xml.parsers/DocumentBuilderFactory.class : <%= this.getClass().getResource("/javax/xml.parsers/DocumentBuilderFactory.class") %>
SAXParserFactory : <%= javax.xml.parsers.SAXParserFactory.newInstance() %>
/javax/xml/parsers/SAXParserFactory.class : <%= this.getClass().getResource("/javax/xml/parsers/SAXParserFactory.class") %>
TransformerFactory : <%= javax.xml.transform.TransformerFactory.newInstance() %>
/javax/xml/transform/TransformerFactory.class : <%= this.getClass().getResource("/javax/xml/transform/TransformerFactory.class") %>
<hr>
Servlet : <%= application.getMajorVersion() %>.<%= application.getMinorVersion() %>
JSP : <%= javax.servlet.jsp.JspFactory.getDefaultFactory().getEngineInfo().getSpecificationVersion() %>
ServerInfo : <%= application.getServerInfo() %>
RealPath : <%= application.getRealPath("/") %>
ContextPath : <%= request.getContextPath()%>
<hr>
totalMemory : <%= Runtime.getRuntime().totalMemory() %>
maxMemory : <%= Runtime.getRuntime().maxMemory() %>
freeMemory : <%= Runtime.getRuntime().freeMemory() %>
<hr>
    </body>
</html>
[/code]
위 소스를 실행하면 몇몇 중요한 정보를 얻을 수 있는데 그중에 request.getContextPath() 값을 한번 확인해 보자.
개발 시 의도했던 컨텍스트 루트가 아닐 가능성이 크다.
컨텍스트 루트가 의도했던 루트와 다르다면 웹서버든.. WAS든 host 설정과 관계된 설정파일을 보면서 해당 문제를 교정하면 된다.
원인은 컨텍스트가 다름으로 인해 import한 클래스를 클래스로더가 찾을 수 없어 발생하는 현상이다.

한가지 팁이라면 톰켓 + 가상호스트로  구성한 웹 어플리케이션의 컨텍스트 루트가 / 라면  [CATALINA_HOME]/conf/Catalina/[HOST_NAME]/ROOT.xml 의
Context 항목의 docBase는 "[웹어플리케이션경로]/ROOT" 와 같이 설정되어야 하고, 웹어플리케이션의 또한 [웹어플리케이션경로]/ROOT/  아래에 배포되어야  한다.

최근에 오라클에서 Java 6 update 21 을 발표했습니다. 이번 버전에서 java.dll의 변경된 사항으로 인해 이클립스 구동에 영향을 미치게 되었다고 합니다.

변경 사항은 JDK의 개발사 정보를 기존 "Sun Microsystems, Inc." 에서 "Oracle Corporation" 으로 수정한 것인데요 이클립스의 경우 Sun JRE 에 있는 non-standard 실행 옵션 중의 하나인 -XX:MaxPermSize 적용 가능 여부를 java.dll의 제조사 정보 문자열의 "Sun Microsystems"로 구분하고 있다고 하네요. 실제로  -XX:MaxPermSize 옵션을 지원하지 않는 몇몇 JVM에 해당 옵션을 적용하면 이클립스 구동이 실패한다고 합니다. 이클립스 런처는 Windows에서 실행되는 SUN VM인 경우 자동으로 -XX:MaxPermSize=256m 옵션을 적용한다고 하네요.

JVM 의 Vendor 정보를 변경한 것으로 영향을 받는것은 비단 이클립스 뿐만이 아닐겁니다.
http://www.excelsior-usa.com/blog/excelsior-jet/apps-will-stop-working-under-oracle-jre/ 에서와 같이 System.getProperty("java.vm.vendor") 값으로 무언가를 처리하는 모든 어플리케이션이 영향을 받을 수 있습니다.

JAVA가 Oracle의 자산이 된 이상 개발사 정보를 변경하는 것을 뭐라고 할 순 없지만 기존에 개발된 어플리케이션에 미치는 영향을 생각한다면 오라클이 어떤식으로든 액션을 취하지 않으면 안될것 같습니다. Java 6u21에서 이클립스 구동이 실패한다면 당분간은 JDK를 Java 6u20으로 다운그래이드 해야할 듯 합니다.

제가 만든 서버에서 보낸 데이터가 xml 형식으로 바이트 스트림으로 해서 받는데 in.read로 받았더니 byte 버퍼에 태그단위로 하나씩 들어가는데다가 디버그해봤더니 in.read라는 문장은 받은 xml 태그 수만큼 반복해서 실행되고 전체 xml을 받아서 파싱하려고 Stringbuffer를 이용해서 append 하려고 했더니 이것도 안되네요..

안녕하세요 질문자님.
질문 내용을 제가 정확히 이해한 건진 모르겠습니다만 제가 이해한 내용은
보내는 서버 측에서는 예를 들어, "<tag>내용</tag>" 스타일의 문자열을  byte[]로 변환하여
outputStream.write( byte[] );
하고 있고 클라이언트 측에서는
[code]
while ((readLength = inputStream.read(input, 0, input.length)) != -1) {
    stringBuffer.append(  new String( input )  );
}
[/code]
과 같은 동작을 하고 있다고 생각이 됩니다.

질문 내용 중 ' in.read라는 문장은 받은 xml 태그 수만큼 반복해서 실행되고' 라고 하신 걸로 미루어보아 데이터는 정상적으로 들어오고 있다고 판단됩니다. 받은 데이터를 가공하는데 어려움을 느끼고 계신 건 아닌가 하는 생각이 드네요.

우선 작성하신 클라이언트 쪽이 서버에서 보내주는 xml을 다 받으면 while 문을 빠져 나오는지 확인해 보시고요. 정상적으로 while문을 빠져 나온다면 유입된 Data를 가공하는 문제가 될 거고 그렇지 않다면 서버 측의 outputStream 에 write() 하는 부분을 확인하셔서 stream을 확실히 끝내고 있는지 확인하셔야 할 것 같습니다.

참고로 제가 작성한 소스를 첨부합니다.
첨부한 소스는 xml 형식의 문서를 읽어들여 byte 형식으로 전송하여 수신부에서 file과 문자열로 복원하는 코드가 작성되어 있습니다. Server.java 와 Client.java 는 일반적인 자바 bolocked Socket 프로그래밍 방식을 취하고 있습니다. 실제로 확인해야 하는 부분은 ByteArrayTransporter 클래스에서 클라이언트에 Data를 전송하는 부분과 Client 클래스에서 java.nio.ByteBuffer 를 이용하여 입력 데이터를 처리하는 부분 정도가 될 거 같습니다.

ByteArrayTransporter.java
[code]
   byte[] byteArray = new byte[1024];
   int readLength = 0 ;
   while ( (readLength = fileInStream.read(byteArray, 0, byteArray.length) ) != -1 ){
     out.write(byteArray, 0, readLength);
   }
   out.flush();
   out.close();  //<-- 스트림 끝내기
[/code]

Client.java
[code]   ByteBuffer bBuffer = ByteBuffer.allocate(102400);
   while ((readLength = bin.read(input, 0, input.length)) != -1) {   //byteBuffer에 byte[] 쓰기
      bBuffer.put(input, 0 ,readLength );
   }   //ByteBuffer 에 담긴 문자열 확인
   System.out.println( new String(bBuffer.array() , "UTF-8" ) );
[/code]

커뮤니티에 올라온 질문 중에 소수자리 숫자에 대한 덧셈 계산의 결과가 이상하다는 내용이 있어 정리해 봅니다.
질문에 올라온 코드는 아래와 같습니다.
[code]
double a = 35147.464;
double b = 73823.828;
double c= a+b;
System.out.println("a+b=" + (a+b));
System.out.println("c=" + c);

double d = 587350.504;
double e = 63354.488;
double f= d+e;
System.out.println("d+e=" + (d+e));
System.out.println("f=" + f );
[/code]

실행한 결과는 아래와 같습니다.
[code]
a+b=108971.29199999999
c=108971.29199999999
d+e=650704.992
f=650704.992
[/code]

왜 똑같이 소수점 세 자리 숫자를 더했는데 어떤 때는 소수점 아래 자릿수가 늘고 어떤 때는 세 자리로
출력되었을까요?

소수자리 숫자는 인간이 생각하는 10진수의 개념으로 접근 하면 안되기 때문인데요..
알고있듯이 컴퓨터는 0,1 로 모든 연산을 처리하는데 int, long 같은 정수라면 0,1로 표현할 수 있지만
float, double 같은 소수자리 수는 IEEE 754 표준에 의한 binary의 일부(fractions)로  표현하게 됩니다.
( http://www.math.byu.edu/~schow/work/IEEEFloatingPoint.htm 참조하시면 됩니다만 제게는 참.. 어렵네요.)
어쨌거나 저쨌거나 결과만 놓고 보면 '소수자리 숫자는 컴퓨터는 근사값 밖에 알 수 없다.' 인데요.

그럼, 저렇게 계산되도록 놔둬야 하느냐? 그렇지는 않습니다.
위 같은 경우는 DecimalFormat.parse() 메소드를 이용하면 됩니다.
맨 처음 코드를 아래와 같이 다시 작성해 볼 수 있겠지요.
[code]
java.text.DecimalFormat format = new java.text.DecimalFormat(".###");

double a = 35147.464d;
double b = 73823.828d;
double c= a+b;
System.out.println("a+b=" + format.parse( format.format(a+b) ) );
System.out.println("c=" + format.parse( format.format(c) ) );

double d = 587350.505d;
double e = 63354.491d;
double f= d+e;
System.out.println("d+e=" + format.parse( format.format(d+e) ) );
System.out.println("f=" + format.parse( format.format(f) ) );
[/code]


그럼 결과는 아래와 같이 원하는 대로 출력이 될 겁니다.
[code]
a+b=108971.292
c=108971.292
d+e=650704.996
f=650704.996
[/code]


한가지 유의해야 할 점은 저런 방식의 처리를 정확성을 요구하는 금융이나, 계측 분야에 적용 할 때는
계산결과의 정밀도가 충분히 받아들여질 만한 것인지를 다시 한 번 고민해야 한다는 겁니다.

금융과 같이 double이 허용하는 것보다 큰 숫자가 필요로 할 때는 BigDecimal을 이용해야 합니다.
( http://www.yunsobi.com/blog/227 BigDecimal의 필요성 참조 )

새로운 hotspot, UI 어플리케이션의 시작과 구동 성능 향상, 우분투 8.04와 레드햇 엔터프라이즈 리눅스 5.3 및
윈도우즈7 지원, 357개의 버그 픽스가 이루어진 sun java 6 update 18 가 출시되었습니다.
JavaSE 6 Update Release Note

엔터프라이즈 개발자가 특히 흥미를 가질만한것은 가비지 컬렉션의 성능 향상일듯합니다.
Garbage First(G1) 가비지 컬렉터( 드디어 experimental 딱지를 뗐습니다.)가 신뢰성과 성능에서 괄목할 만한
향상을 이루어 냈다는겁니다. 가비지 대상 수집 처리를 병렬화(Parallel Scavenger)하고 향상된 NUMA
( Non Uniform Memory Access ) 지원이 포함됩니다.
NUMA 아키텍처는 메모리에 액세스하는 방식 중 하나로 프로세스들은 서로 다른 메모리 영역에 엑세스하는데
동일하지 않은 시간을 소비하는 특징이 있습니다.

NUMA 아키텍처..

대부분의 현대적인 컴퓨터는 이 NUMA 아키텍처에 기반하고 있습니다. Java HotSpot VM에서는 NUMA 를 이용
할 수 있는 시스템이라면  -XX:+UseNUMA 플래그를 통하여 병렬로 가비지 대상을 수집할 수 있습니다.
이 옵션의 효과는 꽤나 훌륭해서 8코어 옵테론 시스템에서 측정한 SPEC JBB 2005  ( http://www.spec.org/jbb2005/index.html )
벤치마킹에서 32비트에서 30%, 64비트에서 40%성능 향상이 있었습니다.

데스크탑 어플리케이션과 Web Start의 업데이트 주요 항목을 보고있자면 썬은 데스크탑과 RIA 마켓도
무시하지 않고 있음을 엿볼 수 있습니다.
( 개인적으로 java가 이 두 영역에서의 그다지 큰 영향력을 행사하지 못할것 같다는 생각을 하지만요..)
 - 클라이언트 서버 양쪽 VM에 새로운 java heap configuration을 적용하여 가비지 컬렉션 성능 향상.
 - 빠른 시작을 위한 클래스로딩 최적화.
 - Direct 3D를 사용할 경우 시스템에 따라 100-200ms가량 어플리케이션 시작 시간 단축.
 - JavaFX 어플리케이션의 warm start 시 15%가량 빠른 구동.
 - Web Start와 애플릿의 jar파일의 동시 다운로드
 - Java Web Start 스펙 JSR-056 을 6.0.18로 버전업하고 다수의 버그 픽스.

이 외에도 다음과 같은 변화를 포함
 - jar 파일 생성시간 20% 단축
 - JavaDB 버전 10.5.3으로 업데이트
 - VisualVM 버전 1.2.1로 업데이트
 - StaX(Streaming API for XML) 마이너 업데이트

이번 버전에 보안관련 버그 픽스 사항은 포함되지 않았습니만 이번 분기에 발표 할 다음번 업데이트에
포함될것으로 예상하고있습니다.

http://blog.sdnkorea.com/blog/504

sqljdbc.jar
sqljdbc.jar 클래스 라이브러리는 JDBC 3.0을 지원합니다.
sqljdbc.jar 클래스 라이브러리에는 JRE(Java Runtime Environment) 버전 5.0이 필요합니다.
JRE 6.0에서 sqljdbc.jar을 사용하면 데이터베이스에 연결할 때 예외가 발생합니다.

참고: JDBC 드라이버 버전 2.0은 JRE 1.4를 지원하지 않습니다. JDBC 드라이버 버전 2.0을
        사용하려면 JRE 1.4를 JRE 5.0 이상으로 업그레이드해야 합니다.
        응용 프로그램이 JDK 5.0 이상과 호환되지 않아 다시 컴파일해야 하는 경우도 있습니다.  

sqljdbc4.jar
sqljdbc4.jar 클래스 라이브러리는 JDBC 4.0을 지원합니다.
이 라이브러리에는 sqljdbc.jar의 모든 기능과 함께 새로운 JDBC 4.0 메서드가 포함되어 있습니다.
sqljdbc4.jar 클래스 라이브러리에는 JRE(Java Runtime Environment) 버전 6.0 이상이 필요합니다.
JRE 1.4 또는 5.0에서 sqljdbc4.jar을 사용하면 예외가 발생합니다.

참고: 응용 프로그램을 JRE 6.0에서 실행해야 하는 경우에는 JDBC 4.0 기능을 사용하지 않더라도
        sqljdbc4.jar을 사용하십시오. 

http://msdn.microsoft.com/ko-kr/library/ms378422.aspx