Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Gosling on Computing

CowboyNeal posted about 10 years ago | from the teco-shoutouts dept.

Java 74

CowboyRobot writes "ACM Queue has Eric Allman (creator of Sendmail) interviewing James Gosling (creator of Java) and the conversation covers many aspects of computing today, including the state of security, comparisons of languages and OSs, and the future of virtual machines. 'At the lowest level, you have to know that the boundaries around the piece of software are completely known and contained. So, for example, in Java, you can't go outside the bounds of an array. Ever. Period. Turning off array subscripting is not an option.'"

cancel ×

74 comments

Sorry! There are no comments related to the filter you selected.

Uh...! (-1, Troll)

Kethinov (636034) | about 10 years ago | (#9897299)

I ported sendmail to Java, recompiled it, and I'm using it to make this first post! ...man that was horrible, I deserve a modbombing now!

[OT] Sendmail Vs Exim (0, Offtopic)

HogynCymraeg (624823) | about 10 years ago | (#9897335)

I've been "advised" to move our servers away from sendmail to Exim. Has anyone had experience of doing this? I'd be interested to hear the pros and cons.

Re:[OT] Sendmail Vs Exim (0)

Anonymous Coward | about 10 years ago | (#9903779)

exim pros: syntax for configuration doesn't utterly suck
exim cons: doesn't scale to large mail volumes (may not matter if you're a small site)

Recommendation: avoid sendmail. avoid exim. use postfix.

hmmm (0)

Anonymous Coward | about 10 years ago | (#9897503)

'At the lowest level, you have to know that the boundaries around the piece of software are completely known and contained.
Sounds like something that should be handled by the OS to me.

Re:hmmm (0)

Anonymous Coward | about 10 years ago | (#9898856)

Write your OS in Java, then.

Good idea. (4, Insightful)

TheLink (130905) | about 10 years ago | (#9897618)

It's dangerous to use a programming language where common programmer mistakes allow "remote attackers to execute arbitrary code of their choice with the process's privileges".

Once they do that we'll only have to worry about stuff like SQL injection (which can result in execution of arbitrary code), which can be reduced/near eliminated by making people use prepared statements.

In some cases it'll still be necessary to use the unsafe languages, but nearly 100% of the programmers in the world obviously can't code safely in C or similarly vulnerable languages.

Even Eric Allman couldn't (see Sendmail for evidence).

Re:Good idea. (2, Insightful)

Anonymous Coward | about 10 years ago | (#9897655)

But that's not a reason to use Java. Safety of that sort is perfectly possible in languages compiled to native code; ML or compiled Lisp can give you the safety of Java, plus the convenience of type inference or dynamic typing, plus the speed of C.

Not that I'd dream of barely-on-topic evangelism or anything...

The problems of code injection (4, Interesting)

Anonymous Brave Guy (457657) | about 10 years ago | (#9897823)

Once they do that we'll only have to worry about stuff like SQL injection (which can result in execution of arbitrary code), which can be reduced/near eliminated by making people use prepared statements.

Yep, that's a serious problem, and one that gets far less "press" than the sort of buffer over-run vulnerabilities you get in careless C or C++.

The one that always astounds me is that languages with an eval-type statement -- that is, ones which can parse and execute an arbitrary string at run-time -- don't get slated for their security problems way more often. We use Perl to write CGI scripts all the time, and its variable interpolation can be waaaaay more dangerous than any potential pointer nasties in C!

It's notable that Java does not have such a function. It does, however, have the usual problem with allowing arbitrary strings to be interpreted as statements through its SQL API, but given the nature of SQL I'm not sure how realistic it is to address that anyway...

Re:The problems of code injection (2, Interesting)

TheLink (130905) | about 10 years ago | (#9899818)

But it's quite different if a programmer intentionally executes a user supplied arbitrary string without filtering it. Not the same as a programmer makes a low-level mistake (off by one, not having the numbers right) and then user supplied arbitrary code is executed.

The first is a "not thinking straight" problem and requires stupidity/ignorance which is common. The second is a "typo class" problem and only requires imperfection which is nearly ubiquitous -even smart and knowlegeable people make such mistakes (some even do it regularly).

As for other languages: I crashed a forth webserver the first time I tried :). I used a ' as password when it prompted for username and password for an access controlled URL. Turns out ' is a special forth keyword so Boom!

As the author of the webserver said when I emailed him: "the line between CODE and DATA is blurred by Lisp and obliterated by Forth. :)"

That's dangerous if you don't know what you're doing...

At least with perl if you turn on tainting and "use strict" a lot of exploits become very difficult. Whereas with C you need to keep remembering to do the right thing. Global "make things safer" switches are good for most people.

If you ALWAYS use SQL prepared statements in Java, in one sweep you make SQL injection attacks a lot harder. After that you need to make sure that LIKE queries don't have unwanted wildcards, and that stuff like a=b-parameter is either a=b - parameter or a=b-(parameter) so that if parameter is a negative number it doesn't create an SQL comment.

Then either you turn off multibyte/multilingual support or hope that the database implements it correctly. There was a bug in a database where a particular invalid multibyte word caused the following character to be "eaten" up. Imagine if the following character was a ' or \. The DB developer who mentioned the prob didn't even realize the severity of that prob and I had to give examples. Eye-opener...

You haven't heard about "taint mode"? (1)

BerntB (584621) | about 10 years ago | (#9907331)

We use Perl to write CGI scripts all the time, and its variable interpolation can be waaaaay more dangerous than any potential pointer nasties in C!
Is there a reason taint mode in Perl won't work for you?

(If the reason is old Perl code or uneducated programmers, I do think that your complaint is a bit overblown...)

Re:You haven't heard about "taint mode"? (1)

Anonymous Brave Guy (457657) | about 10 years ago | (#9910932)

No, taint is a great feature, at least up to a point. It's certainly a good idea, and it (particularly the way you untaint things) fits in pretty well with the general framework of the language. There are a couple of problems with taint mode, though.

Firstly, it's not obligatory. Now, you can reasonably argue that any competent Perl programmer will switch it on where it's needed, as indeed we (my colleagues and I) would, and that making it obligatory would be operate against the convenience of Perl and its TMTOWTDI philosophy. However, you can likewise argue that any competent C++ programmer will never suffer from buffer over-runs or memory leaks since the idioms to avoid them are common knowledge amongst such developers, or that anyone competent to write scripts to drive databases won't allow SQL injection because they'll always prepare their statements and filter everything first. Unfortunately, personal experience suggests that the majority of programmers actually aren't all that competent; they can get the basics done, but the difference in knowledge and ability between them and a good (not even expert) programmer is very significant. If anything, Perl suffers worse from this, because you can (and many people do) easily pick up just the basics from looking at a few sample scripts and scanning the introductory electronic docs, without ever realising that taint mode even exists.

Secondly, even when switched on, it isn't completely foolproof. See the problem of using exec with a list, for example.

And of course, not all languages with eval functionality support a taint mode; in fact, AFAIK this is unique to Perl at present.

Re:You haven't heard about "taint mode"? (1)

Eivind Eklund (5161) | about 10 years ago | (#9957414)

Taint mode is not unique to perl. It also exists in Ruby [ruby-lang.org] , at least.

As for SQL injection problems: I'm avoiding them by using a self-built API that is based more closely on the relational model than SQL is. That makes it trivial to write safe code, even without prepared statements. The basic problem of incompetent programmers still remain, of course - it is non-trivial for somebody to learn a relational API instead of SQL, and writing a relational API is even less trivial (and I'm not going to release mine until I feel it "complete", as I can't field the noise involved.)

Eivind.

Re:The problems of code injection (1)

bill_kress (99356) | about 10 years ago | (#9964134)

In java you actually could get the classloader to download a class over the net. It might be tricky, but I suppose it's possible.

This is, in effect, like the scripting problem you mentioned.

The nice thing is that it will be running with the same security system as its parent, so if the app wasn't given access to your HD, that's just not going to happen.

Re:Good idea. (1)

Brandybuck (704397) | about 10 years ago | (#9901177)

You're right, and that's the number one reason why Java is not written in C. Oh wait...

Re:Good idea. (1)

TheLink (130905) | about 10 years ago | (#9906765)

Most bricklayers don't make their own bricks. Nor should they need to know how to.

Leave the brick making to the brick makers. Fewer problems that way.

Re:Good idea. (1)

Brandybuck (704397) | about 10 years ago | (#9910475)

If Java developers were built buildings, they would refuse to even use bricks. Why, if the whole damn wall wasn't prebuilt they wouldn't bother! These are the guys who hated Legos as children.

</sarcasm>

Re:Good idea. (1)

TheLink (130905) | about 10 years ago | (#9913998)

Why reinvent the wheel or the wall for that matter? In the absence of artificial scarcities (like copyright, software patents), people should be spending less time rebuilding walls and more time on the stuff that's new.

But, as my brother says, I've been going downhill. I did like lego and did a fair bit of machine code programming when I was a kid (didn't have access to an assembler).

Now I prefer prefab - I use cpan and perl (in that order ;) ). Reusing your own code is nice and all that, but being able to reuse other people's code, now that's what I call _real_ code reuse.

I must point out that Java programmers are actually quite hardworking. IMO Java is a 99% perspiration and 1% inspiration[1] programming language (that's probably why it outsources well to the sweatshops ;) ).

[1] Note: If Edison was smarter he'd have perspired a lot less. But he was smart _enough_ in the right areas. So go figure...

Gosling, Java? Hmmm..... (5, Informative)

Cyberax (705495) | about 10 years ago | (#9897628)

I lost all my respect to Gosling after a clumsy attempt to add generics to Java.

The right way to add generics to Java is a radical modification of JVM (Java Virtual Machine), but Sun didn't want to it. So they made an attempt to add generics to Java language without touching JVM. The result of this attempt is a complex scheme of name mangling (just like C++), and some unnecessary overhead. And such implementation _still_ requires some JVM changes and is incompatible with old JVMs. So now we have an ugly generics in Java and Java 5.0 (rebranded J2SE 1.5) incompatible with previous versions.

Re:Gosling, Java? Hmmm..... (2, Insightful)

Bluelive (608914) | about 10 years ago | (#9897711)

Not really something you can hold gosling personally responsible for. And java generics arent as bad as you try to make them seem.

Re:Gosling, Java? Hmmm..... (0, Troll)

Cyberax (705495) | about 10 years ago | (#9897836)

Generics are non-existent to me. They won't be anywhere around until 2006-2007. And there will be something much better than Java in that timeframe, IMHO.

DotNET platform now has all chances to bes Java replacement on desktop (OpenSource Mono will help).

Java had the last chance to change, but miss

No Generics until 2006-2007 ?? (3, Informative)

fforw (116415) | about 10 years ago | (#9898620)

Generics are non-existent to me. They won't be anywhere around until 2006-2007.
what are you talking about? the 1.5 release is already at "beta 2". So we will have a release version in autumn. Netbeans will reach it's beta for the 4.0 release soon, so there will be a matching, open-source IDE, too.

And all that before even 2005.

Re:No Generics until 2006-2007 ?? (1)

Cyberax (705495) | about 10 years ago | (#9899066)

It took almost 3 years to migrate from J2SE 1.3 to J2SE 1.4 for most of our customers.Even now lots of our customers run JDK 1.3

Now add 3 years to 2005...

Re:No Generics until 2006-2007 ?? (1)

v01d (122215) | about 10 years ago | (#9899095)

Oh, but everyone will rush to upgrade .NET?

Re:No Generics until 2006-2007 ?? (1)

Cyberax (705495) | about 10 years ago | (#9899363)

.NET is better than Java from engineer point of view, just because Java bytecode is a subset of IL (Intermediate Language). So it's possible to recompile any Java program without native methods to DotNET (Microsoft has tool which translates Java into C#).

I really like .NET, right now I'm hacking Mono sources trying to add exact garbage collector instead of conservative Boehm GC.

Re:No Generics until 2006-2007 ?? (1)

gokeln (601584) | about 10 years ago | (#9899410)

Did you RTFA? .NET is fundamentally insecure because it decided to support the insecure features of C/C++. I'm not willing to get bit by these weaknesses years down the road when the script kiddies start taking advantage of them.

Re:No Generics until 2006-2007 ?? (2, Informative)

Cyberax (705495) | about 10 years ago | (#9899532)

No. This is just a FUD.

.NET bytecodes has a well-known "verifiable subset" which can be automatically verified to be correct just like Java bytecode. CLR can be configured to reject non-safe code in some domains and accept it in another domains. For example, you can configure CLR to behave just like an applet sandbox for downloaded applications.

I repeat, Java bytecode is just a subset of IL. So you can do in .NET everything you can do in Java.

Re:No Generics until 2006-2007 ?? (1)

gokeln (601584) | about 10 years ago | (#9899785)

And, if your application doesn't happen to be written in this "verifiable subset", what's your choice? Trust it?

I assume all the default CLR subsystems are defaulted to reject non-safe code?

I wonder how many other OS's MS is supporting with their CLR? If I want to run under Linux, what's the likelihood that an MS produced bytecoded program will run there unmodified and untested. (Not that Java is there yet, but at least that's their goal. MS's goal doesn't seem to be WORA. It seems to be Add More Nonstandard Stuff, so they have to use our system. This is an understandable goal-- and I support their right to do it-- but I don't have to be drawn into the trap, either.)

Pardon me for not trusting our Redmond friends, it's just that they have a track record of abuse. Maybe they have a new attitude of philanthropy I haven't noticed yet.

Re:No Generics until 2006-2007 ?? (1)

Cyberax (705495) | about 10 years ago | (#9900748)

Ansewer to question "to trust or not to trust" depends on circumstances. Remember, Java has native methods too (and you don't want to give permissions for execution of native methods to Java applet).

And I'm NOT a Microsoft friend. But .NET is a very well engineered system. And there are OpenSource implementations of DotNET. Right now I'm hacking Mono sources - it's a very well-written project.

Re:No Generics until 2006-2007 ?? (2, Insightful)

angel'o'sphere (80593) | about 10 years ago | (#9910541)

How can Java Byte Code be a subset of IL byte code?

JBC is completely stack oriented and very close to UCSD pCode. CLR is register oriented ... no way that you can 'map' the one to the other by changing code words. You have to restructure and recompile one byte code to the other.

The VMs have completely different abstraction levels as well. Java has no assemblies, they use the more generic approach via class loaders.

angel'o'sphere

Re:No Generics until 2006-2007 ?? (1)

Cyberax (705495) | about 10 years ago | (#9913824)

CLR is stack oriented also. It uses generic instructions (ie. one 'add' instruction instead of 'add_int', 'add_float', 'add_byte'...), so that's why JBC is a subset of CLR.

Look here, if you don't beleive me: IL instruction set [microsoft.com]

Re:No Generics until 2006-2007 ?? (1)

angel'o'sphere (80593) | about 10 years ago | (#9960343)

oops, you are right. I mixed up CLI/CLR with the Parrot vM, I guess.

Nevertheless I find the term "subset" inapprobriated. Further: CLI does not have one add instruction, only the notation in text is "add". Like Java it has (and needs to have) an individual instruction for every operand size (i1, i2, i4, i8, u1, u2, u4, u8 etc.)

Thanx for the pointer :D

angel'o'sphere

Re:Gosling, Java? Hmmm..... (1)

Bluelive (608914) | about 10 years ago | (#9899841)

So java changed to little for you ? Anyways mono will not have c#2.0 support for a while to come.

Re:Gosling, Java? Hmmm..... (1)

Cyberax (705495) | about 10 years ago | (#9903110)

Mono will certainly have support for C# 2.0 by 2006. And it will mature enough to be used in serious projects.

Re:Gosling, Java? Hmmm..... (2, Interesting)

Massacrifice (249974) | about 10 years ago | (#9898474)

And what exactly should this implementation have been? Its easy to criticize, but I would like to know what you are proposing instead. Really.

Because from what I read, java generics look very usable. My only complaint is that they werent in JDK 1.4.

Re:Gosling, Java? Hmmm..... (2, Insightful)

Cyberax (705495) | about 10 years ago | (#9898996)

Take a look at C# 2.0 draft. That's the right way to implement generics.

Basicly, Java generic classes are common classes with some compile-time information. Compiler automaticaly inserts type casts when it's neccessary. But resulting byte-code is just the same code with casts from Object. So the only advantage is more typesafeness.

In C# 2.0 generic class are not real classes, they are templates (as in C++) for classes with erased type information. CLR (Common Language Runtime) instantiates parametrized class when it's neccessary (in JIT-time), during instantiation erased types are substituted with specified types, it's the same mechanism as used in C++. Advantages of this implementation: faster code (no redundant casts), smaller size, ability to parametrize templates with promitive types.

Re:Gosling, Java? Hmmm..... (1)

pauljlucas (529435) | about 10 years ago | (#9899016)

Because from what I read, java generics look very usable.
In their very limited sort of way, sure. If you want to see what real generic programming can be like, have a look at "Modern C++ Design" by Alexandrescu. I've been using C++ since the cfront days, but, by only reading through page 14 of the book, I was astonished at the kinds of amazing things you can do with C++ templates that Java generics (as implemented) will never be able to do.

Re:Gosling, Java? Hmmm..... (1)

CableModemSniper (556285) | about 10 years ago | (#9900080)

Ok, but C++ templates aren't really generics either. They are basically sophisticated macros that look like generics, which has the side effect of allowing them to do all sorts of weird, powerful things. But it has downsides as well. Some more info [msdn.com]

Re:Gosling, Java? Hmmm..... (1)

pauljlucas (529435) | about 10 years ago | (#9900153)

Ok, but C++ templates aren't really generics either.
Sigh... nobody reads my sig. I never said C++ templates were generics. I said "generic programming" which is the umbrella term for writing programs where the type is somehow parameterized. Ada, Java, C#, and C++ all have different manefestations of "generic programming."

Re:Gosling, Java? Hmmm..... (4, Interesting)

Laxitive (10360) | about 10 years ago | (#9899222)

I agree with your sentiment, to a limit.

I don't think the generics in Java are very ugly at all. The interface - i.e. the syntax itself - is reasonably clean. The implementation ends up being just a fallback to the safe-dynamic-casting functionality of the JVM, but you don't know that when you actually use the generics.

I think the major benefit of generics is that developers can structure their code easier. They can tell the compiler that something is a List of Strings, and not a List of Objects. The performance aspect of it is less important.

Also, you are not considering that there are low-level VM operations that can mollify, to a significant degree, the potential performance hits caused by dynamic casting.

If you read papers related to Self (a Sun research language, based on smalltalk, using prototype-based OO semantics), you'll notice that there was a lot of work done on doing fast dynamic type-inferencing. A lot of that work has been rolled back into Java.

So let's say you have a List of Strings in Java. And there's a location in the code which grabs the first element from a list, and that first element happens to be a String all the time, or most of the time (this occurrs very frequently even in OO code - even though the strict semantics might imply polymorphic behaviour, in practice, a lot of code ends up being monomorphic anyway). The Java VM will actually figure that out at runtime, and compile a special version of the code, which does one pointer check (to see if the object you're pulling out is a string), and if that pointer check succeeds, makes a call to a custom-compiled version of the method based on that type assumption. If that check fails, then it falls back to less efficient code. So that piece of code that ends up dealing with Strings in practice, ends up doing only a single pointer check, instead of the heavyweight operations needed for a blind dynamic cache.

Even when you have limited polymorphic behaviour (code that is polymorphic over a handful of tyes), the java VM optimizes it by using polymorphic inline caches (I think this was added in the 1.5.* VMs).

And the nice thing is, this happens on the dynamic properties of the code, not just the static properties. So if you have some code that, according to the syntax, deals with plain Objects, but in practice, deals with instances of Foo a vast majority of the time.. then most of the time, it WILL execute with the type-assumption, with the added cost of a pointer check.

So yes, it would be nice if the generics system had support at the bytecode level. But it's not as much of a hit on performance as one might think. The jitter and its low-level optimizations compensate for that quite a bit.

I'm pretty sure Sun developers were aware of this when they decided not to mess with the VM bytecode definition when adding generics support to the Java language.

-Laxitive

Re:Gosling, Java? Hmmm..... (1)

Laxitive (10360) | about 10 years ago | (#9899258)

Dammit, I should have read my preview more carefully.

So that piece of code that ends up dealing with Strings in practice, ends up doing only a single pointer check, instead of the heavyweight operations needed for a blind dynamic cache.

The bolded section should have been:
blind dynamic cast

-Laxitive

Re:Gosling, Java? Hmmm..... (1)

Cyberax (705495) | about 10 years ago | (#9899431)

Yes, I understand that in some cases JIT can optimize casting away (I'm somewhat familiar with JVM source code). But it's not possible in all cases, and sometimes time spent in JIT optimizer annihilates optimizations.

Besides, it takes about 5000-9000 passes of code to make HotSpot to kick in and optimize a piece of code. It might be OK for long-running server applications, but it can't be tolerated in desktop apps.

Re:Gosling, Java? Hmmm..... (1)

Laxitive (10360) | about 10 years ago | (#9899555)

Like I said, I agree with your sentiments. It would be better to not have the runtime optimizer worrying about stuff that could be easily inferrable at compile/load time.

Sun decided that jvm compatibility was more important to them than any performance they could gain from low-level support for parametrized types. To a certain extent, I'm happy even with just the syntax and compiler-level support for it. It'll make my code cleaner and easier to follow, anyway.

-Laxitive

Re:Gosling, Java? Hmmm..... (1)

Cyberax (705495) | about 10 years ago | (#9899587)

New bytecode from JDK 1.5 is incompatible with previous JVMs. And that's the funniest thing.

Re:Gosling, Java? Hmmm..... (1)

Laxitive (10360) | about 10 years ago | (#9899683)

Really?!

If true, that's just plain silly. Can you provide more info? I'd like to read about this.

-Laxitive

Re:Gosling, Java? Hmmm..... (2, Informative)

Cyberax (705495) | about 10 years ago | (#9900410)

Look at Retroweaver [sourceforge.net] . This is a project aimed to make Java 1.5 features work on previous JVMs (by weaving bytecode). They have a nice explanation why JDK 1.5 is incompatible with 1.4 somewhere on their site.

Re:Gosling, Java? Hmmm..... (0)

Anonymous Coward | about 10 years ago | (#9913023)

Seems to just be the standard new classes and methods problem that seems to happen with each release of java- says nothing about bytecodes. For example, Swing was not in Java 1.0 and the bytecodes were never changed to support Swing later on. I have always considered Java backwards compatibility a farce because its of library creep.

Re:Gosling, Java? Hmmm..... (1)

greenrd (47933) | about 10 years ago | (#9956822)

In my experience (very limited - few hundred lines of code so far) - Retroweaver 1.0rc5 works fine with all language features, except JDK 1.4 assertions (ironically, because they're not a JDK 5.0 feature). But that's OK for a new project because you can just code your own assertion function.

Re:Gosling, Java? Hmmm..... (1)

Bert690 (540293) | about 10 years ago | (#9960096)

They have a nice explanation why JDK 1.5 is incompatible with 1.4 somewhere on their site.

I took a look at the entire site and found no such explanation. Any other suggestions? I'm curious too.

Re:Gosling, Java? Hmmm..... (0)

Anonymous Coward | about 10 years ago | (#9961250)

The bytecode is still the same in 1.5, but some of the language features use methods only available in 1.5. For instance: Auto(Un)Boxing uses the java.lang.Integer.toInt() Method that was introduced in 1.5.

Same thing for Generics (complicated, I don't know all the details) and the new for() loop (which uses the new Iterable interface).

Hm... can't remember if the other features need any new stuff. But: the version number of the class files would probably prevent a pre-1.5 JVM from loading a class file generated for 1.5.

murphee
http://jroller.com/page/murphee

Re:Gosling, Java? Hmmm..... (1)

Bert690 (540293) | about 10 years ago | (#9965382)

The bytecode is still the same in 1.5, but some of the language features use methods only available in 1.5. For instance: Auto(Un)Boxing uses the java.lang.Integer.toInt() Method that was introduced in 1.5....

Ah, OK, so it's not the JVM that's the issue with backwards compatability, but the lack of the appropriate library support. Interesting. I gather then that a 1.4 JVM would actually work just fine provided the 1.5 libraries were in its classpath.

I can't seem to find anything about this mysterious method "toInt()" in the 1.5 api [sun.com] specs, but I understand the issue now. Thanks.

Re:Gosling, Java? Hmmm..... (0)

Anonymous Coward | about 10 years ago | (#9913072)

My problem with Java generics are not so much that they have the potential to be slow but rather they are too transparent. The metaprogramming that has become popular using C++ templates is not possible with Java generics.

I understand something like the following is legal with Java generics:
List<Integer> lst=new List<Integer>;
Object obj=lst;
List lst2=(List) obj;
lst2.add(new Stack());
That seems like a hack to me. I want real type safety! Generics look okay until you start poking at it and then the ship just starts sinking real fast.

Re:Gosling, Java? Hmmm..... (3, Insightful)

bay43270 (267213) | about 10 years ago | (#9899547)

Moderators seem to be confusing Informative with Offtopic. What does Gosling talking about security have to do with Sun implementing generics? While sun was adding generics to Java, Gosling was building IDE components. Why blame him for Sun's reluctance to alter the JVM?

As far as how Sun implemented generics, the decision was purely political. Even Sun knows their solution is technically inferior. That doesn't make it wrong. They weighed the pros and cons and arrived at a different solution than you did, not because you know something they don't, but because they weighted the results differently.

Re:Gosling, Java? Hmmm..... (2, Funny)

Paradise Pete (33184) | about 10 years ago | (#9900081)

I lost all my respect to Gosling after a clumsy attempt to add generics to Java.

So you had respect for him, he does something in what you consider to be a clumsy way, and now you have NO respect for him? So if Gosling showed up and offered to help you with some project you'd shoo him away out of disrespect?

Re:Gosling, Java? Hmmm..... (1)

Alomex (148003) | about 10 years ago | (#9958880)

The right way to add generics to Java is a radical modification of JVM (Java Virtual Machine), but Sun didn't want to it.

Designerd are loath to make changes that create incompatibilities, lest they inconvenience the existing user base. This ignores the fact that the current user base is already inconvenienced by existing deficiencies in the language, and, moreover, in young languages such as java the existing user base is but a negligible percentage of the total users of the language through its life time.

Of course, one should avoid unnecessary incompatibilites, but once a glaring deficiency such as lack of generics has been identified it is better to bite the bullet and fix the problem once and for all, incompatibilities be damned.

(plus there is a way to avoid incompatibilities too, using version headers a la xml).

Very good read (1)

Alwin Henseler (640539) | about 10 years ago | (#9898204)

If you're into language/OS design, then go RTFA. It gives a good view of the why/how to do things, and some historic perspective.

Meanwhile... (1)

vonahsen (745394) | about 10 years ago | (#9898310)

Linus Torvalds (creator of Linux) interviews Bill Gates ("creator" of Microsoft) about God (creator of Universe) Come on, give us geeks some credit for knowing who some of the big-guys are.

He is not God. (0)

Anonymous Coward | about 10 years ago | (#9899173)

The "Bestia" is the creator of the Universe, is the creator of the Worlds, is the creator of the Things, is the creator of the Beings, is the creator of the Lifes, is the creator of the Souls (or Hells or Spirits), is the creator of the complex programs of ADN of many life beings, is the creator of the Deaths, is the creator of the Loves and Hates, is the creator of the "Final Day" (End of Universe, Begin of Eternity of the Universal Death) ,...

open4free ©

Re:He is not God. (0)

Anonymous Coward | about 10 years ago | (#9956900)

Wow, cool! Where's that from?

What about turning off bounds checking? (2, Interesting)

Chemisor (97276) | about 10 years ago | (#9898618)

> for example, in Java, you can't go outside the bounds of an array. Ever. Period.

As I recall, it used to be possible to turn off runtime bounds checking. I also think that most people would do this once the code is debugged. Did this feature get disabled recently?

Re:What about turning off bounds checking? (2, Insightful)

Anonymous Coward | about 10 years ago | (#9899509)

As I recall, it used to be possible to turn off runtime bounds checking. I also think that most people would do this once the code is debugged. Did this feature get disabled recently?

The language is defined so that this is impossible. See here. [sun.com] If you were to disable bounds checking, then you would be violating the language spec, and therefore it would not be Java. It would be the same if you wrote a JVM that ran bytecode but never checked array accesses. This sort of stuff may be useful for debugging or academic purposes, but it's not something one can do without redefining what it means to be Java.

Re:What about turning off bounds checking? (1)

angel'o'sphere (80593) | about 10 years ago | (#9910562)

That "feature" never existed in Java. You likel mix it up with Pascal :D

angel'o'sphere

JVM and virtual servers (5, Insightful)

gtrubetskoy (734033) | about 10 years ago | (#9898900)

I like Java as a language, what I don't like is the JVM.


In this article he mentions that the idea for the JVM came from the days when he wrote an emulator and found that his emulator actually performed better than the compiled C code. With the most modern JVM's, tests show that their performance is very close to, and often exceeds that of compiled code.


But the problem is that this is done at the expense of the performance of the overall server. UN*X (and other OS's) go to great lengths to make different programs perform and share resources in the most efficient manner. Scheduling, memory management, IO optimization, all that wonderful stuff, that makes a bear like emacs start almost instantaneously even on an old P90.


As is evident from my sig, I've been spending quite a bit of time in the past year tinkering with virtualization (The Linux Vserver in particular). The amazing thing is that all the optimizations of Linux still apply even if you're running two dozen virtual servers on the same machine (the code for emacs is still shared across processes, even in different virtual servers). Except for, sadly, the JVM. This is why you see many VPS hosting providers forbid running Java and sell a separate "Java server" at a much higher price. And we're considering doing the same. In our experience, a typical VPS customer running Apache, sendmail and a few other things uses 200-400MB of virtual memory, much of which is shared, whereas a customer running Tomcat or, even worse, JBoss use 1-3GB of virtual memory, next to none of which is shared. (Note that virtual memory != physical memory, but that's a separate discussion.


Given that virtualization is becoming more and more popular these days (and even Solaris now has "zones", which are same thing as Linux Vserver or FreeBSD jails), I think the folks at Sun need to think about where the JVM fits into a virtual server.

Re:JVM and virtual servers (2, Informative)

HappyClown (668699) | about 10 years ago | (#9956972)

Agreed this is indeed a problem, JVMs can be quite memory hungry. However there are several ways to address this. First of all, it's possible to have a single application server instance host multiple web applications. In fact, this is half the point of having an application server in the first place! Sure there's extra effort involved in getting the security and other configuration right, but it will save you gobs and gobs of memory.

Additionally, Sun will be providing new functionality in J2SE 1.6 (6.0?), due out in beta this year, to allow JVM resources to be shared across separate instances of the JVM.

Take a look at http://research.sun.com/projects/barcelona/papers/ oopsla00.pdf [sun.com] to see how Sun plan on addressing this.

Re:JVM and virtual servers (0)

Anonymous Coward | about 10 years ago | (#9957274)

Well, I raised this very point a long while ago (2000, in fact) and the post "too much cream in the coffee" was an interesting re-read after I saw your comments.

Basically, Java p-code is not shared across processes because it is treated as data. This is just plain dumb. I do not know, interestingly, if Microsoft's .NET framework shares this crippling design defect, would anyone care to comment?

Nice comments on GC (1)

tcopeland (32225) | about 10 years ago | (#9899036)

We do parallel garbage collections. We actually have multiple garbage collectors. On the high-end systems that run on multiprocessors, what we'll tend to do is run these concurrent garbage collectors that allow the garbage collector to run in parallel with active code, and we'll dedicate some number of processors to garbage collection.
Nifty. Garbage collection seems to be one of the few areas where the academic research actually trickles down into real applications.

Java snake oil (0, Flamebait)

pauljlucas (529435) | about 10 years ago | (#9899178)

So, for example, in Java, you can't go outside the bounds of an array. Ever. Period.
Of course you can. The JVM then throws an exception. Unless you have a test case that specifically tests array bounds, you're never going to be sure that your application won't die at 2:36am when you get paged.

The snail-oil marketing around Java has always annoyed me. "Java has no pointers, so no more pointer errors!" What crap. Kindly explain NullPointerException then. Sure, you can't do some of the free-wheeling things you can do in C with pointers, but Java does have pointers (hidden by a coating syntactic sugar).

The Java snail-oil salesmen try to convince you that your code will be bug free because certain classes of errors just can't happen. Again, what crap. They can happen. The only thing the JVM does is tell you precisely when they happen. Is this better than insideous bugs in C that change memory they shouldn't but don't crash as a result until later? Certainly. But the bugs still happen in Java. And they can be insideous in different ways.

Re:Java snake oil (2, Insightful)

Laxitive (10360) | about 10 years ago | (#9899360)

The Java snail-oil salesmen try to convince you that your code will be bug free because certain classes of errors just can't happen. Again, what crap. They can happen. The only thing the JVM does is tell you precisely when they happen. Is this better than insideous bugs in C that change memory they shouldn't but don't crash as a result until later? Certainly. But the bugs still happen in Java. And they can be insideous in different ways.

Ah, snail oil, it does wonders for the skin ;)

Anyway, yes, it IS better to know WHAT is happening and WHEN it happens, than for it to blindly happen and cause problems later. This is because it bounds the code and its runtime behaviour. A NullPointerException or array out of bounds exception is not nearly as insidious as random memory getting clobbered. For one, it eliminates an entire class of possible bugs: buffer overflows. They simply wont happen. Knowing that there will be certain strict bounds on the runtime behaviour of the program is extremely important.

-Laxitive

Re:Java snake oil (2, Insightful)

Shillo (64681) | about 10 years ago | (#9957280)

Hear, hear!

My coworker is currently recovering from 3 days' bugfixing session.

In C++, he called a virtual method off uninitialised pointer. The random piece of code that got run somehow managed not to crash the program immediately. Instead, it overran stack in random places. The program would crash in a corrupted STL list, in a completely unrelated spot. And it wasn't compatible with Valgrind.

Frankly, I'd take bugs in Java code instead of this anytime.

--

Re:Java snake oil (3, Insightful)

Anonymous Coward | about 10 years ago | (#9899441)

The Java snail-oil salesmen try to convince you that your code will be bug free because certain classes of errors just can't happen. Again, what crap. They can happen. The only thing the JVM does is tell you precisely when they happen. Is this better than insideous bugs in C that change memory they shouldn't but don't crash as a result until later? Certainly. But the bugs still happen in Java. And they can be insideous in different ways.

Calm down, buddy. I never saw anything that said that Java will eliminate every bug known to man. I think everyone understands that "you can't go outside the bounds of an array" means "you can't go off the end of an array, corrupt memory, and do god-knows what to your application's state". You openly admit that this is better, yet you attack the "snake oil salesman" for bringing it up. It sounds like you have an axe to grind.

Re:Java snake oil (1)

pauljlucas (529435) | about 10 years ago | (#9899905)

The snake-oil salesmen don't bring it up using precise langauge. Try reading Sun's own literature about why Java is better. Any PHB would come away thinking that no pointer errors can ever happen. Ever.

HotShot Virtual Machine? (1)

heffel (83440) | about 10 years ago | (#9902835)

From the article:
"If you look at the just-in-time compilers and things like the Java HotShot Virtual Machine, they are very much oriented toward maximizing throughput"
Is this a typo? I've heard of the HotSpot virtual machine, not HotShot, a Google search for "HotShot Virtual Machine" didn't come up with anything that would clarify this.

Trolling in the article? (0, Troll)

Schwarzchild (225794) | about 10 years ago | (#9906155)

EA I'm curious about a couple of other languages. My favorite language to hate is Perl. It seems like no real thought was given to the language. It kind of grew over the years. So it's just really deeply, deeply ugly.

This is a boneheaded remark. You could say the same thing about Sendmail. Perhaps he's just trolling?

JG Well, yes, but that's part of its charm. It's sort of the resurrection of TECO. Everything in it is about text, so if the data you care about is text, it's pretty nice. I actually like Perl. I can't say I'm real good at it, and I certainly wouldn't want to do any big projects in it. It's sort of a maintenance nightmare. It has very little in the way of structuring and abstraction and all the other things that one would need to do truly industrial-strength software. But as a language to do narrowly defined mind puzzles, it's pretty entertaining.

Wow, is Gosling really that clueless?

Re:Trolling in the article? (0)

Anonymous Coward | about 10 years ago | (#9957190)

if that's "clueless," everyone should be. PERL personifies the annoying side of "geek" - passed the point of being useful and funny to downright disgusting.

Re:Trolling in the article? (1)

SageMusings (463344) | about 10 years ago | (#9961992)

And in the same breath, he actually goes on to say he likes TCL. Hands down, TCL is the WORST language I have ever explored. I wasted a week trying to like it, once upon time, because I liked the Tk widgets (this was back in 1998).

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>