This Weeks Giveaway:

[Carl Trusiak]

This Week we are giving away four copies of the book
"Early Adopter J2SE 1.4".
And the best part... The Author James Hart is online to answer your questions!
Everyone give James a huge JavaRanch Welcome

Thanks to the people at Wrox Publishing for the books.
For details, check out JavaRanch Book Promotions

[Pho Tek]

Welcome James!
I've browsed my friend's copy of your book and one thing caught my eye - it's regarding the JAXP 1.1 integration into rt.jar. Could you refresh my memory on that item and why it is a problem with versioning for javax.xml.* extension ?
Oh wait! It's coming back to me - was your complaint about the fact that JAXP1.1 is integrated with SAX2 and DOM2. And the problem that it may cause for future development on DOM3 etc.. ?
Is there any workaround for this problem when deploying to J2SE1.4?
Thanks a lot.
Pho

[James Hart]

Thanks Carl,
Looking forward to answering everyone's questions and hearing their thoughts about J2SE 1.4 and the book.

------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
[This message has been edited by James Hart (edited December 18, 2001).]

[Fei Ng]

Welcome James,
Welcome to Javaranch and first i want to Congrats James on a well written book! 5 stars at amazon.
I always wonder whats new on 1.3 and 1.4 version of Java. It is always hard to keep up with the edge of technology. Especially, since there is not much changes enough. Now, we have a well written book on the subject and i think it is great.
James, what makes you write this book? It is becuase version 1.4 has undergone a good amount of changes? for good or ... ? What is the most important adds or changes on 1.4 compare to 1.2 or 1.3?

I feel silly asking this question but... what is your comment on j2ee and .net? or java with C#.
thanks.
I hope you have a good time on javaranch.

[James Hart]

Originally posted by Pho Tek:
I've browsed my friend's copy of your book and one thing caught my eye - it's regarding the JAXP 1.1 integration into rt.jar. Could you refresh my memory on that item and why it is a problem with versioning for javax.xml.* extension ?

Pho,
Good point. The issue is actually a much broader one than JAXP - it's really the wider problem of the inclusion in rt.jar of 'endorsed standards'. Inside rt.jar you have classes that fall really into four categories, now. There are the java and javax package families, which contain the classes and interfaces that make up the core Java platform. Then there's the com.sun, sun and sunw classes, which are the support classes that make up the Sun implementation of the Java platform on a particular platform. Then you have endorsed standards - that's strictly a set of interfaces that make up an industry sdtandard, and J2SE 1.4 includes four of those: DOM (org.w3c.dom), SAX (org.xml.sax), GSS (org.ietf.jgss) and CORBA (org.omg). Then you finally - and this is a new one for 1.4 - have non-Sun reference implementations: Crimson and Xalan, which are Apache products, and live in the org.apache hierarchy. You've also got the confusing state of affairs where org.w3c.dom is an endorsed standard, whereas org.w3c.dom.events, stylesheets, traversal, views and so on aren't endorsed - they are, however, in rt.jar, because they are required and used by Crimson.
Since the book was published, and shortly after beta 3 of J2SDK1.4 came out, Sun announced a new classloading protocol to allow for future changes in any of the endorsed standards. It's called the 'Endorsed Standards Override Mechanism', and it can be found at http://java.sun.com/j2se/1.4/docs/guide/standards/index.html. It allows JAR files containing new, updated versions of standards to be put in a certain directory (normally JAVA_HOME/lib/endorsed) and be loaded from this directory in preference to rt.jar.
There's still some real problems, I think, that this throws up, because you've got a lot of classes in there which are not meant to be for use by developers. For example, you can write code that uses DOM level 2 extensions, or that uses Xalan's XPath API, and it will compile and run fine against Sun's J2SE implementation, because these things are present in rt.jar. But that code isn't 100% pure Java, and it's not guaranteed to work elsewhere.
One way to solve that problem would be to have a compile-time JAR file (ct.jar?), accessed by javac, that ONLY contained the J2SE classes. The endorsed standards could be loaded from the lib/endorsed directory. Then, unless you explicitly included JAR files which provide additional functionality on the classpath, yoiur code won't compile unless it uses strictly J2SE classes.
I've also had some problems running Tomcat under J2SE 1.4, because of the way Tomcat loads XML parsers. Tomcat likes to keep a tight rein on which parts of the application have access to which parser, but the presence of a parser in rt.jar confuses matters terribly. IT seems to be necessary to remove crimson and/or xalan.jar files from Tomcat web applications running under J2SE 1.4, but I've not looked into what's going on there exhaustively.
Hope this answers your question. What does anybody else think about the increasing complexity of rt.jar?

