Slashdot Mirror
James Gosling on Java
prostoalex writes "It's been ten years since the official introduction of Java - a programming language combined with virtual machine and a class library. ZDNet published an interview with James Gosling, the creator of Java, who talks about the project's past, present and future."
If anyone is interested in conversing with James Gosling one-on-one, he (amazingly) hangs out at DevShed.com in the forums, likes to aswer questions, and my guess is he knows what he's talking about when it comes to Java. Even more amazing is that as smart a guy as he is, his social skills leave a lot to be desired (read some of his posts in the Lounge).
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
As far as I'm concerned, everybody (that I know in the java world) is (and has used for some time) Borland's JBuilder. It's an amazingly nice IDE that's of far higher quality IMO than Eclipse (although the swing interface does drive me a little mad)
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
FYi, parent is trolling. There's no such quote in the article.
Why the hell did the interviewer decide to turn it into a "how did/does/will Java work with MS technologies" diatribe?
.NET (their "Java") or Java are going to go away. Both will be around for a long time, and both are going to have to integrate.
.NET programs to call Java, and vice versa.
I mean, theyre so disparate in ideaology, while I can understand some of the relationships, why on earth bring them up with the creator of a language that MS has deliberately shunned when they couldnt get it to work "their way"?
Because neither Microsoft
Java is evolving to work better with MS technologies in three ways: First, the Desktop Integration APIs, which allow the portable use of Browsers and features like the systray within Java applications, Secondly, by developing Java GUIs to make them indistinguishable from other Windows applications on Longhorn without losing portability, and Thirdly, with the use of Web Services to allow
1. Kudos to the Groovy authors. They've even garnered James Gosling's attention. If you write Java code and consider yourself even a little bit of a forward thinker, look up Groovy. It's a very important JSR (JSR-241 specifically).
2. He talks about Javascript solely from the point of view of the browser. Yes, I agree that Javascript is predominently implemented in a browser, but it's reach can be felt everywhere. Javascript == ActionScript (Flash scripting language). Javascript == CFScript (ColdFusion scripting language). Javascript object notation == Python object notation.
But what about Javascript and Rhino's inclusion in Java 6? I've been using Rhino as a server side language for a while now because Struts is way too verbose for my taste. I just want a thin glue layer between the web interface and my java components. I'm sick and tired of endless xml configuration (that means you, too, EJB!). A Rhino script on the server (with embedded Request, Response, Application, and Session objects) is the perfect glue that does not need xml configuration. (See also Groovy's Groovlets for a thin glue layer).
3. Javascript has been called Lisp in C's clothing. Javascript (via Rhino) will be included in Java 6. I also read that Java 6 will allow access to the parse trees created by the javac compiler (same link as Java 6 above).
Java is now Lisp? Paul Graham writes about 9 features that made Lisp unique when it debuted in the 50s. Access to the parse trees is one of the most advanced features of Lisp. He argues that when a language has all 9 features (and Java today is at about #5), you've not created a new language but a dialect of Lisp.
I am a Very Big Fan of dynamic languages that can flex like a pretzel to fit my problem domain. Is Java evolving to be that pretzel?
FYI, grandparent should have been modded informative and parent modded funny.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment.
As Java is now used in real-time control applications, that is certainly avoidable.
bloated: the java class libraries are huge and so deploying a java environment (and you can't assume a decent java system will already be installed by default) is a huge undertaking
Not really. Java can be installed as a single rpm or tgz. Its over 10 mb, but given the size of a CD-ROM, or broadband download speeds, that is hardly a 'huge undertaking'.
and who would seriously wan't to release thier software as java bytecode when jad is arround?
There are plenty of bytecode obfuscators around.
C++ was 14 around 1997 and was widely used and known for its high performance.
That's not how I remember it. I remember in 1996-1997 people were scoffing at C++ because it was "slower than C".
slow: slow to start definately, slow in actual code speed no. Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment
Sure its slow to start because ther is a 2nd process. But Java 1.5 addresses this to some degree. As for inconvient GC cycles, that is the programmers fault. You have to do your own GC when you think you have time. The JVM will only GC when its full...
bloated: the java class libraries are huge and so deploying a java environment (and you can't assume a decent java system will already be installed by default) is a huge undertaking
False.
NOT FREE: well there are free jvms but there is still catching up to do and as they get better they will undoubtablly suffer the same issue as wine, most stuff will work but there will be slight differences that fuck over some apps.
You mean like Microsoft tried?
the fact that languages like java allow poor coders to produce code that kind of works rather than total failures probablly doesn't help the languages reputation either.
Troll.
Unfortunately, it's like trying to run C++ programs through an interpreter on a machine at 3/4 of the power of the one you're using instead of actually compiling and tweaking it for maximum speed and efficiency.
If you ran some actual benchmarks (with modern Java) you will find you are mistaken. Modern Java VMs include an optimiser that tweaks the machine code for speed and efficiency just as you describe. Last year, a set of benchmarks for numerical computation showed Java within 4-5% of optimised C code.
I use Java apps at work and they are often slow and ponderous compared to similar apps written the normal way in C++
The reason for this is usually that some organisations are very slow at upgrading their Java. Java 1.5 was released last year and is generally acknowledged to be fast, both in terms of general performance and GUI speed. Many companies are still using Java 1.3, which is very old.
The "barfing runtime exceptions" was exactly my point. It's not only a red flag for badly written code, it's a built-in QC test. I'm TIRED of reading other people's code and having to go back to them and say "O.K., this (really arcane thing that you never will understand) might/probably will happen, and so therefore I can't put you code into production". All them "barfed runtime exceptions" make my argument for me. I can simply fiat "no unhandled exceptions" and leave it at that.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
I disagree. You can't just write an inefficient program and hope that advances in hardware make up for it.
I think Java's biggest problem is the lack of a good garbage collector. I saw a program where the programmers had put a tiny memory display in the bottom left corner of the screen. At first it was OK, hovering around 100 megs, but as we kept using it, the memory usage would increase as needed, but it would never free it after it was done with it. Within 10 minutes, the thing had occupied all 512 megabytes of that computer's RAM and nearly crashed the system.
There is also a non-Java alternative to this program which has less features, and a CLI instead of a fancy GUI, but at least it doesn't need two Gigs of RAM to run. Personally, I prefer the non-Java one.
It's funny you should mention that...
One former professor of mine uses the phrase "10 years of Java experience" as an indicator of when to throw out a resume. He does some consulting work, and companies tend to ask him to go over the resumes of their applicants and junk those that he feels are unqualified. First, those who don't have CS or SE degrees get thrown out. Second, he throws out anything with obvious lies such as "10 years of Java experience".
When you posted that, I immediately thought of that story, because it really shows how some people can be utter dumbasses.
I support the Center for Consumer Freedom
2. Out of the box EJB support that is good.
3. Out of the box webservices support.
4. A much better, more mature GUI Editor that's going to get even better in 4.2. (Not sure if VE is in eclipse 3.1)
5. Cool auto comment tool
6. Bundled Tomcat and Full J2EE compliant app server.
7. This guy's blog to read :)
8. This one is subjective but to me... i don't find the interface as cluttered or ugly as Eclipse. Obviously other's disagree. Also even the the windows are not native, the layout is much closer to what native dialogs look like on windows. With Eclipse, the dialog boxes just seem weird. Error messages look and feel like they don't belong, etc.
Open Source Java DAO Generator
An updated Eclipse plug-in and a new Idea plug-in for Groovy were just released. They aren't perfect yet, but there is progress.
We considered Jython and Groovy when we were adding scripting to an app, since they were the only two scripting languages that came with licenses that were found to be acceptable by our legal department.
Why choose at all? Why not use the Bean Scripting Framework (originally from IBM's Alpha Works, IIRC) and let the customer choose whichever language they prefer? BSF lets you embed any scripting language that has a conforming wrapper. BSF wrappers are available for Groovy, Jython, BeanShell, Rhino, JRuby, Tcl, NetRexx, XSLT, and perl among others (although it's been my experience that some of these aren't all there yet).
FreeSpeech.org