Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Gosling on Computing 74

Posted by CowboyNeal from the teco-shoutouts dept.
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.'"
This discussion has been archived. No new comments can be posted.

Gosling on Computing More

Gosling on Computing

Comments Filter:

  • Good idea. (Score:5, Insightful)

    by TheLink ( 130905 ) on Friday August 06, 2004 @04:32AM (#9897618) Journal
    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. (Score:2, Insightful)

      by Anonymous Coward
      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 (Score:5, Interesting)

      by Anonymous Brave Guy ( 457657 ) on Friday August 06, 2004 @06:40AM (#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...

      • 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 mistak
      • 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...)

        • 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

          • 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 m

      • 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.

    • You're right, and that's the number one reason why Java is not written in C. Oh wait...
      • 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.
        • 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>
          • 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 t

  • Gosling, Java? Hmmm..... (Score:5, Informative)

    by Cyberax ( 705495 ) on Friday August 06, 2004 @04:37AM (#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.
    • Not really something you can hold gosling personally responsible for. And java generics arent as bad as you try to make them seem.
    • 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.
      • 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
      • 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.

        • 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]

          • 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..... (Score:5, Interesting)

      by Laxitive ( 10360 ) on Friday August 06, 2004 @10:24AM (#9899222) Journal
      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
      • 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
      • 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.
        • 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
          • New bytecode from JDK 1.5 is incompatible with previous JVMs. And that's the funniest thing.
            • Really?!

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

              -Laxitive
              • 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.
                • 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.

                • 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..... (Score:4, Insightful)

      by bay43270 ( 267213 ) on Friday August 06, 2004 @10:53AM (#9899547) Homepage
      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.
    • 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?

    • 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
  • 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.
  • 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.

  • What about turning off bounds checking? (Score:3, Interesting)

    by Chemisor ( 97276 ) on Friday August 06, 2004 @08:59AM (#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? (Score:2, Insightful)

      by Anonymous Coward
      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
    • That "feature" never existed in Java. You likel mix it up with Pascal :D

      angel'o'sphere

  • JVM and virtual servers (Score:5, Insightful)

    by gtrubetskoy ( 734033 ) * on Friday August 06, 2004 @10:04AM (#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.

    • 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?)

  • 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.
  • 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.

  • 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 lik

    • 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).

Slashdot Top Deals

We must believe that it is the darkest before the dawn of a beautiful new world. We will see it when we believe it. -- Saul Alinsky

Close