[James Hart]

Originally posted by FEI NG:
Welcome James,
Welcome to Javaranch and first i want to Congrats James on a well written book! 5 stars at amazon.

Thanks

I always wonder whats new on 1.3 and 1.4 version of Java. It is always hard to keep up with the edge of technology. Especially, since there is not much changes enough. Now, we have a well written book on the subject and i think it is great.
James, what makes you write this book? It is becuase version 1.4 has undergone a good amount of changes? for good or ... ? What is the most important adds or changes on 1.4 compare to 1.2 or 1.3?

I think J2SE 1.4 represents a real commitment by Sun to make Java work as a client-side, GUI-application platform. You've got the client-hotspot VM in there, they've rearchitected Java2D, and done a lot of work on Swing, like making the Windows look and feel more like Windows 2000. Then you've got integration of Web Start, which I think is probably the most exciting thing to happen in Java development in a while. If Sun can push J2SE 1.4 onto enough desktops, then web start will become a genuinely usable deployment path for applications, and that's got to be a good thing.
There's nio - the new I/O architecture - which is a radical overhaul of one of Java's core library functions. I/O with nio is cleaner, and you can do a great deal with Buffers that you couldn't do cleanly with byte arrays.
The utility enhancements - regular expressions, preferences and logging - are all solid welcome additions to the platform. A lot of developers will probably upgrade to 1.4 for regex support alone.
Plus you've also got the first actual change to Java language syntax since Java 2 was introduced - the assert keyword. It's not much, but it certainly shows the language can evolve, incrementally, and that's also a good thing.
And then you've got the inclusion of a couple of old standard libraries into the platform: security, and of course XML.
Individually, all these sound like incremental improvements.
But if you think about the future of client applications, in a world where application functionality is accessed via web services, then a client platform with a fast GUI, deployable over the network using Web Start, with native XML support, fast networking and built in cryptographic functionality, is pretty much the definition of what you need. What Sun have created is a key component in a much bigger picture, and that's why I wanted to write a book about it, showing how these things come together to make something significant.

I feel silly asking this question but... what is your comment on j2ee and .net? or java with C#.

Not a silly question at all. I work full time at Wrox, on the Early Adopter team. I spend most of my time playing around with, and investigating, new technologies. I've been looking at .NET on and off for about a year now, and I'm actually just starting to look into VB.NET. But I'm a Java guy at heart (well, deep down, I'm actually a Mac guy), so I'm generally looking at .NET from a perspective of comparison - how does it differ from, how is it similar to, Java?
The main thing I can tell you now is that if you know Java you already know about 50% of what you need to know to understand .NET. That gives you a headstart over anybody coming from a COM/VB6/ASP background, who knows about 10% of it. The platform class libraries are very familiar if you've used Java, and C#, the language, is pretty much identical (or there's always J#). So, be grateful to Microsoft for creating .NET - they just enhanced the job prospects of anyone with a good knowledge of Java
How do they compare? I think we'll find that the .NET platform design is going to have made some of the same mistakes Java made in the past (Java built Swing to overcome AWT's shortcomings, nio to overcome io's shortcomings, etc.), so Java's maturity gives it a great headstart. But you've got to look at the way .NET handles XML, SOAP, web services, and ASP.NET - there's stuff in there that's beautifully put together, and I wish Java did it half as well. Still, with projects like JAXB, JAX-RPC, JavaServer Faces and so on underway, Java soon will.
I've got my opinions about C#'s language design as well, but this reply's getting long... perhaps another time

[Glenn Murray]

