Win a copy of Spring in Action (5th edition) this week in the Spring forum!

James Hart

Author
+ Follow
since Dec 17, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by James Hart

Originally posted by Stanley Tan:
James,
Isn't there some sort of code you can insert in your Web pages that will prompt the user to download the plug-in? I know HTML converter from Sun does this, but I can't remember if the process is seamless. (it's been a long time... )



You're right, there is - but it's not that widely used (Java developers, pay attention), probably because too many developers think of applet as a 1.1.8 platform, and just target the default JVM, rather than bothering with the plugin. Plus, it's a lot easier to use an <applet> tag - even the front page of java.sun.com does precisely that. Here's the full code, as recommended by Sun, for including an applet in your page in a browser-compatible way:
The following code is specified at the beginning of the <BODY> tag.
<pre>
<SCRIPT LANGUAGE="JavaScript"><!--
var _info = navigator.userAgent; var _ns = false;
var _ie = (_info.indexOf("MSIE") > 0 && _info.indexOf("Win") > 0
&& _info.indexOf("Windows 3.1") < 0);
//--></SCRIPT>
<COMMENT><SCRIPT LANGUAGE="JavaScript1.1"><!--
var _ns = (navigator.appName.indexOf("Netscape") >= 0
&& ((_info.indexOf("Win") > 0 && _info.indexOf("Win16") < 0
&& java.lang.System.getProperty("os.version").indexOf("3.5") < 0)
| | _info.indexOf("Sun") > 0));
//--></SCRIPT></COMMENT>
</pre>
The following code is repeated for each APPLET tag
<pre>
<SCRIPT LANGUAGE="JavaScript"><!--
if (_ie == true) document.writeln('
<OBJECT
classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width="200" height="200" align="baseline"
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<NOEMBED><XMP>');
else if (_ns == true) document.writeln('
<EMBED
type="application/x-java-applet;version=1.3" width="200" height="200"
align="baseline" code="XYZApp.class" codebase="html/"
model="models/HyaluronicAcid.xyz"
pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED><XMP>');
//--></SCRIPT>
<APPLET code="XYZApp.class" codebase="html/" align="baseline"
width="200" height="200">
</XMP>
<PARAM NAME="java_code" VALUE="XYZApp.class">
<PARAM NAME="java_codebase" VALUE="html/">
<PARAM NAME="java_type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="model" VALUE="models/HyaluronicAcid.xyz">
<PARAM NAME="scriptable" VALUE="true">
No Java 2 SDK, Standard Edition v 1.3 support for APPLET!!
</APPLET></NOEMBED></EMBED>
</OBJECT>
<!--
<APPLET code="XYZApp.class" codebase="html/" align="baseline"
width="200" height="200">
<PARAM NAME="model" VALUE="models/HyaluronicAcid.xyz">
No Java 2 SDK, Standard Edition v 1.3 support for APPLET!!
</APPLET>
-->
</pre>
Simple, huh?
On the other hand, a Flash movie is embedded like this:
<pre>
<object classid="clsid27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0"
width="900"
height="675">
<param name=movie value="mainindex.swf">
<param name=quality value=high>
<embed src="mainindex.swf"
quality=high
pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"
type="application/x-shockwave-flash"
width="900"
height="675">
</embed>
</object>
</pre>
So surely Java can be done more simply than it is.
Is it any wonder people use the <applet> tag, and just accept the default applet support?
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
[This message has been edited by James Hart (edited December 20, 2001).]
16 years ago

Originally posted by James Hart:
Generics is a proposed amendment to the Java type system that allows you to write classes in such a way that they can handle any kind of object in a type-safe manner.


By the way, (shameless plug) generics and JAXB are examined in the book, in the last chapter, which looks at the future of J2SE.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago

Originally posted by Stanley Tan:
I never really liked applets. I think they died a couple years back so its not really a big thing taking it out of XP. Besides, 1.1 is a dinosaur.


I think XP taking out that crippled MS JVM which only supported 1.1.8 may be the best thing that's ever happened to applets. If Sun can actually get the plugin rolled out properly, you won't have to write applets targetting 1.1.8 any more - you'll be able to target 1.3.1, maybe even 1.4.
The lack of Java 2 support in the default plugins has crippled applets. Now there is no default plugin on windows, you can actually expect users to go and download the real Java plugin. This is a good thing, right?
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago

Originally posted by David Garland:
Is it reasonably safe to install 1.4 now, or should I wait until it gets worn in a bit? Are the chances of breaking old code outweighed by performance enhancements? Would it be a bad idea to write something using 1.4 specific API this early?
Dave


The final 1.4 release should happen early next year. Once it comes out of beta, then you should really start to consider upgrading.
But in the mean time, you have nothing to lose from installing 1.4 in a separate directory and throwing together a little batch script that switches your JAVA_HOME and PATH variables between the two installations so you casn try it out.
There really are very few risks of breaking old code - see my post earlier in the thread, timestamped posted December 18, 2001 06:05 PM. What's more risky about moving to 1.4 is writing code that won't run on older systems.
One thing you might want to try is compiling your code using the 1.3 compiler and class libraries, but running it using the 1.4 JVM and libraries. That way, you get all the benefits of the improved performance, and you know your code will still work when deployed on 1.3 systems.
But I'd also advise people to move as fast as possible to developing on and for 1.4, and persuade your users, hosting providers, server administrators or whoever else you need to to upgrade as soon as possible.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago

Originally posted by FEI NG:
We all know you can't force you users to dnload the plug-in and if you do they will stay away! If you have a new project coming. Would you consider Applet? I think people will avoid it if they can.


Users only have to download the plugin once. It hasn't stopped people using Flash on their websites. What I think disappoints me most about the applet situation is that Sun doesn't seem to have managed to give applets the status of a plugged-in component. When I visit a web site that uses applets, I want a dialog to pop up (like it does if the site uses QuickTime, or Flash) telling me I need to download and install the Java plugin - and then the plugin installs (without asking me any questions about what I want installed), and the page works. The plugin should check for newer versions automatically whenever it's launched.
Of course, Sun should address download size, to ensure that they don't disrupt users' lives too much.
But for this to work, of course, there's got to be enough sites out there using applets that people realise they have to have the Java Plugin to be able to get the most out of the internet. IF everyone just says 'ah, applets won't work, nobody has the plugin', then nobody will use applets, so nobody will need the plugin.
There's a lot of competition out there. Flash is getting powerful nowadays - did you know it supports downloading of XML data now? - and there's also a lot you can do with Quicktime beyond just playing movies. Curl is an attempt to create a new client-side platform that's more suited to real applications than HTML. I think there's a lot of demand for powerful client-side technologies - and the applet already exists, can draw on a lot of skilled java programmers, and has all the power of J2SE.
Why should applets be dying?


Does Sun has any plan for that? is Web Star replacing applet? or ... ?


I don't think Sun see Web start as a replacement for the Applet. It's a complementary technology for web delivery, that gets applicaitons out of the browser window, and beyond the lifecycle of the page. But there's definitely still a place in the world for applets.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago

Originally posted by Jason Kilgrow:
What is/are "generics"? I am unfamiliar with that term/concept.


Generics is a proposed amendment to the Java type system that allows you to write classes in such a way that they can handle any kind of object in a type-safe manner. Take collections, for example. With Collections now, we have to write code like this:
<code>
List a = new ArrayList();
a.add("hello");
a.add("world");
String b = (String) a.get(0);
</code>
Now, there's an explicit cast in there, and that means this code isn't typesafe. It means we're making an assumption at compile time about something that will be the case at runtime - that the returned value from the List will be a String. Generics is a way of allowing the compiler to help us out with these sort of problems. In a generic compiler, you can write:
<code>
List a = new ArrayList<String>();
a.add("hello");
a.add("world");
String b = a.get(0);
</code>
Now, we're saying that we want the ArrayList to be an ArrayList of strings - so the compiler knows only to let us put strings in, and knows that values we get out will be strings already.
To use generics, you need to write classes in such a way that they're parameterizable. The early access release of the generics compiler, which you can get from Sun, comes with a generic collections library that you can compile code just like that shown above against.
The compiler writes standard bytecode, though, by inserting explicit casts. But the difference is, the compiler is guaranteed only to insert casts where it can guarantee they'll succeed.
It has the potential to radically improve the reliability of Java code, and allows you to reuse code much more efficiently.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago

Originally posted by Pauline McNamara:
Following up on your mention of that other book, which looks very tempting...
James, an editorial review at Amazon states that the OSX book covers "Developing enterprise applications on Mac OS X". Does this refer to J2EE? It's still not clear to me whether I have to use my Windows PC at work to learn J2EE.


The Sun J2EE reference implementation doesn't contain any natyive code, or any direct reliance on anything that's not in J2SE 1.3. That means you can get it running on a Mac OS X box. You can run Tomcat, MySQL, JBoss, IDEs like NetBeans - so certainly, there's nothing to stop you using a Mac OS X machine for enterprise development. I think it's ideally suited to the job.
The chapter on enterprise in the book covers issues like getting a working database and servlet container running on OS X.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago

Originally posted by David Garland:
Speaking of assertions being in/excluded in production versions, does anyone know how Java will handle this?


It's enabled on a package by package / class-by-class basis, using the JVM launch flag -enableassertions (or -ea for short).
You can enable assertions on all classes, or on a subset of classes, using a combination of -enableassertions and -disableassertions flags.
There's a programmatic API that enables you to enable assertions from inside a program - but whether assertions are enabled on a particular class or not is set at the time that class is loaded, and fixed from then on - it can't be switched later. You enable assertions for a class that hasn't yet been loaded by talking to the ClassLoader.

As for whether you turn them on at runtime or not, there's two schools of thought: one is that assertions should be used during testing to identify bugs and stop the program. The other is that assertions should be enabled at runtime, since they document exactly what the programmer thinks is going on at that point in program execution. If an assertion fails, it means the programmer was wrong - so the program should probably not carry on going.
If an assertion fails in your accounting software, like, say, after recording a balance transfer, you checked that the total balances of all accounts was the same - and it turned out not to be - then that means there's a bug in your program. Would you really prefer your accounts guy to carry on regardless under those circumstances? An assertion failure tells you the program is broken, and closes it down, putting a big sign on the door saying 'danger - do not enter'.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
[This message has been edited by James Hart (edited December 19, 2001).]
16 years ago
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"
16 years ago

Originally posted by Pauline McNamara:
James, how courageous of you to admit that deep down you're a Mac guy (in the Book Giveaway thread) in the midst of so many real computer geeks. "What no command line, that ain't a computer!"
As a Mac fan myself, I couldn't resist the urge to ask whether you've been able to mix your Mac leanings with your taste for Java.


Well, you've found out one of my other little secrets there...
The Wrox Early Adopter team keeps itself pretty busy. We just published Early Adopter Mac OS X Java, which I also wrote a chapter for (covering programming Cocoa with Java).
Some really good things about Java on Mac OS X:
The Aqua pluggable look and feel that makes Swing apps look just like they were designed for the Mac
Cocoa, the application programming library Apple inherited from NeXT. It's an objective-C API, but Apple have bridged it from Java so you can write Mac OS X applications in Java
JDirect, which is like JNI but with a fraction of the pain
And of course, the fact that it's a full J2SE 1.3.1 implementation, that means all your favorite classes are there for you to play with.
Oh, and you can get BBEdit for it, which is one of the best text editors on any platform. With a Mac that can do that, I'm VERY happy with my OS X 10.1 installation.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
[This message has been edited by James Hart (edited December 19, 2001).]
16 years ago

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"
16 years ago

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"
16 years ago

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
16 years ago

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"
16 years ago

Originally posted by James Brady:
[B]Regarding web start, do you know if its possible to launch an application from the browser which will allow a network connection (as client or server) to hosts other than the web server which served the web page initially ? ie. are there security restrictions on socket connections in this regard ?
B]


JNLP applications run inside a sandbox much like an applet does, and are, by default, restricted from accessing servers other than the one they came from. But if you sign your JNLP application's JAR files, and request an open application environment, then if the client allows it your code is run outside the sandbox in an unrestricted environment.
------------------
James Hart
Wrox
Author of "Early Adopter J2SE 1.4"
16 years ago