Sams Teach Yourself JAVA 6 in 21 Days,
Fifth Edition

By Rogers Cadenhead, Laura Lemay,

* Publisher:   Sams
* Number Of Pages:   720
* Publication Date:   2007-05-25
* Sales Rank:   41691
* ISBN / ASIN:   0672329433
* EAN:   9780672329432
* Binding:   Paperback
* Manufacturer:   Sams
* Studio:   Sams
* Average Rating:
* Total Reviews:

Book Description:
“If you get only one Java book, it should be Sams Teach Yourself Java in 21 Days” –PC Magazine
In just 21 days, you can acquire the knowledge and skills necessary to develop three kinds of programs with Java:
applications on your computer, servlets on a web server, and browser-launched Java Web Start applications.
No previous programming experience required. By following the 21 carefully organized lessons in this book, anyone can learn the basics of Java programming.
Learn at your own pace. You can work through each chapter sequentially to make sure you thoroughly understand all of the concepts and methodologies, or you can focus on specific lessons to learn the techniques that interest you most.
Test your knowledge. Each chapter ends with a Workshop section filled with questions, answers, and exercises for further study. There are even certification practice questions.
“Sams Teach Yourself Java is one of the best introductions to hands-on Java programming. If you buy one book on Java, this is the one to buy!” –Independent Web Review

* Completely revised, updated, and expanded to cover the latest features of Java 6
* Learn to develop standalone Java applications, web servlets, JavaServer Pages, and Java Web Start applications
* Easy-to-understand, practical examples clearly illustrate the fundamentals of Java programming
* Discover how Swing can help you quickly develop programs with a graphical user interface
* Find out about JDBC database programming, Internet client/server programming, and XML parsing with the open source XOM class library
* Covers new features of version 6 such as Java DB, the new relational database that is now a built-in
* part of Java
Rogers Cadenhead is a web application developer who has written 22 books on Internet-related topics, including Sams Teach Yourself Java 2 in 24 Hours. He maintains this book’s official website at http://www.java21days.com.
Laura Lemay is one of the world’s most popular authors on Web development topics. She is the author of the
bestselling Sams Teach Yourself Web Publishing with HTML, as well as Sams Teach Yourself Perl in 21 Days.

PDF | 5.45 MB | 721 Pages
Download
More Books here..

Over 350,000 BRAND NEW books are 50% OFF. Save on shipping too!

Recently we had a story which involved improving one of our data models. The table for the model had grown quite wide and we wanted to improve normalization and performance. We wanted to move a few columns from our original table (Listing) to a new table with the primary key of the new table (ListingLocation) also being a foreign key to the primary key of the original table, our one-to-one relationship. I will try to detail how we accomplished this change using a simplified example. Source code is linked at the bottom of this post.

Here is the entity relationship diagram of the old, single table structure:

And here is the entity relationship diagram of the new, two table structure:

As you can see, it is a very simple example of a very common relationship in the database. However, what we found when implementing this in Hibernate was not a simple as I had hoped.

To get started here is the SQL used to represent our new tables:

CREATE TABLE Listing
(
id BIGINT(20) NOT NULL AUTO_INCREMENT,
price DECIMAL(10,2),
PRIMARY KEY (id)
) TYPE = INNODB;

CREATE TABLE ListingLocation
(
listingID BIGINT(20) NOT NULL,
address VARCHAR(255),
PRIMARY KEY(listingID),
INDEX (listingID),
FOREIGN KEY (listingID) REFERENCES Listing (id)
) TYPE = INNODB;


I’ve used MySQL for this example because it is free and easy to setup. InnoDB table types have been because they allow foreign keys, which is crucial to this example.

Our old Listing entity was pretty basic; it looked something like this (imports & getters/setters excluded):

