Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Tim Bray on 'What Sun Should Do'
I got involved with Java in late 1995 and taught Java to hundreds of students in 1996 and 1997; in addition, by the end of 1997 I had developed close to 50 Java programs (i.e., applets, applications, utilities, components) -- some were completely functional applications, while others were proof-of-concept applications.
Before JDK 1.1 was released in early 1997, I could have sworn I had the core APIs memorized. But after JDK 1.1 -- and especially
after JDK 1.2 -- I just couldn't stay current on all of them. Although I did use technologies such as Java Database Connectivity
(JDBC), servlets, Remote Method Invocation (RMI), and the core JDK APIs frequently, it was tough to keep up to date on all
the other features of Java, such as EJBs, Java Naming and Directory Interface (JNDI), Java Message Service (JMS), security,
and more. In the past two or three years, however, I have managed to catch up on JavaMail, JMS, EJBs, JNDI, and others. Although
I am familiar with the Collections Framework and have used it on one or two occasions, I cannot say I am a pro at using it
-- I still tend to fall back on my favorites, the Vector and Hashtable classes.
For a while there, it seemed like a new API, whether it was part of the core JDK or standard extensions, was introduced by Sun every month. And with all of the product announcements from other vendors, I've been feeling constantly left behind (although the recent dot-com bust has introduced a sense of sanity to the mad rush).
It gets even worse. If you visit the Java Community Process (JCP) Website, you'll notice numerous Java Specification Requests (JSRs) in progress, which makes you wonder whether you should wait to learn and/or apply existing APIs (e.g., Apache's Log4J) when there is something similar in the works (e.g., the Logging API spec).
And if you are a regular visitor to Sun's flagship Java site, you've probably come across articles about the latest developments on smaller versions of Java (e.g., Java 2 Micro Edition (J2ME), Java Card). J2ME, for example, is gaining a lot of momentum, and, in my opinion, is about where Java 2 Enterprise Edition was two years ago -- in other words, it is about to explode. If you attended JavaOne last month, you might have seen demos of J2ME-based products that are either already shipping or will be available later this year. More than 4.3 million Java Cards were recently deployed to active duty military personnel (enabled by ActivCard, Inc.).
All in all, if you are like most Java developers or entrepreneurs (or if you fall into both categories, like myself), you want to catch the wave and stay current with the technologies in order to develop the next killer app.
Obviously, technology will continue to advance and naturally introduce changes on an ongoing basis. Ironically enough, technology helps technology progress faster. Given the rapid pace of technological development, one must choose areas of expertise and be content with that.