The problem Sudarshan N. Mogasale reported whereby classes get to access the private members of other classes turns out to be a feature, not a bug, at least according to Sun. (I'm still not convinced.) Access protection is enforced by the byte code verifier which is turned off by default for classes loaded from the local file system. It can be turned on by using the undocumented -verify or -Xverify:all options to the java interpreter. For example,
D:\JAVA\private>java Outside
23
42
D:\JAVA\private<java -verify Outside
Exception in thread "main" java.lang.IllegalAccessError: try to access method
Inside.print()V from class Outside
at Outside.main(Outside.java:6)
As I originally suspected might be the case, this turns out to be a known bug in the Java Developer Connection Bug Database, specifically number 4030988. What I didn't suspect was that this was originally reported over three years ago against Java 1.1b3 and is "Closed, will not be fixed". (Side note: with over four million bugs in the database, it's no surprise it's getting hard to locate anything. We really, really need to develop some better search algorithms. Boolean and full-text search just aren't cutting the mustard anymore, even within the restricted space of Java bugs.)
I've received conflicting reports about why this behavior is the way it is. The most likely possibility seems to be for compatibility with classes generated by some older, incorrect compilers that required direct access to private members to support inner classes. This suggests that using the -Xfuture option to the interpreter should also fix the problem because this option enforces all constraints that JavaSoft expects to enforce at some point in the indefinite future, such as forbidding access to private members; and indeed this option does fix the problem.
At the very least, this means that applets (which do verify untrusted byte code) shouldn't have any security problems as a result of this bug--excuse me, feature. However, I still think that byte code verification should be turned on by default, at least for those issues which can be produced by the normal Java compilation process. An option to turn off verification is perhaps reasonable. Leaving it turned off by default until someone trips over it is not. For instance, in a pure application environment one programmer on a team may be unintentionally using a field or method another programmer on the same team thinks is hidden. I don't know that every byte code verification needs to be made for local classes, but access protection is pretty fundamental. Some Java 1.1 and 1.2 VMs do notice the problem, and won't run the test program with or without verification. Others don't and run it happily.
I want some LinuxMon game cards!
I've moved Greg Guerin's analysis of C# to a special reports page due to length and also so that the URL is more permanent for other sites that want to link to it. I've also added another report from Larry O'Brien. Additional commentary is appreciated.
The final version of the second edition of The Java Language Specification (JLS)--that is, the
one that covers Java 2--includes the same language in
Section 12.1.4:
"The method main must be declared public, static, and void."
Given this statement, I don't think I'll be recommending or using non-public main() methods just yet.
However it still leaves open a couple of questions:
main() method? or for that
matter a non-static or non-void main() method? I suspect it's not, but the issue is unclear from the spec.
main() method?
I suspect the answer is yes. However, the JLS isn't detailed enough to definitively answer either of these questions. Normally, these are the sorts of issues that would be resolved by a standards committee. Too bad Java doesn't have one.
Meanwhile, Sudarshan N. Mogasale of Geometric Software Solution Co. Ltd has uncovered a possibly related and even more dangerous problem. The JDK 1.3 For Windows NT does not check access specifiers at runtime. This allows you to access private data with either a hacked compiler, direct editing of byte code, or a simple recompile. Consider these two programs:
public class Outside {
public static void main(String[] args) {
Inside inside = new Inside();
inside.print();
inside.value = 42;
inside.print();
}
}
public class Inside {
private int value = 23;
private void print() {
System.out.println(value);
}
}
Clearly, Outside should neither compile nor run because it can't access the private
value field in Inside, and indeed it doesn't.
However you can trick the compiler into compiling it and the virtual machine into running it!
To do this, first make value and print()
public like this:
public class Inside {
public int value = 23;
public void print() {
System.out.println(value);
}
}
Now compile both files and run Outside. This is what you expect and what you get:
D:\JAVA\private>java Outside 23 42So far, so good. No surprises. However, now change
value and print()
back to private like this:
public class Inside {
private int value = 23;
private void print() {
System.out.println(value);
}
}
Recompile only Inside.java, not Outside.java. The run Outside like this
D:\JAVA\private>javac Inside.java D:\JAVA\private>java Outside 23 42
Outside can now access and change the private value field in Inside!
This shouldn't happen! Outside should throw an IllegalAccessError instead.
Although the steps outlined here, require access to the source code of the class
whose private data you're illegally
accessing, it's not that much harder to do it without the source code.
You just have to know a little
bit about Java byte code hacking.
This is a major security hole that opens up many attacks. I don't know if it's been reported before.
I've verified it on NT 4.0 using Sun's latest JDK 1.3. Mogasale has tested it
on JDK 1.2.2 and 1.3. He also says this problem does not arise
on JDK 1.1.7 for Solaris. I do not yet know if this hole is present in any browser
VMs, though I suspect it only arises in Java 1.2 and later. More reports and tests
from different VMs would be helpful. You can send your results to my usual address,
elharo@ibiblio.org
and I'll summarize here tomorrow. I'd especially like to know if this occurs
in either JDK 1.2.2 or 1.3 on Solaris, and whether anyone can find a report of
this in the Java Developer Connection Bug Parade. I'd also like to know whether or not
the various browser VMs are vulnerable to this.
Sun's released version 1.2.1 of the J2EE SDK Japanese Supplement. This is a set of resource bundles containing localized Japanese messages for the J2EE SDK. You'll need to install the J2EE SDK software bundle before you install the Japanese Supplement bundle.
Sun's released version 2.0.1 of the Java Communications API for Sparc Solaris. A Windows version will be available soon. The Java Comm API allows Java applications to access serial and parallel ports.
Sun's posted an early access release of the Java Naming and Directory Interface (JNDI) DNS Service Provider 1.2 on the Java Developer Connection (registration required).
Apple's released version 2.2.2 of Macintosh Runtime for Java. This release fixes a few security bugs. Mac OS 8.1 or later and a PowerMac with 32 Megabytes of free RAM and 20 megabytes of hard disk space are required. MRJ 2.2.2 supports Java 1.1.8.
Several people have reported that the non-public main() method works in JDK 1.2.1 and JDK 1.2.2.
It does not work in JDK 1.1.8, JDK 1.1.5, or JDK 1.0.2.
However, Jamie Lawrence reported that it failed in Borland JBuilder regardless of JDK version.
Robert A. DiBlasi found that this is addressed as Bug Report
4252539 in the Java Developer Connection Bug Database.
Apparently the behavior is intended, but implementation dependent.
Scott Came pointed out the first edition of The Java Language Specification--that is, the
one that covers Java 1.0--is unequivocal
on the issue. Section 12.1.4 states that
"The method main must be declared public, static, and void."
My draft version of the second edition of the spec retains this exact sentence in section 12.1.4.
Would any language lawyer with a copy of the final version 2 of the Java Language Specification
care to point out if that spec still includes this sentence?
(If XMLDevCon hits a slow spot today,
I may pop over to the McGraw-Hill bookstore and buy one myself.)
Microsoft's posted some information (though no software) about C#. I haven't had time to look at it yet because I'm still busy with XMLDevCon. If anyone who had would like to send in a thoughtful, non-inflammatory summary I'll try and post it tomorrow.
Cool discovery of the day: At least as of JDK 1.3, you do
not have to declare your main() methods
public!
You can leave them with the default package access, or even make them private!
This was reported to me by a Java trainer in India, one of whose students
(as yet anonymous) noticed this.
This has a lot of important implications; among them:
main() methods that are only used for testing
and not for application launching, can be private so they aren't
accidentally accessed from other classes, and don't need to be
deleted or commented out before distributing or
building JavaDocs.
I still recommend that you make the main()
methods that launch your applications public. This allows the program to
be easily launched from or as a part of other Java programs.
It makes Java a lot more scriptable from within Java.
Nonetheless non-public main() methods are
a useful and potentially important technique.
This does not work in Java 1.1.3 (the only other version I have easily available.) Can somebody test this in Java 1.2? Here's a simple program to try:
class Test {
static void main(String[] args) {
System.out.println("Hello World!");
}
}
Currently, this program compiles everywhere I've tried it. It runs successfully JDK 1.3.0 for Windows. It fails with the message "In class Test: main must be public and static" on JDK 1.1.3 for Solaris. I suspect this is an unannounced or perhaps announced but little heralded change in either Java 1.2 or Java 1.3 that's just being noticed now.
I'll be at XMLDevCon today and most of this week so updates are likely to be a little slow. Tonight I'm giving an introductory talk about JDOM at the meeting of the New York C++ & Java SIG of the New York PC Users' Group. The meeting starts at 6:45 in the Gramercy B Room of the New York Hilton, 1335 Sixth Avenue, (where the XMLDevCon show is being held) and runs till roughly 8:00. I'll be showing off JDOM basics and comparing and contrasting it to SAX2 and DOM. Admission is free. You do not need to be registered at XMLDevCon to attend, though you may want to register for a free XMLDevCon special events pass if you want to see the keynotes or wander the show floor as well.
I just spent an hour trying to debug an installation of the JDK 1.2 and then the JDK 1.3 on Windows 2000. Mostly, it seemed to work; but for some unexplained reason java couldn't find the jar archives in my ext directory even though javac could. What I eventually discovered was that Sun had placed two more or less identical copies of the JRE (along with the jre/lib/ext directory where jar archives go) on my hard drive; one in C:\jdk1.3 and one in C:\Program Files\JavaSoft. javac uses the JRE installed in the first directory, but java uses the JRE installed in the second. You have to put your .jar files in both places to make them accessible to both java and javac. I'd encountered this brain damage before on a different system, but at the time I attributed it to multiple JDK and JRE installations over time getting in the way of each other. However, this was a fresh system on which no Java had been installed before. Apparently, this isn't a bug. Sun is deliberately placing two copies of the JRE on every Windows hard drive the JDK is installed on. What idiocy! As near as I can tell, it is possible to delete one JRE, make a few changes to the PATH and the registry, and get everything to work with only a single installation of the JRE, so why isn't this the default? Can we maybe get JDK 1.4 to live with a single copy of the JRE? I hunted around on the Java Developer Connection Bug Parade but didn't find anything clearly on point. It may be related to Bug 4240897.
I'd like to thank everyone who helped me get Linux installed on my laptop. I've now finally configured it to dual boot into either Debian or Windows 2000. I still have to configure X, but I don't anticipate any major problems there. From this point out, it's all just Unix which I'm thoroughly comfortable with. My problems all arose from starting with a Windows system, something I've never been an expert at. This is going to be extremely helpful for getting more Linux coverage and screenshots into my future books.
I do not want to clear up one common misconception that showed up in virtually all the emails I got. Press releases to the contrary notwithstanding, PowerQuest's Partition Magic 5.0.1 most definitely does not support Windows 2000. What it does do is make a couple of boot floppies that run Caldera DR-DOS from which you can run a stripped down, incomplete version of Partition Magic that is missing critical functionality. However, Partition Magic itself will not run on Windows 2000. BootMagic seems to run once installed (it really runs before Windows 2000 takes over) but the BootMagic installer reproducibly crashes, and if you want to change your configuration, e.g. to add an operating system, then you have to reinstall BootMagic from scratch. You can't configure it from Windows 2000. Furthermore, you can't even get this limited functionality in the package you buy. PowerQuest is currently selling version 5.0. To get version 5.0.1 you have to pay PowerQuest more money to ship you another CD, or spend several hours downloading an update that can't successfully install itself and doesn't provide all the functionality of the version on the CD.
Before you can get the downloadable update, you have to register, which means sending PowerQuest your name, address, and other personal info they have no right to. I've bought the software. I should be allowed to use it without having to reveal anything about myself. Payware companies like PowerQuest (and Microsoft, and Apple, and Sun, and many, many others) are starting to forget their place. They sell a product to us. We buy a product from them. That's all. This doesn't give them the right to tell us what we can do with the product. It also doesn't give them the right to become involved in our lives, send us email, call us on the telephone, or even know who we are. I think one of the most important features of open source software in the next decade is going to be that it doesn't try to restrict the user like so much payware now does. I also think that for this reason it's important that we not let critical parts of the open source infrastructure be replaced by payware solutions like VMWare, BootMagic and PartitionMagic. If software is to be truly free, then it can't depend on non-free parts. That fips is effectively dead because of the removal of a crucial feature in Microsoft Windows is a black eye on the free software community. By removing the ability to create DOS boot disks from Windows NT and 2000, Microsoft hobbled Linux and other free operating systems by making it much harder to migrate from Windows to Linux. So far, no one seems to have noticed or commented this attack.
Cnet's reporting that Microsoft is about to release (or perhaps just announce) its long-awaited Java-Killer, to be named C# (pronounced "C sharp"). This is a C++ derivative with a lot of Java-like features. It will have garbage collection and maybe security. (Not that Microsoft knows the first thing about security; If ActiveX didn't prove that, ILoveYou sure did.) It will probably be Windows only, at least until the FSF gets their hands on it.
The name's cute, but otherwise this strikes me as a yawn.
If Microsoft wanted to really challenge Java, they should have gone with
Python. I just don't believe it's possible for any major advances in language design
to be made while restricting oneself to the mistakes
Kernighan and Ritchie made 30 years ago. Many of Java's flaws are the
results of needlessly maintaining compatibility with C. Much of Java's simplicity
comes from places where it broke with C and C++. (switch statements come immediately to
mind.) IMHO, a simpler, easier-to-use
language than Java can only come about if you move further away from C and C++, not closer.
Discussion on slashdot.
Sun's published Public Review Draft Specifications for
The Merlin JSR is particularly interesting since it amounts to a roadmap for where Sun
plans to go with the JDK.
The only proposed language change is a
simple assertion facility.
The other changes involve either low-level VM details or
API extensions and additions.
Improvements to the core library (java.lang) may include deep-copy clones
and exception chaining.
Goals for Merlin do include a lot of XML APIs including SAX1, DOM1, JAXP, SAX2, and possibly DOM2 as well as an unspecified XSLT API.
Improvements in the AWT/Swing include headless systems and support for mouse wheels as well as much better file dialogs. Look and feel improvements include a Windows 2000 Look and Feel as well as putting the Macintosh menu bar at the top of the monitor, to which all I can say is, "It's about time!" A general preferences API is also a likely candidate for inclusion.
Several enhancements are aimed at increasing availability including a remote monitoring facility that's a subset of the debugging and profiling APIs is suggested so that other clients can watch the progress of a Java program over TCP/IP. Another reliability enhancement is support for native failover APIs so one server can pick up where a dying server leaves off. The virtual machine will be 64-bit compatible. HotSpot will share a common source base across platforms. Multiple virtual machines will also be able to share some memory and data structures so the total footprint is reduced.
Installation of both applets and applications should be (and needs to be) much improved. Support for Java Web Start and the Open Java Interface for Netscape 6 is a no-brainer.
For internationalization, Thai and Hindi locales will be added. The
character set converters
in the undocumented sun.io
package will be moved to a public API.
Unicode 3.0 will be supported including surrogate pairs.
UTF-7 will be added to the list of supported encodings.
All of JDBC may be bundled into the core distribution. DNS and DSML service providers for JNDI will be added.
There are many proposed improvements to I/O.
Asynchronous I/O and/or polling I/O may finally be added.
Memory mapped or otherwise buffered I/O should also be added.
printf() like formatting and regular expressions are also likely candidates for inclusion.
There will be more different kinds of more specific IOExceptions.
More details about the file system and file types should be exposed through the Java API without
requiring you to drop out to native code to determine, for example, the file permissions and ownership info.
All this should
give me something to write about in the second edition of Java I/O :-).
Networking changes, by contrast, are quite minor. IPv6 will be supported if the host platform supports it. Passive mode FTP will be added. I'm glad to say I don't think any of these or the other networking changes will necessitate a third edition of Java Network Programming anytime soon.
The security changes are quite major. I don't have time to discuss them right now. Suffice it to say that after four major iterations of Java, Sun is still trying to figure out how to do security right.
There are many, many more minor improvements and fixes. For details, you'll have to read the PDF file. That's actually quite a lot, though. Relatively little of the existing API should be deprecated, however. Most of these additions seem like good ideas to me. The details are being worked out through the Java Community Process. Public review closes on July 20, 2000; but the review of the individual pieces is in a variety of stages. Some of these are almost done; and are virtual locks to be included in the next release of the JDK. Others are just gleams in a programmer's eye right now. I'll report details on the individual parts here as they move closer to completion.
Sun's also published the Participant Review Draft Specifications for
Review closes for all of these on July 5. JAIN is about low level network management in the public switched telephone network and similar networks and won't be of interest to most people. These will be standard extensions and not part of the Java core API.
Jens Alfke has posted release 9 of Rich Chocolaty Goodness, his AWT GUI enhancer package for the MacOS. Version 9 lets individual tabs of a TabControl have their own tooltips and fixes a couple of small bugs.
Vita Nuova will be distributing Bell Labs' Inferno Operating System including source code (not open source) for about $300. Inferno is a virtual operating system that can run on a variety of hardware. Most interesting is its object-oriented Limbo programming language. It has portability features similar to Java's, though it's really quite a different language.
Sun's dropping the price of its existing Sun Ray 1 thin client to $299 from $549. It's also adding a new $549 SunRay 100 client with a 17 inch CRT monitor and a $1249 SunRay 150 with a 15" flat panel display. This is actually the one I like--anything with a CRT monitor is simply too big to be thin--but I want a price point around $499. Unfortunately, the price is very constrained by the availability and prices of TFT displays so I don't expect to see one soon enough to really let the SunRay catch on. Still, it's a very nice system for a lot of markets that don't require full-fledged PCs like point of sale terminals. One of my favorite uses is as basic Internet terminals at trade shows and Web cafes.
Sun's also released version 1.1 of the SunRay OS with various enhancements including multiple server support. This means the SunRay smart cards are no longer limited to a single workgroup.
Slava Pestov has released the seventh beta of JEdit 2.5, an open source programmer's editor written in Java. This version fixes assorted bugs.
Sun's released version 5.2 of the gratis (but not libre) StarOffice suite for Windows, Solaris, and Linux. Version 5.2 improves Microsoft Office file compatibility, full online help, a database engine, better indexing and cross-referencing in the word processor, a WYSIWYG font dialog, and a presentation player for playing StarOffice slide shows on a system without StarOffice.
Frederic Lavigne has posted version 0.2.3. of his Skin Look and Feel, a Skins package for the Java Platform that lets Java developers use GTK and KDE themes in their Swing applications. This release fixes some bugs and adds sound support for WindowEvents, a new layout for Scrollbars, and a SkinChooser component. However, you might want to read Skin Cancer for a cautionary thought about such technologies.
The short answer to the partition question seems to be to buy PowerQuest's Partition Magic and use that to split my disk. I've ordered a copy, and we'll see if that works.
I've recently purchased a Dell Latitude LS notebook to support the increasing number of presentations I'm giving. This puppy comes with Windows 2000 preinstalled on the single partition of its 12 gigabyte hard drive. I'd like to make the primary operating system Linux for normal use. However, I need to have access to a Win 2000 system for some of the books I write so I can't wipe the drive completely. My first reaction was to partition the drive (FAT32 formatted) using fips. Unfortunately all the instructions I have for using fips seem to assume you can make a boot floppy and boot into MS-DOS mode. As near as I can tell, that's impossible in Win 2000.
So my question is this: has anybody sucessfully repartioned a Win 2000 system without wiping the whole drive? If so, how? It's not out of the question that I wipe the whole drive--it's a new system that doesn't possess any siginifcant data and should be fairly easy to reinstall from the CDs--but I'd rather avoid that if I can. I know I could use VMWare but I really don't want to split the machine between two OSs at the same time. Most of my needs are met by running one or the other, and I'd rather not take the performance hit from splitting the OS. Keeping in mind that this system can't use the CD and the floppy drive at the same time, all suggestions are appreciated. Please send them to elharo@ibiblio.org. Thanks!
Jason Hunter's released a new version of his com.oreilly.servlet
package.
New features include
letting clients send headers, cookies,
and authentication information to the server
as well as two new classes for Base64 encoding and decoding
and a nascent cookie CookieParser class.
Ben Spink's posted first beta of CrushFTP 2.0, his $20 shareware FTP server written in Java. Version 2.0 adds a customizable user interface, usage graphs, the abolity to listen on more than one port, and account expirations for non-anonymous FTP.
Tim Endres has released version 5.2.2 of jCVS II, an open source CVS client written in Java. CVS is a popular client-server, source code control system used on lots of open source projects like Xerces.
Slava Pestov has released the sixth beta of JEdit 2.5, an open source programmer's editor written in Java. This version fixes assorted bugs.
IBM's alphaWorks has refreshed their port of the JDK 1.3 to Linux to fix assorted bugs.
I've finally gotten the rights back to my first book, The Java Developer's Resource. A lot of people liked this book, but it's been out of date for several years and out of print for the last couple. Over the next year or so I'm going to be updating it and posting the revised chapters here at Cafe au Lait. The first three chapters are available now:
Others will follow as I have time to write them, though not necessarily in order. I will probably divide the book into more, smaller chapters so I can post and update more frequently.
Sun's posted the first early access release of Java Web Start, version 0.4,
on
the Java Developer Connection (registration required).
The more I look at this the more useful it seems.
Java Web
Start lets you launch stand-alone Java applications
from your Web browser. After it's downloaded the first time, the application can
be launched independently of the web browser.
The applications run in a sandbox and are secure like applets, though the sandbox is a little less
restrictive than the one applets get to play in. For instance, Java Web Start applications can call
System.exit() and they can read and write files that the user chooses
through Open and Save File dialogs (though they can't read an arbitrary file on the hard
drive.)
As with applets, code signing can be used to loosen the sandbox restrictions.
However,
they're cached on your hard drive and don't require a new download every
time you want to run one.
They can also be updated to new versions automatically.
Technically, it seems quite easy for developers to implement
Java Web Start applications, just put all your files in JAR archives,
write a simple XML document describing the application, and set a couple of web server
parameters.
Java Web Start is available on Windows,
Solaris
Sparc, Solaris
X86, and X86
Linux.
Bell Labs has open sourced its experimental Plan 9 operating system.
As you've undoubtedly already heard, Judge Thomas Penfield Jackson has ordered that Microsoft be split into two companies. The decision will be appealed, possibly directly to the Supreme Court. If it were up to me, I would have split Microsoft into several dozen companies; but this is a good start.
Slava Pestov has released the fifth beta of JEdit 2.5, an open source programmer's editor written in Java. This version improves the home and end commands and fixes assorted bugs.
Sun's posted the first early access release of the Java Embedded Server 2.0 on the Java Developer Connection (registration required). The Java Embedded Server would be aded to settop boxes, cable modems, or similar devices to allow the service provider to manage and control other devices in the home like telephones, lights, alarm systems, appliances, and more. What I can't for the life of me figure out is why anyone would trust the cable company to control your refrigerator? or for that matter why you'd want them to? The potential for privacy violations here seem staggering. Frankly, I don't want the cable company (or anyone else) to know what TV shows I watch, much less how often I open my refrigerator or when I turn on the lights in my bathroom.
The W3C has posted two notes from Sun for the JSpeech Grammar Format and the JSpeech Markup Language. The JSpeech Grammar Format defines a non-XML syntax for encoding the valid responses at given moments in a program's life. For instance, a very simple grammar may say that in response to a particular question, the user must answer "Yes" or "No". It makes speech recognition more accurate by limiting the words that may be spoken and commands that may be given at any one time. The is an XML application for annotating text that will be spoken by a computer to improve its quality. For instance, JSML lets you specify the pronunciation of a word or say that a particular phrase should be spoken louder to emphasize it.
Aside from name changes, these are the same as Sun's previously published Java Speech API Grammar Format 1.0 and Java Speech Markup Language 0.6. The names have been changed to protect Sun's Java trademark while these to be developed under the W3C process. The W3C is obligated to post notes submitted by member organizations like Sun, but they aren't obligated to endorse or do anything with them. These two specs will probably be developed within the Voice Browser Working Group, however.
Sun's released some, but not all, of the source code for NetBeans/Forte for Java IDE under the Mozilla Public License (Sun variant). In particular, they've deleted the source for the Java Parser and Internal Compiler, (a pretty major omission IMHO, and one Sun could easily rectify if they had a mind to) as well as the third party ICE browser component. Source is available via CVS only.
Sun's published what is apparently the final version of the Java Community Process 2.0 Rules. Bottom line: Sun has a permanent seat on the executive committees that reject or accept new specifications and changes to existing specifications. Sun further has exclusive nomination privileges for 10 of the 15 other seats on the executive committee. Furthermore, Sun can veto some (but not all) proposals. In particular it can veto "new Platform Edition Specifications or UJSRs for J2SE that propose changes to the Java language".
The printed version of the second edition of the Java Language Specification is now available from amazon and other online booksellers. However it does not yet appear to be available online. Amazon also seems to have the second edition of Bruce Eckel's Thinking In Java on 24-hour availability as well. This book is available online.
Sun's released version 2.1.1 of the JavaCard API specification and software development kit. As usual, all the specs are in the inconvenient PDF format. In related news, American Express has announced that it will integrate Java into its Blue smart card (which is apparently not the same thing as the ubiquitous AmEx charge cards).
Sun's posted the first early access release of the Java Accessibility Helper 1.0 on the Java Developer Connection (registration required). This is designed to help Java developers make their JFC-based programs accessible to persons with disabilities. According to Sun,
The Helper generates a report that includes a prioritized list of problems and potential problems with the application being tested. For example, the Helper verifies that all input fields in an application can be reached using only the keyboard.
The Accessibility Helper does not require the source code for the application being tested and will work with any AWT- or Swing-based application.
Sun's also posted the first early access release of a Mobile Information Device Profile for J2ME (MIDP) implementation. In brief, MIDP lets developers specify what a particular cell phone, Palm Pilot, toaster oven oo other non-traditional device does and does not support.
IBM's alphaWorks has updated EADP for Visual Age Java. This is a set of extensions to VisualAge Java Persistence Builder. This release adds a few new features such as default primary key values and scrolling capability for large databases, plus a rewritten user manual and javadoc.
Sun's posted what's probably the final beta of the Java 2 Software Development Kit, Standard Edition, v 1.3.0 (JDK 1.3) for Solaris and X86 Linux on the Java Developer Connection (registration required). This release fixes various bugs, tunes performance in several areas, and bundles both the Java HotSpot Client VM and Java HotSpot Server VM.
Sun's also posted the first early access release of the Java Image I/O API on the Java Developer Connection (registration required). Specifically, this is version 0.4. The Java Image I/O API is a pluggable framework for reading and writing images in various formats. It will probably be part of Merlin, the next major release of the JDK after 1.3.
IBM's Java evangelist Simon Phipps has left IBM, and is now working for Sun. Phipps is probably best known for keynoting more Java-related conferences in the last couple of years than all other speakers combined. (Well probably not quite that many, but the man does like to talk to an audience.) He'll be doing pretty much the same job as before, only for Sun instead of IBM.
The members of the Executive Committees that will oversee the Java Community Process (JCP) 2.0 have been announced. There are two of these, one for the desktop/server space and one for the consumer/embedded space. Members include:
I'm particularly happy to see Apache, Apple, Caldera, and HP on the board. Their respective platforms have been severely underrepresented in the past to the detriment of Java. These are interim boards until elections are held later this year.
The first beta of JINI 1.1 is now available for download from the Java Developer Connection (registration required). Version 1.1 bundles the JavaSpaces service implementation. This was previously a separate product.
Sun's also released a beta of the
Java Naming and Directory Interface (JNDI)
Directory Service Markup Language (DSML) Service
Provider 1.2.
DSML is a XML application
for representing directory data. See for details. The
JNDI/DSML service provider implements the
javax.naming.directory.DirContext interface for
reading and writing DSML documents.
Finally, Sun's posted the first public draft of the J2EE Connector Architecture Specification 1.0. According to Sun,
The J2EE Connector architecture provides a Java solution to the problem of connectivity between the many application servers and EISs already in existence. By using the J2EE Connector architecture, EIS vendors no longer need to customize their product for each application server. Application server vendors who conform to the J2EE Connector architecture do not need to add custom code whenever they want to add connectivity to a new EIS.
The J2EE Connector architecture is based on the technologies that are defined and standardized as part of the Java 2 Platform, Enterprise Edition (J2EE). The J2EE Connector architecture is proposed to be part of version 1.3 of the J2EE platform.
Sun's released version 2.1 of the Java Media Framework, an application programming interface (API) for video and audio capture and playback in Java applications and applets. As well as fixing assorted bugs and making various performance improvements, version 2.1 adds
JMF is available in pure Java and Solaris and Windows-optimized versions.