@Entity
@Table
public class Listing implements Serializable {
@Id
@GeneratedValue
private long id;
@Column(columnDefinition= "DECIMAL(10,2)")
private double price;
private String address;
...

In this case, creating a new instance of Listing and persisting it is very easy. When we split the entities, it becomes a little more complicated. Here is what our entities looked like after being split:

@Entity
@Table
public class Listing implements Serializable {
@Id
@GeneratedValue
private long id;
@Column(columnDefinition= "DECIMAL(10,2)")
private double price;
@OneToOne
@PrimaryKeyJoinColumn
private ListingLocation listingLocation;
...

and

@Entity
@Table
public class ListingLocation implements Serializable {
@Id
@Column(name = "listingID")
private Long id;
private String address;
...


The differences are not large, but there are a couple important points to note:

• Adding ListingLocation to Listing with @OneToOne & @PrimaryKeyJoinColumn annotations tells Hibernate the Listing has a one-to-one mapping with ListingLocation by using the Primary Key as the join column.
• Adding @Id & @Column(name = “listingID”) annotations to our id field in ListingLocation tells Hibernate that id is, well, an ID, but that column should not be called “id” in the DB, but “listingID” as that will help an observer see the relationship quickly without looking closely at the schema. Also, it is good to note that the @GeneratedValue is not on “id” in ListingLocation as it is in Listing as we want to specify exactly what goes in that field.

The biggest gripe I have with using the one-to-one relationship is that we can no longer save Listing only. Our REAL Listing entity is far more complex with several relationships, but this was the first one-to-one relationship with Hibernate. Previously we could do something like:

Listing listing = new Listing();
listing.setPrice(price);
listing.setAddress(address);
listing.setFoo(foo); // where foo is a @OneToMany annotated entity
...
session.save(listing);

Now, we must save Listing and ListingLocation separately like this:

ListingLocation listingLocation = new ListingLocation();
listingLocation.setAddress(address);
Listing listing = new Listing();
listing.setPrice(price);
listing.setListingLocation(listingLocation);
...
session.save(listing);
if (listing.getListingLocation() != null) {
listing.getListingLocation().setId(listing.getId());
session.save(listing.getListingLocation()); // save ListingLocation
}


I guess I’m just a bit spoiled, but I was hoping that this would bit more automatic, as it is with the one-to-many/many-to-one relationships.

I have written a small app that uses these two entities and inserts a row into each table, the link is available at the bottom of this post. The config (hibernate.cfg.xml) expects that you have MySQL running on 127.0.0.1 with a DB named ‘OneToOneDemo’ with a user named ‘root’ and a password of ‘password’; I have included the SQL (Setup-OneToOneDemo.sql) to setup the DB. Just extract the contents of the archive, navigate to the project directory, and from the command line/terminal run:

mvn clean compile exec:java -Dexec.mainClass=com.point2.onetoonedemo.App -e


You should see the following output:

@OneToOne @PrimaryKeyJoinColumn Hibernate Demo
----------------------------------------------
...
Hibernate:
insert into Listing (price) values (?)

Hibernate:
insert into ListingLocation (address, listingID) values (?, ?)
Saved listing ID: 1


Download Source Code (12 KB .ZIP)

If you have any questions, comments, or suggestions on how to do better accomplish one-to-one Hibernate mappings, I would love to hear about them. If you have any problems getting the code to compile and/or run, please let me know and I will make the necessary changes. Everything should just work, providing you modify the hibernate config or setup your DB. I had a difficult time finding complete and recent documentation on this subject so I hope this post and the maven project will help.

By: Damien Gabrielson

A very good summary of top 10 features of Java SE 6 by Sang Shin – Sun Microsystems Inc. : Java SE 6: Top 10 Features

Java 6 Platform Revealed

by John Zukowski

I am currently having to learn Java 6 to create a website for a job. After browsing through all of Hastings, Barnes and Noble’s, and Safari’s shelves I settled on “Sams Teach Yourself Java 6 in 21 Days”. This was the only book I found with a full chapter dedicated to communication between websites. So far I have completed up to Day 3, and have learned more about programming than three semesters of C++ in college. I recommend this to anyone that wants to learn a programming language.

(I originally planned this to be a single article, but because of the scope decided to split it into two parts. Read the first part for the the basics of using Sun’s HttpServer to conduct functional HTTP testing. Here we revisit our functional test and rewrite it using JUnit 4.7’s new Interceptors feature.)

Recap

In my previous post, I demonstrated how to use Sun’s HttpServer API to write a functional test of an HTTP ‘conversation’.

Recall that I thought my initial solution seemed inelegant. It was verbose, with some start up and shutdown code that would have to be repeated for each test, and which I felt cluttered the actual test code.

It was also tedious, in the sense that the raw HttpHandler and HttpExchange API required us to do quite a few things manually, and unintuitively (such as having to compute and write out the length of our response before the response itself).

In this post, we’ll explore how to use the new Interceptors feature ‘quietly’ released with JUnit 4.7 to write reusable, portable pre and post-test behaviour. I’ll also exhibit a convenient HttpHandler implementation that simplifies some of the effort required in responding to HTTP requests.

JUnit Interceptors at a glance

Developers familiar to JUnit will know that prior to JUnit 4.x, to perform pre/post test behaviour such as setting up and tearing down test scaffolding or external resources, we had no choice but to override TestCase#setup() and TestCase#tearDown(). To make this reusable across test classes, we had to extend TestCase and our actual tests had to extend that custom class.

JUnit 4.x introduced annotation-driven testing using the @Test annotation, which allowed us to write tests that were simple POJOs. However, this didn’t help when we wanted reusable pre/post test behavior. We still had to write our custom base class, this time with methods annotated with @Before and @After.

JUnit 4.7 introduces a new feature called “Interceptors” that aims to bring back to JUnit the ability to to ‘meta-testing’ with a much cleaner and simpler API. See Kent Beck’s¹ and David Saff’s² blog posts for more of the inside scoop.

Writing an Interceptor

A good place to start is to look at the source for ExternalResource.

If we need complete control over our interceptor’s behavior, we’d need to implement MethodRule from scratch.

In our case, we can get by simply by extending ExternalResource. We setup our HTTP server in the before() method, and tear it down in our after() method. We also provide a way to specify the port to listen on in our constructor:

Next, we provide a delegate method to register handlers:

Using Interceptors

To use our new JUnit interceptor, all we need to do is annotate a public field with the org.junit.Rule annotation. Note that the field has to be public—this might raise a warning if you use Checkstyle and personally, I wish JUnit would allow private @Rules.

The JUnit runner does the rest. It’ll transparently call our interceptor’s before() method, run the @Test then call our interceptor’s after() method.

Armed with this, we can rewrite the rest of our HTTP functional test as:

Simplifying our Handlers

We’ve managed to cut out some of our test scaffolding code. Now let’s simplify our actual handler. For this, I wrote SimpleHttpHandler, which is an HttpHandler which provides delegate methods to the actual HttpExchange. That is, by extending SimpleHttpHandler we can simply go getRequestURI() instead of having to go httpExchange.getRequestURI().

Additionally, SimpleHttpHandler uses an internal ByteArrayOutputStream, exposed via a PrintWriter in the getResponse() method. This lets us simply write our response as if, say, to System.out, and it takes care of computing the total response length later on when we call the sendResponse() method.

Here’s the same handler above rewritten using SimpleHttpHandler:

The complete source to HttpServerInterceptor and SimpleHttpHandler are provided as part of junit-rules, a ‘pet’ project I’ve made to explore and showcase JUnit Rules.

Hopefully, I’ll be able to add other, useful rules to junit-rules. Feel free to download, study and use it. Better yet, if you want to share any useful rules of your own, by all means, please fork or contribute to it!

(Edit 2009/10/16: Changed links/references to junit-interceptors to junit-rules, all because I misread Kent Beck’s post—they were renaming it to Rules from Interceptors, and not the other way around!)

References

¹ Interceptors in JUnit
² JUnit 4.7: Interceptors: expected exceptions

(I originally planned this to be a single article, but because of the scope decided to split it into two parts. This first part explores the basics of using Sun’s HttpServer to conduct functional HTTP testing. Part 2 revisits the following test using JUnit 4.7’s new interceptors (rules) feature and demonstrates a simpler HTTP handler.)

Forces

At work, we recently had the need to perform functional testing of a custom client that used HTTP as a transport. This isn’t strictly unit testing since we’re conducting actual HTTP over a socket & port instead of stubbing out or mocking the server, but in this case that was the only real way to test the client.

I could’ve fired up a standalone Web server and used that, but decided against it for a couple of reasons.

First, I wanted to have the server respond in a specific way to a particular client request. For example, if the request was for GET /1234.xml I might want to respond with an HTTP 200 and an XML response body. Another request for GET /0.xml might return an HTTP 404 instead.

To do that using, say, a Servlet container would mean writing multiple Servlets (mapped to various request URI) or a ‘rich’ Servlet with additional complexity. I didn’t want to have to write tests to test my test scaffolding!

Secondly, a standalone server would have to be started and stopped outside of our standard compile/test/package process (using Maven). Other people wouldn’t be able to run the tests successfully without having the test server up as well.

Clearly, the best way to go was to use an embedded HTTP server, which would allow us to provide specific responses tailored for each unit test.

As luck would have it, it turns out that Sun’s Java 6 implementation comes with a lightweight HTTP server API built in. Read on as I demonstrate the basic use of Sun’s HTTP server classes to write a functional test.

HTTP server in a box

The heart of our test solution involves taking advantage of the lightweight HTTP server API included in Sun’s Java 6 implementation. Note that since this isn’t part of the Java core API this package may not be available on all Java platforms. If this is a problem, you might be better off using another embedded HTTP server such as Jetty.

The class itself is com.sun.net.httpserver.HttpServer, and here’s how to use it in a nutshell:

1. Create the server
2. Create a server context and register a request handler
3. Start the server
4. Perform your test
5. Stop the server, and verify/assert your expected behavior

Now let’s look at each step in detail with corresponding code.

Create the server

We create an HttpServer using HttpServer.create(). To specify a port, we need to pass in an InetSocketAddress:

The second parameter to HttpServer.create() is the ‘backlog’, “the maximum number of queued incoming connections to allow on the listening socket”. Since that doesn’t really affect us, we can just pass in a 0 and a system default value is used.

Creating and registering a request handler

Now we get to the meat of actually stubbing our server’s behavior by creating and registering a request handler. HttpServer provides the createContext(String path, HttpHandler handler) method to do just that.

Now, HttpHandler is an interface which declares one method: handle(HttpExchange)

Obviously, HttpExchange is the class we need to work with when responding to HTTP requests. Let’s look at some code and I’ll explain what it does afterwards:

Basically: we convert our response string into a byte array. We send an HTTP 200 (OK) along with the number of bytes we’re about to send as the response body. We then write out the bytes of our response body, then close the HttpExchange. The complete HttpExchange life cycle is detailed in its API documentation.

We now create a context for the URI we’re interested in, passing in our newly created HttpHandler, then start the server:

At this point, an actual HTTP server will start running in a background thread ready to respond to requests. Let’s exercise our client code:

Our client code connects to our server, retrieves the associated URI, then, using a BufferedReader reads in lines from the input stream. We make a few JUnit assertions on what we received.

The only thing left to do is to stop our HttpServer:

The parameter is the number of seconds (NOTE: not milliseconds) to block to wait for our HttpServer to shutdown properly. Since we know we’re not serving any other requests, we can safely tell our HttpServer to shut down immediately.

At a glance

Here’s our functional test at a glance:

While functional, I find the above code rather verbose. If I want to write more HTTP tests, I certainly don’t want to keep repeating myself going httpServer.start(); … httpServer.stop(0);. I especially find it tedious to have to compute the length of the HTTP response body beforehand, then send it along with our HTTP response code before writing out the actual body.

In the next part of this article, we look at using some shiny new features in JUnit 4.7 that lets us write cleaner, more reusable tests that involve pre and post test behavior. Also, I’ll exhibit a helper class that simplifies some of the effort involved in implementing an HttpHandler.

Contrary to my regular habits, I bought the latest update to Mac OS X, “Snow Leopard” on the first day of release. Our local Apple store opened early (I think around 8-ish) on the 28th and I picked up my copy as soon as I saw the doors opened.

The truth is, since the days of the Amiga, I have not been as excited for an operating system release. My confidence in the quality that comes out Apple is also almost limitless, so I just popped the DVD into my computer and waited about an hour for the install to finish, hoping that there would be 7 GB magically reclaimed from my hard disk. I was wrong – it turned out to be a whopping 14 GB, which I thought was pretty impressive.

The next thing was for me to look for apparent problems, but apart from my “A Lot of Water” screen saver stopping to work (some changes to OpenGL in Snow Leopard might have caused this *sniff*), I did not notice any problems, just the “it just works” that I am used to from Apple. Well – until I started to do some development in Java. The Snow Leopard installation seems to remove  an installation of Java SE 5 and instead link the Java SE 6 version to it.

So what’s the problem, Java SE 6 is compatible to Java SE 5, some would say. Yes, almost. Unfortunately there are some incompatible changes in JDBC (in my case, the Connection interface) that requires me to work on a Java SE 5.

Luckily someone had the same problem and has published a solution for that problem: The bottom line is to download a Leopard version of Java 5 and redirect the symbolic links to that downloaded version.

After following the instructions, I could continue working on my Java project as before.

Update: I had another issue with maven even though I had already changed the version in Java Preferences. This could be fixed by adding a line

JAVA_VERSION=1.5

to the  ~/.mavenrc file.

Looks like the Ubuntu (jaunty amd64) build of Java 6 (1.6.0_13) has a problem closing files. Upgrading to 1.6.0_14 from karmic backports Works For Me.

Seems like it would be a big obvious bug, but I couldn’t find any reports. Have you run across it?

Java-kehittäjälle vuosi 2009 on kiintoisaa aikaa.

Viime vuoden puolella esitellyt uudistukset kuten Java 6 update 10 ja JavaFX pistävät uusiksi Java-sovellusten asennusta ja käytettävyyttä. Teemana on entistä kevyempää, helpompaa ja näyttävämpää. Selaimesta ruudulle ladattavat appletit, widgetit ja JavaFX sovelmat tuovat rikkautta käyttöliittymiin ja Web Start teknologian avulla Java-sovellukset saadaan helposti levitettyä työasemiin.
Tänä vuonna JavaFX-teknologia siirtyy myös mobiili- ja digitv-alustalle.
Ajan myötä näemme kumpi vetää enemmän, Google Android vai tuleva MIDP 3 + JavaFX -yhdistelmä. Molempia koodataan kuitenkin Java-kielellä.

Palvelinpuolella Java EE 5 -alusta auttaa suunnittelemaan ja toteuttamaan palvelinsovellukset entistä helpommin. Yksinkertaistunut EJB 3.0 -malli auttaa pitämään ylläpidon helppona. JavaServer Faces -tekniikalla saadaan web-käyttöliittymät koottua valmiskomponenteista entistä nopeammin. AJAX-piirteitä on rakennettu JSF-komponenttien sisään. Jos haluaa kattavamman AJAX-ratkaisun, Google Web Toolkit auttaa tekemään senkin ammattimaisesti.
Hype on vaimentunut Web Services -tekniikoiden osalta. Niitä käytetään integraatioratkaisuissa, joita tehdään organisaatioiden välillä.

Kestotrendejä myös Java-puolella ovat mm. Agile menetelmät kuten Scrum ja XP, sekä Test Driven Development (TDD), joilla pyritään pitämään ohjelmistoprojektien tavoitteet selvillä ja näkyvissä, kulut kurissa ja tuottavuus maksimissa mm. JUnit yksikkötestauksella.

Jos olet koskaan kokenut, että ohjelmistoprojektissa on turhia viiveitä, myöhästymisiä tai riskejä niin käy katsomassa miten homman voi tehdä järkevämmin.

Toukokuun Java One seminaarissa San Franciscossa on uusia julkistuksia, puheenaiheina mm. Java 7 uudistukset kuten Jigsaw moduulimalli sekä Java EE 6.0 standardi ja EJB 3.1.

Lisätietoja
Arto Santala, Tieturi Oy,  arto.santala@tieturi.fi

P.S. Nyt viimeistään on paikallaan päivittää osaaminen nykypäivän tasalle ja hakea sovelluskehitykseen tuottavuutta ja ryhtiä!
Valitse mielenkiintoisimmat kurssit www.tieturi.fi/java

Share on Facebook

We try to stay current with our technologies at Point2. An example of this is using the most recent Java platform, Java 6 (JDK 1.6) and modern IDEs such as NetBeans 6.5. However, staying up to date with technology is not always as simple as it could be. Java 6 was released in December 2006 and NetBeans 6.5 was released almost 2 years later in November 2008 and yet it still wants to use Java 5 (JDK 1.5) as the default Java Platform, regardless of what you have set in the OSX Java preferences. Here is how you can set NetBeans 6.5 to use JDK 1.6 by default.

• Ensure that JDK 1.6 and NetBeans 6.5 are installed
• Locate the NetBeans config file, typically located at “/Applications/NetBeans/NetBeans 6.5.app/Contents/Resources/NetBeans/etc/netbeans.conf” and open the file in your favourite editor
• Set the “netbeans_jdkhome” parameter to the JDK 1.6 home directory (ie. netbeans_jdkhome=
  /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home)
• In NetBeans, right click on the project in the project window and select “Properties”
• Ensure the “Source/Binary Format” is set to “1.6″
  
• Click on “Tools” on the toolbar and select “Java Platforms”
• Under “J2SE” the default platform should now be “JDK 1.6″
  

By: Damien Gabrielson

The title of this post is a bit misleading in that you apparently cannot run Eclipse on a MacBook Pro with Java 6 set as the default JDK.  Never mind that it took Apple a year and a half after the release of Java 6 for Apple to support Java 6 on OS X in the first place.  I thought Apple was “developer friendly”?  My experience on a Mac has usually been slightly better than working on a PC, except that the failings of a PC can usually be dismissed as Microsoft’s incompetence.  Apple seems to act more like a highly-opinionated jerk.

After I upgraded to Java 6 (and then had to manually change my JDK symlink even after the upgrade), Eclipse refused to start.  The system log showed:

[0x0-0xa90a9].org.eclipse.eclipse[4265]: _NSJVMLoadLibrary: NSAddLibrary failed for /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Libraries/libjvm.dylib
[0x0-0xa90a9].org.eclipse.eclipse[4265]: JavaVM FATAL: Failed to load the jvm library.

To resolve the issue, I edited /Applications/eclipse/Eclipse.app/Contents/Info.plist, and uncommented this line:

/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java

Problem solved.  Apparently Eclipse uses 32-bit SWT-Cocoa bindings, and Apple just decided that they weren’t going to support 32-bit SWT any more in Java 6, breaking any app that uses them in the process.  So the fix is to just run Eclipse under Java 5 (Java 6 projects still work in this setup).  I’m starting to lose track of the consumer-unfriendly attitudes I’ve experienced from Apple.  Their version of Java 6 is late, incomplete, and lazy.

I will declare this now – Apple is every bit as evil as Microsoft.  If Apple EVER gets the market share that Microsoft once held, Microsoft’s anti-trust violations will seem like trivial misdemeanors compared to what Apple would do with such power.  I need to gather my thoughts on this soon and elaborate on this point.

De las pocas cosas que me mantenían usando otro sistema operativo era que para OS X no disponía de java6, mientras que en Linux y Windows lleva un año mas o menos usandolo. Los usuarios de Mac OS X ya podemos descargarnos la versión 6 de Java en la web de Apple Development, más concretamente aquí.

Para mas información visitar http://developer.apple.com/java/

Nicht 3.14… , nicht 3 und auch nicht 42. Sondern 12 :

zumindest in den SGML-Klassen von Java6. Dort meint PI allerdings etwas anderes als die Zahl, nämlich eine Document Processing Instruction. Trotzdem lustig

Event: Sun Tech Days (Website)

Organized By: Sun Microsystems

Venue: Hyderabad International Convention Center

Key Dates:
Event: February 27-29, 2008

Sun Tech Days is a worldwide developer conference organized by Sun Microsystems. There are numerous opportunities at the Tech Days: developing skills in Web 2.0, sharing knowledge and growing network, participating in communities changing the face of technology.

Tech Days are one’s opportunity to hear from and meet with some of the brightest technology experts from around the world. It’s a chance to network with peers, understand more about what’s going on from Sun and the industry. Key Note speakers for the event are Rich Green, Ian Murdock, and David Axmark.

Tech Days travels the globe to share expertise with the community about Solaris OS, the Java EE, SE, and ME platforms, the NetBeans IDE, Sun Studio, Open Source and more.

(Fee Structure)

Subscribe to Gyaan RSS Feed here.
Subscribe to International RSS Feed here.
Subscribe to the combined Let Me Know RSS Feed here.

Obwohl wir seit Jahren erfolgreich JBoss einsetzen muss ich für einen neuen Kunden WebLogic von BEA testen. Der Kunde nutzt die aktuelle Version 10.0. Vorsicht: WebLogic 10.0 (veröffentlicht am 10.04.07) läuft nicht mit Java 6 (veröffentlicht am 11.12.06). Hm, das alleine ist zumindest merkwürdig. Neue Java Versionen sind in der Regel abwärtskompatibel. So läuft z.B. JBoss-4.0.2, der vor Jahren veröffentlicht wurde, problemlos mit Java 6. Richtig ärgerlich ist aber, dass in der WebLogic Dokumentation nicht darauf hingewiesen wird. Es gibt viele Megabyte Dokumentation zur Version 10.0, z.B. Installation Prerequisites mit System Requirements oder Supported Configurations for BEA WebLogic Platform 10.0 mit Hinweisen zu Betriebssystemen, Web Servern, Datenbanken und sogar Spring Versionen. Es gibt aber keine Hinweise welche JDK Versionen unterstützt werden. Nur indirekt wird darauf hingewiesen. Die WebLogic Server 10.3 Tech Preview unterstützt erstmals Java 6:

This Technology Preview includes select new features, standards updates and performance improvements. Version 10.3 TP remains fully Java EE 5 compatible and adds new support for Java SE 6.

Vielleicht ist es BEA etwas peinlich, dass ihr 10000$-Server sich nicht mir Java 6 verträgt. Ich habe einen ganzen Tag damit verschwendet die 10.0 mit Java 6 zu testen bis ich endlich den Hinweis gefunden habe.