Originally posted by James Hart:
[...
I've got my opinions about C#'s language design as well, but this reply's getting long... perhaps another time [/B]

What's this, a teaser? After appreciating your mini-summary of .NET I'd really like to hear your thoughts on C#.
Glenn

[Dave Turner]

Originally posted by Glenn Murray:

What's this, a teaser? After appreciating your mini-summary of .NET I'd really like to hear your thoughts on C#.
Glenn

So would I!
Is it worth looking at as a serious alternative to java, or should i stick with Java?
Dave

[James Hart]

Originally posted by Dave Turner:
So would I!
Is it worth looking at as a serious alternative to java, or should i stick with Java?
Dave

Okay, okay! you asked for it...
My first take on C# was, I think like most people, 'hey! That's Java!'. But it's got a few little philosophical twists of its own, and it does a few things in a different way to that which seems 'natural' to a Java developer. I think it's going to cause a few problems for people who migrate in from a Java background if they aren't careful about how much of the similarity they take for granted.
There's things like the exception mechanism, which doesn't support checked exceptions - while a Java programmer will take it for granted that the compiler will inform you if you haven't caught an exception you should have, C# doesn't do that. Yet it has very similar exception handling and throwing syntax.
Then there's properties. If you have some code like this:
<pre>
Person a = new Person();
String b = a.name;
</pre>
A Java developer looks at that, and assumes that the name property is just a public field in the Person class. The a.name operation, to retrieve that value, will therefore be atomic, threadsafe, and side-effect free. But in C#, that bit of code might actually, depending on the implementation of Person, be calling into a property getter method - a method that might not be threadsafe, certainly won't be atomic, and may have side effects.
That makes me feel uncomfortable.
On the other hand, C# has enums, structs, and that primitive-type boxing thing that it does, which I'm still not entirely sure I like, but is definitely better than the messy primitive/Object divide in Java. These are all 'nice' linguistically, but they're not necessary.
Then it also makes use of some very ugly operator overloading conventions that just don't read right. For example, the += operator is used to add a listener to an object. +=, to me, means 'increment by', so its use in that context is jarring, and unintuitive.
But, in spite of all the 'discomfort' that C# causes me, I can read it, and understand it, and thanks to Visual Studio's IntelliSense technology, I can program in it, because VS does a good job of helping me work out what class I need to use, and what methods and properties are available on it. Compared to a language that's further removed, like Objective-C (which I had the misfortune to have to look at a lot of recently), C# is only a minor stretch from Java.
I think it's worthwhile Java developers familiarizing themselves with C# to a limited extent - getting to know how it does differ from Java. It'll stand you in good stead if you need to move to .NET because your job takes you there, or the money looks good.
What do people here think of .NET and C#?

------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[Jason Kilgrow]

Originally posted by James Hart:
Hope this answers your question. What does anybody else think about the increasing complexity of rt.jar?

It sounds to me like Sun is trying to be all-encompassing. I think the rt.jar should have the basic j2se stuff in it. I liked your idea of the ct.jar (compile time jar) or having some other way to configure javac to check other modules or maybe put the extensions in other jar/jars. What I don't want to see happen is Java going to bloatware. Keep it modular!

[ruilin yang]

It sounds a good book to have !
I like to know how much new compared with J2SE 1.3.
Thanks
Ruilin

[Gerry Giese]

ruilin, James basicly answered your question up above in the post dated "December 18, 2001 04:10 AM". Technically, the book covers everything that you're asking about - if you don't win a copy, go buy it and you'll get all the gory details.
James,
How much coverage is given in the book to the changes in the graphics and GUI arena? It's my understanding the JAI is being added, swing performance increased, and some new features like full-screen graphics modes are being added. In particular, are the performance increases due mainly to usng the NIO classes, or from deeper optimization and tuning analysis?

[Jason Kilgrow]

Originally posted by Gerry Giese:
ruilin, James basicly answered your question up above in the post dated "December 18, 2001 04:10 AM". Technically, the book covers everything that you're asking about - if you don't win a copy, go buy it and you'll get all the gory details.
James,
How much coverage is given in the book to the changes in the graphics and GUI arena? It's my understanding the JAI is being added, swing performance increased, and some new features like full-screen graphics modes are being added. In particular, are the performance increases due mainly to usng the NIO classes, or from deeper optimization and tuning analysis?

I've seen a swing gui run on 1.3 and the same swing gui run after been compiled/run with 1.4. Maybe it was just me, but it seemed like the gui app ran better and looked better when compiled/run with 1.4. Any thoughts on this? Should I see a noticable difference or was it just my imagination?

[Shane Roylance]

I have the upcoming task of converting our application, implemented in Java 1.3, to 1.4. Is there any difficulty in this? Is there any gotchas that I should look out for.

[James Hart]

Originally posted by Jason Kilgrow:
I've seen a swing gui run on 1.3 and the same swing gui run after been compiled/run with 1.4. Maybe it was just me, but it seemed like the gui app ran better and looked better when compiled/run with 1.4. Any thoughts on this? Should I see a noticable difference or was it just my imagination?

This is absolutely true - and remember, you're still using a beta of J2SE 1.4.
Sun have performed miracles on the graphics engine and managed to squeeze some massive performance enhancements out of the Java2D engine. According to their docs, the main thing they did was a lot of profiling work, that's eliminated a lot of redundant redraws.
I have actually started to use Forte properly since I got J2SE 1.4 - it's become usable thanks to Swing's performance improvements.
Try it - you'll like it.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[Jason Kretzer]

So does this mean that HotJava might actually correctly repaint when scrolling web pages? I would love to get rid of M$ IE for my day to day surfing.
-Jason

[Tom Ben]

Welcome James,
Nice review at Amazon by the way. I saw you mentioned WebStart while I have some what looked into that. Can you give a more in a nutshell description of it.
------------------
Sun Certified Programmer on the Java 2 Platform

[James Hart]

Originally posted by Gerry Giese:
How much coverage is given in the book to the changes in the graphics and GUI arena? It's my understanding the JAI is being added, swing performance increased, and some new features like full-screen graphics modes are being added. In particular, are the performance increases due mainly to usng the NIO classes, or from deeper optimization and tuning analysis?

I'll be honest, I wasn't able to give as much coverage to the detailed graphics changes as I'd have liked in the book. Graphics aren't a speciality of mine, and so GUI coverage is really limited to covering webstart apps, and the image I/O API.
There's more available. Offscreen drawing, full screen mode, and the ability to perform drawing operations on a headless system (one with no display). But there isn't that much there that affects the average developer, whose graphics programming tends to be at the swing component level or above.
So far as I'm aware, JAI (Java Advanced Imaging) is a specialized API, and isn't what has been incorporated into 1.4 - the Image I/O API that has been included is a separate development.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[James Hart]

Originally posted by Jason Kretzer:
So does this mean that HotJava might actually correctly repaint when scrolling web pages? I would love to get rid of M$ IE for my day to day surfing.
-Jason

Not tried HotJava in years - does it still exist ?
Give it a go - and let us know what happens.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[James Hart]

Originally posted by Tom Ben:
Welcome James,
Nice review at Amazon by the way. I saw you mentioned WebStart while I have some what looked into that. Can you give a more in a nutshell description of it.

Web Start's great. Well, to be more precise, JNLP - the Java Network Launch Protocol - is great, and Web Start is Sun's implementation of a JNLP client.
What it's about is taking the concept of applets - downloaded programs that execute inside a sandbox - and applying it to whole applications. How it works is neat. You click on a hyperlink on a web page in your ordinary everyday web browser, that points to a JNLP file. That's a special XML file containing information about how to run the application. The browser downloads the JNLP file, and hands it over to a local JNLP client to handle - just like, if you download a PDF, it hands it over to Acrobat to handle. Web Start is just such a JNLP client.
Web Start reads the JNLP file, which tells it where to get the JAR file or files for the application, and any other information it needs to run it. Web Start downloads the JAR files, fires up a JVM, and loads the application into it.
Web Start maintains a cache of applications you've accessed this way so you can start them up without downloading them again next time. It can also check to see if a new version is available and download it.
But the key user experience is clicking on a web page link starts the application - and it can be a full application, like a word processor, or a multimedia package, or anything you can write using J2SE.
It's powerful, and it's easy.
Web Start isn't the only JNLP client out there - there's also OpenJNLP and probably others. And the coolest thing about JNLP - at its most basic, the only server support it needs is a web server. Simple.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[Thomas Paul]

Originally posted by Gerry Giese:
How much coverage is given in the book to the changes in the graphics and GUI arena? It's my understanding the JAI is being added, swing performance increased, and some new features like full-screen graphics modes are being added. In particular, are the performance increases due mainly to usng the NIO classes, or from deeper optimization and tuning analysis?

Welcome aboard, James. I enjoyed reviewing your book for JavaRanch.
The above question is the one complaint that I had about the book. I thought too many pages were spent on XML (which can be found in many other books including books from Wrox) and not enough pages spent on discussing the AWT/Swing changes. Other than that it is a great book.

[James Hart]

Originally posted by Thomas Paul:
Welcome aboard, James. I enjoyed reviewing your book for JavaRanch.
The above question is the one complaint that I had about the book. I thought too many pages were spent on XML (which can be found in many other books including books from Wrox) and not enough pages spent on discussing the AWT/Swing changes. Other than that it is a great book.

I think you're right there - I could have looked more at the graphics side of things, and one thing I regret not having the time or space for is a good look at the printing service API. And I agree, the XML coverage could have been cut down. I made a call at the time to take the book one way, I could have gone another, and only readers can tell me if I made the right call.
My reasoning for including a chapter on XML was really that, looking at J2SE 1.4, XML is an important and significant addition to the platform - possibly the most important inclusion. But, as you say, it's been covered elsewhere, notably in two Wrox titles which I worked on, Professional Java XML and Java XML Programmer's Reference. However, where those two books were able to treat XML support as very much a pick-and-choose add-on to the Java platform, looking at every tool and API out there, in the J2SE 1.4 book I wanted to concentrate on letting developers know exactly what shade of XML support had been added to the core platform. In addition, I worked on the assumption that XSLT, a complete language which is now, I guess, a de facto part of the Java platform, was something that not all developers have already used extensively. But decisions like that are always a judgement call, and probably the hardest part of making books.
I'm interested to know, though - are XML and XSLT skills just an accepted part of being a Java programmer nowadays? Should I have assumed that readers of the book were already familiar with JAXP?
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[James Hart]

Originally posted by Shane Roylance:
I have the upcoming task of converting our application, implemented in Java 1.3, to 1.4. Is there any difficulty in this? Is there any gotchas that I should look out for.

Shane,
It's a point release, so your code should compile fine, and your classes all run. There's only a couple of areas that might cause you problems.
The assert keyword has been added, and that was never a reserved word. So if you've got a method or variable in your code somewhere called assert, you won't be able to compile it with the -source 1.4 flag. But it will compile by default - and the only reason to switch on the -source 1.4 flag is because your code contains assert statements. On the other hand, in the future, it's likely that 1.4 source compatibility will become the default, so you should probably start compiling with the source switch on to make sure you're not storing up trouble for yourself later on.
If you're reliant on any old third party XML parsers then you might have problems due to the endorsement of the SAX and DOM APIs.
A subtlety that I've run across only once, and not yet confirmed if it's a deliberate policy change, or an accident of history: in JDK 1.3, you can write:
<code>
import java.util.Date;
import java.sql.Date;
</code>
but JDK 1.4 doesn't seem to like this.
I've heard of some problems with JDBC code due to the fact that the JDBC 2 extensions have been incorporated into the platform - but that was back on beta 1, and may well have been resolved now.
So your code should work on 1.4. But then, depending on the kind of application it is, you may want to port some aspects to take advantage of new features, like nio, modified drag'n'drop, logging, preferences, and JavaBean XML serialization. In addition, you might find it useful to go back and add assert statements to your code to improve maintainability and to possibly even identify incipient problems that you've not yet detected.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[Doug Wang]

Originally posted by James Hart:
My reasoning for including a chapter on XML was really that, looking at J2SE 1.4, XML is an important and significant addition to the platform - possibly the most important inclusion.
I'm interested to know, though - are XML and XSLT skills just an accepted part of being a Java programmer nowadays? Should I have assumed that readers of the book were already familiar with JAXP?

Welcome, James.
I like the new J2SE's changes on XML. So I am delighted to see your book's chapter on XML. But Sun only integrate one part of their Java XML Pack into J2SE 1.4. I wonder that what maturity about the other parts of Java XML Pack when J2SE 1.4 is released?
Many people complains Sun's weakness at Web Services. What's your comments to that? Thanks.
Doug Wang.

[This message has been edited by Doug Wang (edited December 18, 2001).]

[John Raab]

Welcome James! I've messed around with the 1.4 beta, and am very excited about the new graphics api features, such as hardware accelerated image buffers. How long do you think until Java will become a decent platform for game development? C++/DirectX is quite complicated comparatively, Java would be a breath of fresh air when developing games.
thanks

[Stanley Tan]

James,
Hi. I too am a Java programmer at heart. But recently I've done a lot of .NET development with C# on a generic XML grid computing service. I've been using JDK1.3 for a while now but Java development is more on the server-side for me. I just don't see it as a good client-side solution even if you have already mentioned the enhancements. And I definitely don't see it as a "decent platform for game development" even with the full-screen mode addition. Am I still dazed from my experience with 1.3? How much faster really is 1.4 client-side apps especially when it comes to Swing?
Regarding C#, I think it's a very good language. As you've mentioned, C# doesn't have the "throws" clause which is very annonying. However, I like the fact that you can catch exceptions without specifying a variable name, since many times you don't even use it:
<pre>
try {
...
} catch (SomeException) {
}
</pre>
I also like properties, though I've noted this causes you a bit of discomfort. Boxing is another feature I like. And also, not to mention the way threads are started. You can specify the starting method of threads using a delegate. Very cool. Delegates, of course, are another very very cool thing.
However, I think my overall experience in .NET was superb because of VS.NET with it's powerful Intellisense. With VS.NET, building powerful XML Web Services becomes very simple. I can't wait to get the final version in Feb. But then again, Java still rules!! (At least for now...)
BTW, I feel that stressing XML in your book was not a bad decision at all Did you discuss Web Services ?

[Fabrizio Gianneschi]

James, what can you tell us about improvements of the String class in jdk 1.4? How much it depends on the regular expression-handling classes?
Thanks a lot
------------------
Fabrizio Gianneschi
Sun Certified Programmer for Java2 Platform

[Vladimir Ergovic]

I user JSSE with my 1.3, is there a big difference when using 1.4 integreted supprot and are there some advantages?

[James Hart]

Originally posted by Vladimir Ergovich:
I user JSSE with my 1.3, is there a big difference when using 1.4 integreted supprot and are there some advantages?

Well, your main advantage is you no longer need to deploy additional JARs with your application. So far as I'm aware, the integrated version of JSSE is exactly the same as the version that's been distributed separately. Except, of course, java.net.Socket now supports nio operations, so SecureSocket can be used with the new I/O APIs.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[James Hart]

Originally posted by Doug Wang:
I like the new J2SE's changes on XML. So I am delighted to see your book's chapter on XML. But Sun only integrate one part of their Java XML Pack into J2SE 1.4. I wonder that what maturity about the other parts of Java XML Pack when J2SE 1.4 is released?
Many people complains Sun's weakness at Web Services. What's your comments to that? Thanks.

The rest of the JAX Pack has a long way to go before it reaches maturity. JAXM and JAX-RPC need to settle their differences and agree on a clear differentiation of responsibility. JAXM needs to get off JAXB's turf, or share its work with it at least.
On top of this, you've got the fact that JAXR will be providing similar functionality to JNDI, JAXM to JMS, and JAX-RPC to RMI and CORBA - yet they'll have completely new APIs that won't necessarily make migration easy or even possible...
Right now, the JAX initiative looks like a furball, and that's partly down to Sun coming late to the web services game and playing catch-up.
IBM were the first to really push Java into the web sevices area, they produced SOAP4J which became Apache-SOAP - a combination of a server-side web service conbtainer, and a client-side SOAP-calling API. They also produced some great tools for working with WSDL. Obviously a lot of other organizations have done great work since - Glue springs to mind. But rather than taking advantage of this as a basis for further work, the JCP seems to be stuck trying to work out a functional spec for a web services client API, and struggling with the problem of how to add a web services container to J2EE.
It's frustrating, and it needs to move forward fast. The platform is getting left behind by reality at the moment.
We're expecting early access releases of the JAX Pack and/or the Sun Web Services Pack early next year, and that should tell us more about exactly where Java web services support is heading, and give us some idea of what will happen in J2EE 1.4 - supposedly the web services edition. That's one we've got a close eye on here in Early Adopter

[James Hart]

Originally posted by John Raab:
Welcome James! I've messed around with the 1.4 beta, and am very excited about the new graphics api features, such as hardware accelerated image buffers. How long do you think until Java will become a decent platform for game development? C++/DirectX is quite complicated comparatively, Java would be a breath of fresh air when developing games.
thanks

That's an interesting question. In principal, if you're talking about a very graphical game - 3D shoot 'em up or something - then you're going to want every ounce of performance in the graphics routines that you can get. For that reason, if you're talking about wanting to write code that's going to draw every pixel onto the screen itself, then Java's never going to cut it in comparison with a low level language that can use hardware accelleration and fool around with memory. But if the rendering is handled by a module that just draws what you tell it - and all you're planning on writing in Java is code that says 'put a cube here', 'put a green bug-eyed-monster here', and so on, then there's nothing to stop Java being used - and in fact, its clean object-oriented design probably makes a lot of sense for building games out of components.
If you think of a game using MVC architecture, the 'view' needs to be a fast rendering engine, that can present a series of images of the 'model' at a high framerate. But the 'controller' - the code that interprets user input and changes the model accordingly - that's well within the reach of Java code. I think Java has its place in describing game logic, physics models, and so on - but in terms of rendering to screen, you probably want to leave that to something that's talking directly to the hardware. And no matter how fast Java gets, I think that's always going to be the case.
Java3D is definitely a step towards a modular library that does exactly that - but as I remember, it sacrifices a lot of speed in rendering because the rendering engine keeps calling into Java code to find out what shape or color objects need to be - and that's something that shouldn't need to be described in code.
Speaking of games (of a completely different kind), by the way, has anyone here had a chance to play with RoboCode (http://robocode.alphaworks.ibm.com/)?

------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[James Hart]

Originally posted by Fabrizio Gianneschi:
James, what can you tell us about improvements of the String class in jdk 1.4? How much it depends on the regular expression-handling classes?
Thanks a lot

I think one of the most surprising things in JDK 1.4 is that the String and Thread classes have been changed - that's a pretty fundamental bit of messing around with Java's innards.
The String class has been tweaked in a couple of ways. It now implements the new interface, CharSequence, which has been added more or less purely to benefit the regular expression library. The other two classes that implement Charsequence are StringBuffer and CharBuffer (ChaBbuffer is one of the nio buffer types). So, this means you can write classes that interpret strings character-by-character, or substring-by-substring, to handle CharSequence objects, and you can automatically handle all three of these data types.
CharSequence defines four methods: charAt(int i), length(), subSequence(int start, int end), and toString(). Most of these were already in place in the String class anyway.
String also now has a split() method, which takes a regular expression as an argument, and returns a String array containing a sequence of substrings which were separated, in the original string, by substrings that matched the regex.
There's also a contentEquals(StringBuffer b) method that allows you to compare a String to a StringBuffer, which is handy.

------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"

[Rick Salsa]

Hi James,
A quick question for you. What are your thoughts on the new logging API in J2SE 1.4? Do you have any idea on how it compares to Log4J or other open source logging projects?
The table of contents on amazon doesn't list anything on this topic. Does your book touch on this at all?
Thanks,
-rick

[Fei Ng]

Hi James,
Another quick question, What is nio operations?
I have been reading your post! There seen to be a lot of changes.
Do you think a new Java version is coming up? Java 3?
thanks.

[This message has been edited by FEI NG (edited December 19, 2001).]

[Rick Salsa]

Hi Fei,
Congrats on the last week's book draw win!!. Nio stands for new I/O (Input/Output)API. There are a ton of improvements to it, mainly in the speed of the buffer management and file I/O (reading/writing.)
You can find out more about it at sun's site or in James book.
-rick

[Jason Kilgrow]

Originally posted by James Hart:
I'm interested to know, though - are XML and XSLT skills just an accepted part of being a Java programmer nowadays? Should I have assumed that readers of the book were already familiar with JAXP?

NO! I think XML is still underused and understated. I find myself wanting ever more exposure to XML and XSLT. I know that they do more than the little I know about them.

[Jason Kilgrow]

Originally posted by James Hart:
Speaking of games (of a completely different kind), by the way, has anyone here had a chance to play with RoboCode (http://robocode.alphaworks.ibm.com/)?

I installed RoboCode a couple of days ago. From the little bit I've played with it, it rocks! That's going to be fun and educational!
I haven't heard of it yet, but I'm thinking that battling robots via the web would be a cool project to work on.
[This message has been edited by Jason Kilgrow (edited December 19, 2001).]

[Fei Ng]

Originally posted by rick salsa:
Hi Fei,
Congrats on the last week's book draw win!!. Nio stands for new I/O (Input/Output)API. There are a ton of improvements to it, mainly in the speed of the buffer management and file I/O (reading/writing.)
You can find out more about it at sun's site or in James book.
-rick

thanks rick,
But i am not getting the book anytime soon, looks like they going to send it Not within a month. But i am NOT!! complaining.
carl did a great JOB!
1.4 sound really great !! From James and other ranchers!
It really feels like a new of Java.. New IO, web start, String.. etc etc..
Just passed the Java 2 Programmer Certification 2 months back, i wonder what will happen if Sun renew the version to java 3. If i have to retake the exam i don't really mind, i guess. Java 1.4 really sound a lot nicer and i am happy about it and excited about the new features.

sorry for off topic a little.

[JeanLouis Marechaux]

Welcome James.
of course I did not read your book yet, but I've seen there is a part dealing with "logging".
I was once said the J2SE 1.4 logging pattern is based on Log4J.
Is that true ?
Another question. Do you have any idea if Sun plan to release a Java 3 soon or do you think 1.4 is a the major release for a while ?

Thanks

[James Hart]

So, there's a couple of questions that have come up since I was last in here...
1) what's this new I/O API all about?
New I/O is about changing the focus of I/O away from streams of characters and bytes that you process byte by byte and line by line, to a new set of concepts: You've now got buffers and channels.
A buffer is like a big array of bytes, wrapped in a nice class that gives you access to loads of useful functionality, so you can manipulate and read data in the buffer.
A channel is a connection - to a file, or a socket - that can strip data out of a buffer, or pour data into one.
There are a lot of clever operations that this system makes possible - things like asynchronous reads and writes, scattering and gathering operations, and fast buffer copying.
2) Logging - is it in the book, and is it like Log4J?
There's an extensive section in the book covering the new logging API, in the chapter on utilities. It's covered along with the preferences API, and regular expressions.
As I understand it, from documents like http://jakarta.apache.org/log4j/docs/critique.html, the Log4J guys didn't think much of the new Java logging mechanism in its early stages. However, as http://jakarta.apache.org/log4j/docs/critique2.html shows, this has changed a lot as the new logging mechanism has taken on board such criticism, and the current version does indeed resemble Log4J architecturally.
Not having used Log4J myself, I think I'll leave discussion of the architectural differences to Ceki G�lc�'s analysis to describe - as the architect of Log4J he's in a far better position to do so
3) Is Java 3 on the horizon?
I don't think the platform is likely to move to 3 in the near future. the next J2SE version (Tiger) will, I think, be the Java 2 Platform, Standard Edition, version 1.5. Sun were pushing a roadmap last year that had 1.5 down at the end of 2002 - but I think that's been pushed back now, in the light of the delays to 1.4. But that said, there's quite a few things that just missed the deadline for 1.4 - JAXB, output formatting, generics, for example - so if they mature in the course of the year, I suppose it's perfectly possible for another release to follow much quicker than we'd normally expect. However, I'd expect the end of the year to be taken up with finishing of J2EE 1.4, and J2SE 1.5 will probably follow in 2003.
What will it take to justify the platform version moving up to 3? That's a good question. Maybe the introduction of a fundamental language change like generics is enough to justify it - maybe Tiger will be J3SE 1.5. But it's more likely going to take a fundamental rethink of the class libraries to justify that move.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"