Speakers Steve Wilson (Steve) and Blake Connell (Blake C)
Moderator Edward Ort (MDR-edO)
This is a moderated forum.
MDR-edO: Welcome to Java Live! Our topic today is the recently released J2SE version 1.3. Our guests are engineering manager Steve Wilson and product manager Blake Connell. They'll answer your questions about J2SE 1.3. So let's begin. Who has the first question?
Robert Burns: Does v.1.3 include JavaTM Sound? If so, can I use it to create VOIP applications?
Steve: Yes, J2SE 1.3 includes Java Sound. Java Sound includes support for digitizing and playing sounds, so it should be quite possible to build apps like voice over IP
Martin: now that 1.3 is out, what is the long-term future of Java in your eyes? - do you have plans for e.g. template or assertion support or things like that? - or is the main language fixed for all time? Thanks from Martin, a developer from Germany.
Steve: Yes, there are plans for both of these items...
Steve: We're looking at adding Assertions in J2SE 1.4. There is currently a JSR in the Java Community Process to develop this...
Steve: We're also looking at adding Generics support (such as templates). This is also in the Java Community Process...
Steve: I think if you look at java.sun.com/jcp you can find details on both of these.
test: When will a Solaris version of v1.3 be available?
Luke Burnham: Is 'Kestrel' and the new 1.3 release the same?
Steve: Yes, Kestrel is the code-name for J2SE 1.3.
Blake C: J2SE v 1.3 for Solaris will be available in Beta form by early next week (JavaOneSM). In addition, the Linux version will also be available for download. Both from the Java Developer ConnectionSM website.
Martin: Why was it necessary to remove the 1.3 beta for Solaris? - wouldn't it have been better to leave the production beta there, until the new "merged" beta is ready? For Solaris users, looks a bit strange now that Windows version is already finished.
Blake C: As you're aware, Sun is moving to a single J2SE release on Solaris (no more "Reference Implementation" and "Production Release"). We elected to remove the "old" 1.3 beta for Solaris as it did not include the new Java HotSpotClient VM or Java HotSpot Server VM...it had the older "Classic VM" with no JIT that was not very fast and ultimately was not going to be the VM we release. Keep in mind this is a one time issue, we are working to synchronize the 3 releases going forward (Solaris, Linux, Windows).
Robert Burns: I use JBuilder 3.0. Can I upgrade it to v.1.3 of the Java 2 SDK? Do you know if it's included in the new JBuilder 3.5?
Steve: I don't use JBuilder myself, but I know that Borland/Inprise has been working with 1.3. You should contact Inprise for questions on their products.
Daniel: I'm concerned that Java technology won't be able to keep up very long with the changing programming needs: today programs have much shorter life cycles than in the C/C++ era. RAPID APPLICATION DEVELOPMENT is needed and Java technology still follows the paradigm of declaring all variables. This may take up as much as half of the program. Strong type checking can be achieved with Type inferencing as well. Cutting down the length of the code is essential, I think.
Steve: Daniel, I fully agreed that RAD is important. However, I personally don't believe that the length of the code is a key issue. I think it has commonly be shown that most of development time is spent debugging (not actually coding). We don't have plans to support anything like "type inferencing" in the language. However...
Steve: We are working to support things like Assertions that allow people to build more robust code.
Steve: In addition, we are starting to put more emphasis on "tools support." We're trying to enable people to build better debuggers and profilers, as well as GUI builder tools (see the Swing Long Term Persistence work for this).
neeraj: What are the approximate timeframes for future releases and the accompanying major features? When will you make make the version jump to J2SE 2.0?
Blake C: We anticipate shipping the final release of J2SE v 1.3 for Solaris and Linux in the Fall. We'll then have a maintenance release in the first few months of 2001 and an upgrade release targeted for the end of 2001. The upgrade release is going through the new Java Community Process (JCP). We won't have a more accurate date until it winds it way through the JCP, including public review.
Daniel: Can you elaborate on Assertions?
Steve: Assertions are a construct that is commonly used in C programming. It allows you to state things in your code that must be "true." This allows you to detect failure conditions quickly. However....
Steve: Adding this kind of error checking to your code can be expensive. The cool thing about the new assertion mechanism is that it is implemented in such a way that when you "turn off" your assertions the JIT compiler can completely strip them from your code--eliminating any performance hit.
Chad: I downloaded the JRE HotSpot 1.3 client, but the readme still says it may not be redistributed. Can HotSpot 1.3 be redistributed for Windows?
Blake C: The JRE v 1.3 is freely redistributable (per the terms of the license) including the default Java HotSpot Client VM. In addition, you can optionally download the Java HotSpot Server VM, v 2.0 and redistribute the JRE with that JavaTM Virtual Machine1. The Server version is tuned for server-side applications. I'll revisit the readme to see if it's unclear.
test: Do you have any benchmark numbers that measure the performance of v1.3 vs. v1.2.2?
Steve: Sure. We've got lots of benchmark numbers...
Steve: We run benchmarks every night now to keep tabs on performance. I think we'll be announcing some "formal" numbers at JavaOne next week. However, informally we're seeing substantial improvements on both Server performance and Client performance. In some cases we're seeing 3x performance improvement in areas like scrolling.
neeraj: Steve mentioned JIT compiler in his answer regarding assertions. Is JIT still around in 1.3? Didn't HotSpot replace JIT?
Blake C: Java HotSpot VMs are essentially composed of two parts: the Java HotSpotRuntime, or base VM, and the Client or Server compiler. Java HotSpot uses different techniques than a simple JIT to increase either client or server performance. This includes adaptive optimization and more. Check out the documentation for the details on performance and Java HotSpot.
Charlie: What are the future plans for the XML/bean script serialization scheme by P. Milneon, the Swing connection, a.k.a. the "Archiver", which relies on JDK 1.3 enhancements?
Steve: Philip Milne's Archiver project is very active right now....
Steve: As with our other APIs, we're putting it into the Java Community Process. You can find more information about it on the JDC website. I believe this is tentatively scheduled for 1.4, but that is subject to JCP approval. I believe we'll be demo-ing some exciting stuff with the archiver at JavaOne. Check for the JavaBeans sessions.
Daniel: I would like to build a graphics application that needs to make thousands of calculations *very* quickly. I need to see the changes as they happen (not just the end result.) Do you really think that the OO paradigm and the new Java compiler technology is fast enough to do this, or do I need to "follow the crowd" and do this in C++?
Thalor: To avoid needing to declare data types in code, JPython 1.1 is available now from www.jpython.org, and if you want to optionally include parameter type info you can via @sigmethod signature declarations. It runs with Java 1.1 or 1.2 and is certified 100% pure Java. It transparently accesses virtually all Java methods, fields, classes, and objects. Give it a look.
Daniel: JPython is (to my knowledge) not statically (strongly) typed. Type inferencing allows compile time type checking through type inferencing. The problem with Python, Scheme/LISP is that I can get type errors at any time, unlike in the type inferenced ML programming language.
Steve: On purely compute intensive applications (like number crunching) HotSpot is really fast--even when compared with plain old C. We've been looking at some benchmarks posted recently by a consultant in the UK (I can't remember his name right now) where he's been coding some compute intensive tasks in C and the Java programming language. These are pure compute tasks like doing a Fibbonacci sequence. In many cases, HotSpot makes faster code than the compiled C.
Chad: Is it possible to run an application with HotSpot 1.3 client from a CD, that is, with all the code and the JRE on the CD with nothing installed?
Blake C: If I understand your question, yes, you can burn a CD with your Java applet or application and the JRE and redistribute it (for a fee or no cost).
Steve:
Steve: BTW, I've recently been working on a book about performance tuning your Java programs....
Steve: plugit's called JavaTM Platform Performance: Strategies and Tactics, ISBN 0-201-70969-4. It should be available next week at JavaOne. It's part of the Javasoft series of books.
Chad: Is there any thought of formalizing embedding COM/ActiveX components in Java applications?
Blake C: Sun produced a JavaBeans bridge for ActiveX Packager, which allows JavaBeans to be wrapped as COM objects. Third parties create a reverse bridge (COM to Java). Sun has not done much work on the JavaBeans bridge recently. We do have some work going on in this area on the J2EE platform. You might want to monitor the J2EE site for more information.
Daniel: I don't understand. How can an OO architecture be faster than an imperative programming language, such as C?
Steve: In general, the difference between static and dynamic compilation is important. Because HotSpot compiles code on-the-fly, there are optimizations it can do that may not be open to C compilers. For example, HotSpot can generate code for the specific chip you're working on (P, PII, PIII, or Ultrasparc vs. Ultrasparc II). There are also some other cool optimizations that are possible. In addition, HotSpot's memory management can be much faster in some situations than straight Malloc and Free.
test: I understand that there are some enhanced deployment options in v1.3 Is that true?
Blake C: Deployment options have been enhanced for Web browsing via Java Plug-in. Java Plug-in is included in the JRE and allows J2SE v 1.3 to work with IE and Navigator. New in 1.3 is significantly improved Applet Caching as well as Java Optional Package installation. Applet caching caches JAR files locally, Java Optional Package installation allows for the auto download of Java 3D, Java MediaFramework, XML or any other Java Optional Package. Also, look forward to Sun announcing a new way to deploy full standalone Java applications via a web browser next week at JavaOne.
Steve: I don't know how many people here are planning on attending JavaOne next week, but it should be a great time. I'm involved in three sessions about performance (I'm leading a panel discussion on Profiling tools on Tuesday, giving a session with Jeff Kesselman on Performance Tuning on Wednesday, and I'll be at the Performance BOF). I've looked on the JavaOne web site and there are dozens of sessions on performance tuning for those of you who are interested.
MDR-edO: There aren't many questions in the queue right now. So if you have a question for Steve or Blake, ask it now.
Daniel: Steve, you keep talking about C when comparing Java performance. What about C++? For a graphics intensive application this is the common choice for professionals. Can Java keep up? What do you think. (Please be as objective as possible!:)
Steve: In general I was talking about C because C++ is a superset of C. However, if you're talking about doing OO style tasks then HotSpot really shines. It can do things like "aggressive inlining." For example, in C++, if a method is marked as virtual then the compile MAY NOT inline that method for fear that an override of that method exists. However, HotSpot can try to inline virtual methods. If an override of that method is later found, then it can back off that optimization and recompile the method with less aggressive optimizations. It's a big advantage to doing your compilation at Run-time instead of build-time.
rickst29: Q1: Solaris SPARC availability hint (early June, later June)? Q2: Any known reasons NOT to migrate from 1.2.2-001 and 1.2.2-05 immediately? Sorry I'm late entering the forum, if these were already asked.
Blake C: A1: Solaris SPARC beta early next week available for download from the JDC. Target final release is September 2000. A2: Sun is making a large investment in the Java HotSpot VMs and that is just one reason to move to J2SE v 1.3.
pascal: I would like to know when the source code to J2SE13 is going to be released? Will the source code to the new Java compiler (formerly GJ) be included?
Blake C: To pascal: We will have the final J2SE v 1.3 source code available via SCSL by late June. The source to the Java compiler will be available.
novice: Hi there: I am just wondering whether Java SDK 2 has any class to convert image to GIF code and send out as output stream to the browser. I am new to writing servlets.
Steve: We have code to read GIFs, but not write them. The reason we don't have writing code has to do with licensing issues (the GIF format uses patented compression techniques). However, there are some alternatives. J2SE 1.3 does provide support for generating JPEG and PNG files. JPEG isn't great for line art, but is good for lots of things. PNG is better than GIF for most things and is supported in Netscape 4.x and IE 4 and 5 (I believe).
Martin: How is the status of Linux support for other platforms (non-Intel)? How about Macintosh (future: OS X) support, is it up to Apple alone?
Blake C: At present, Sun has plans to support J2SE on Linux on Intel x86 only. It seems likely that someday Sun would support a SPARC port, but that's TBD.Both Caldera Systems and the Blackdown porting team are working on ports to x86 and other chip architectures. There has been some great news with Apple recently as they will support J2SE v 1.3 on OS X on PPC.
MDR-edO: Unfortunately, Steve and Blake have a meeting they need to get to. So we'll have to end the session in another 5 minutes. If you have a question you'd like answered, please submit it now.
Chad: If you want to have an applet persist as if installed, can you package it as an Java Optional Package installation instead of creating an installed applet? If so, can you provide a URL? [Also pointers to information on how to install an "installed applet" appreciated]
Steve: An optional package isn't the way to go with this. Under J2SE 1.3, Java Plug-in supports sticky applets. You can add a part to the plug-in tags than defines how it gets stored on the machine (and how it gets updated). See the new Java-Plug in docs for details on this.
Steve: I'd like to thank everyone for coming. I hope to see you all all at JavaOne next week. It's going to be a great time!
Blake C: TO ALL: Thanks for participating. Please check out the J2SE site. Feel free to send comments to j2se-comments@java.sun.com.
MDR-edO: Sorry for the early end to the session. In any case, I'd like to thank all of our participants, and especially our guests Steve and Blake. Signing off.
MDR-edO: Last moderator (me) signing off. The forum is now unmoderated
_______
1 As used on this web site, the terms "Java
virtual machine" or "JVM" mean a virtual machine for the Java
platform.
Reader Feedback
Tell us what you think of this transcript.