Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Interview With the Father of Java 107

Posted by Zonk from the hot-brewed-programming-language dept.
Eh-Wire writes "The Globe & Mail interviews James Gosling after a keynote talk to Sun developers in his home town of Calgary. His thoughts and comments regarding the 'dead end' oil industry, disconnected Telco strategist, and unleashing 'creative weirdoes' makes for an interesting read." From the article: "Java is evolving. It's sort of embedded in the social experiment that is the Internet. There's been tremendous adoption of Java for building large-scale enterprise apps. It's worked tremendously well there. There's been all kinds of growth lately in cellphones and more and more embedded systems. It's all about making the environment around us more intelligent."
This discussion has been archived. No new comments can be posted.

Interview With the Father of Java More

Interview With the Father of Java

Comments Filter:
  • It's sort of embedded in the social experiment that is the Internet. There's been tremendous adoption of Java for building large-scale enterprise apps.

    I was wondering why everything online has been slower lately.
    • There are 11 types of people in the world: those who can count in *unary*, and those who don't need to use their fingers and toes, er, "can't". :-)

      Personally, my money is on the unary group being the larger of the 11 / 10 / 2 groups.

      Off-topic as can be, happy April 1...
  • And here I thought that James Gosling invented PHP [uncyclopedia.org].
  • ...but what state is Calgary in?
  • What did someone accidentally use the GMT clock to set off the April fools script?
    • Why wouldn't they? It's an international site, not specific to one country, and the closest thing we have to a standard time format is GMT.

  • Shameful exploitation of VIPs at Sun (Score:5, Insightful)

    by Anonymous Coward on Friday March 31, 2006 @08:43PM (#15038810)
    I attended the Sun Developer Day in Calgary this week that Mr. Gosling gave the "keynote" at.

    The talk was almost the exact same rambling "Java is everywhere..." speech that he's been giving for years now. The highlight was when his Mac completely locked up during the presentation and he had to do a cold restart! He claimed it's never happend before in 5 years of Mac use... ...Hmmm, I'm sensing a unique opportunity to enrage both the Apple zealots AND the Java zealots in one post! ;)

    Anyway, my point is that Sun has a long history of exploiting some of their top talent by forcing them to travel around the world giving these lightweight marketing talks at corporate events. I remember in the late 90's it was the same thing with Bill Joy. They had him doing so many talks in different cities every day that the actual meeting was in a room at the airport! He was literally on the ground for less than 2 hours, then off to the next stop.

    They fly these guys around on these whirlwind trips to try to draw people to marketing events they would otherwise not bother with. It's seems like such a waste of talent/time. Maybe Sun would be better off letting Gosling and his ilk work on interesting projects that might actually provide Sun with new revenue sources, or at least give them something new and interesting to talk about when they do have to give speeches.

    Even at JavaOne, Gosling's role in Java has been reduced to little more than the "funny looking guy that throws out the T-shirts". It's sad really, I never thought I'd feel sorry for James Gosling, but on Tuesday I did.

    • As somone who worked for a Mac centric company for a long time. We developed in Java for cross platform use. But Apple dicked with java just enough in the 1.4 day to damn audio and video, so we could create cross platform apps that actually work from windows, solaris, mac, bsd, etc. When our chat product when audio and video via the JVM, the only one that would not work was the mac, cause apple dicked with the jvm. God knows which could have interefered with ichat. WAIT a minute. Ichat was originally a c

  • what I don't get is (Score:1, Interesting)

    by sqar ( 884082 )
    why Java is so suboptimal compared to languages like Objective-C and APIs like OpenStep/Cocoa. I mean Java is like some sort of second infusion of Coffee (and we all know that only green tea is better at the second infusion ;-) ): you know what it is supposed to be but it just doesn't taste like the real thing.

    Doubly astonishing so since SUN was co-developing OpenStep in team with NeXT, so they should have known how to design a proper API and what language features are needed for this. Now the Java API i

    • Re:what I don't get is (Score:1, Insightful)

      by Anonymous Coward
      Collection classes that overlap in functionality? Somebody here doesn't understand interfaces and OO design. That somebody is you.
      • So tell me why there is java.util.Vector AND java.util.ArrayList. Same for java.util.Hashtable and java.util.HashMap, java.util.Dictionary and java.util.Map subclasses ...

        That just doesn't look well designed for me

        sqar
        • my understanding of the overlap is to ensure compatibility with older versions. since the whole idea of java is total platform independence and they have improved the java language thru release versions they keep the old api classes to make sure that those classes will still work, not to mention the ability to reference old code, or let the old foggies who've been coding in java from the begining continue to use their old outdated classes 8P.
          • Sure, I understand all the reasons for those duplications. My original "rant" was not about backwards compatibility but the poor start of Java given the fact that SUN was a (marginal?) co-author of OpenStep so one could expect they've learned something from that co-authorship. Obvoiusly that wasn't the case, Java is worse than OpenStep in many (not all) regards. cheers, sqar

  • Embedded and Java shouldn't be seen together! (Score:4, Informative)

    by Bad Mamba Jamba ( 941082 ) on Friday March 31, 2006 @09:57PM (#15039329)
    There's been all kinds of growth lately in cellphones and more and more embedded systems.

    As an unfortunate software developer on one of Sun's high profile embedded Java projects, OCAP, it irks me to see Java and Embedded listed in the same sentence. I could rant for days on the shortcomings of Java and it's unsuitability for an embedded environment but to name some of my biggest peeves...

    1. Any language without unsigned primitive types doesn't belong in embedded land. Embedded systems frequently use unsigned data types. Making me cast up to a bigger primitive size and doing all kinds of bit manipulation gyrations to make unsigned byte data come out right is just wrong.

    2. Most embedded implementations don't have room for a JIT compiler. So you end up interpreting everything or precompiling on the way down to the embedded device. Most embedded devices these days still have pretty lame CPUs in them so everything Java is extra extra slow even relative to a desktop counterpart. Especially if you're doing an app with any kind of graphics. As for pre-compiling...this simply isn't an option in some deployments...say OCAP for instance!

    3. Many embedded environments use multithreading to process various IO tasks etc. Having what amounts to a critical section for your only means of synchronization (and yea Java 5 tries to solve this but most embedded devices are still back on 1.x implementations of Java) leads to one heck of a deadlock nightmare if you aren't very careful with your design. I need not cite the performance hit here either if you're lazy with your syncs. I also need not mention that the thread scheduling is left unspecified so your app may run OK on one JVM but when you port ot another there's no telling...

    4. Java requires a lot of memory if you really want to do something useful. Especially anything graphics related. Most embedded devices don't abound with a ton of memory. As such you end up garbage collecting more and running into problems. Garbage collection can be a costly operation per #2 above. And finding a memory leak in a Java program ain't no picnic either. Especially on an embedded device where you may or matynot be able to get tools in there to see what's going on.

    Yeah you can circumvent some issues if you're smart about your design and don't do stupid things but so far most embedded Java developers I've met are imports from desktop/server land and don't think about this stuff so you can imagine the mess you end up with.

    Just my two cents...

    • Unsigned types (Score:2, Informative)

      by Anonymous Coward
      As someone who has also use Java for low-level network stuff, let me just confirm, you are absolutely correct, lack of a simple unsigned byte type is hyper-annoying. I would like to have an unsigned byte type and easy operations to do bit manipulation. That stuff can be some of the most annoying part of code to debug. If some bit gets set in the wrong place, all of Java's fancy strong typing and all that doesn't provide any help. The only thing that would help would be better instructions or some helper
    • I don't know about embedded systems, but java has been a huge success on mobile phones, mainly due to the fact that it's so prevalent. Most mid and high end phones have some sort of hardware acceleration. ARM have jazelle and Texus Instruments have most of the mobile phone functionality implemented on one chip and the KVM is built-in with 2d graphics acceleration.
      I know that J2ME could have been designed better (mainly due to the fact that it's a committee), but it's not so bad that you can work around the

  • Java bloat (Score:1, Informative)

    by Anonymous Coward

    Now I know I am going to get mod down, tossed to the wolves, raked over the coals with an inbox full of your nuts -- but here goes because after spending 4 years in Java I now have an opinion.

    Java is bloatware and sells hardware. It is great on a desktop as an applet or even as a program running locally where you have 2GB or ram and dual procs to itself. But it has no freaking business on a server. In fact, those writing server apps in Java are plain utterly stupid.

    Lets do the math... I have 600 users

    • Um, what? (Score:5, Informative)

      by Anonymous Coward on Saturday April 01, 2006 @04:33AM (#15040818)
      Where does this 256mb per user figure come from? Any app that requires that much mem per user, and isn't doing something like ray tracing the next King Kong movie, is broken. Yeah I can write utterly broken C++ that also sucks up 256mb per user to log in to a website, but that has nothing to do with the language.

      I think you probably don't understand how Java server stuff works. Your reference to Apache being part of a Java server deployment shows that. It used to be, back in the old days a few years ago, that people often installed Tomcat and Apache together using a connector. I don't know anyone who still does this. Tomcat 5 servers static content about as fast as Apache.

      As for threading: If you're writing a web application, you don't need to write any threads. You need to give a little bit of thought to threads, because your Servlets are objects and they can be used by multiple threads at the same time. Handling this is quite trivial: you just don't touch any instance variables from methods in your servlet. If you don't want to try to figure out threading, that's all you need to know. Tomcat will do all the rest.

      Again, I have no clue where you got that 256mb per user, but I'll clarify a few points. In a typical Java Servlet application, which would use Tomcat (or similar) to serve an application where users log in, do stuff, and data are stored in a DB, this is how resource use will work:

      • Threads: Tomcat can be configured to create however many threads you want. A few dozen to a few hundred is typical. It certainly does NOT create a new thread per request. Just like Apache 2 in threaded mode (which is not its default mode btw) it creates these threads and has them hanging around until they are needed. Just like Apache 2 in threaded mode, these are plain old operating system threads
      • Threads again: Your reference to threads, and developers not knowing that Java is threaded, and again this 256mb per user makes me think that you are assuming that every user needs a separate JVM. This is not the case on any server-based app that is correctly written. Yes I can imagine some bozo creating a web app where Apache forks off a ne JVM for each user session... but wow, that is an inconceivably bad way to design a web app, ie, using a JVM for doing CGI. That's fighting hard against the design and the right way to do it, so of course it won't work. You do not Java for doing CGI servers! One web application = one JVM per machine = one JVM overhead per machine. If you are looking at any deployment where that is NOT the case, it was done by someone who is incompetent.
      • Memory: Sessions are created with a simple session map. A session itself takes up about 1k of memory. If you're smart, you store a user ID in the session and then the servlets can use that to interact with the database. So you're still storing less than 2k per user in memory in the session. It's no different from how PHP is often used. If you're really clever you use Hibernate and store a lightweight user object in the session, and have Hibernate do all its magic caching and proxying. You still have only a few K per user session to store.
      • CPU: Any real-world benchmarks Java just isn't slower. I would expect that a Java web app would use less CPU than a PHP app, because PHP has to parse and compile some large subset of the application with every single request. In Java, the whole thing is compiled to bytecode, which has probably been compiled to native assembly, and it's all loaded in the thread, in memory, ready to go when a request hits it.
      • Garbage collection: This is a problem that Java has. The GC does have to use a global lock and stop every thread (I believe) at certain times to do GC. In practice, this isn't so bad on web server apps. It's worse on desktop apps, which do in fact freeze up for a few seconds at a time occasionally.

      I really don't think you understand how these things work, and if you have real-world experience with Java webapps, then the ones you are thinking of were written by clowns.

      -----------
      Contact management, calendar management, sales automation [contempo.biz]

      • Re:Um, what? (Score:1)

        by Anonymous Coward
        The garbage collection is still a problem it has to be said though a couple of things can really help depending on your application. With J2EE apps something I've found (specifically running under WebSphere on AIX though the technique should work well enough on anything) is to use smaller JVM's (say about 512MB each) and let WAS distribute load around them as it sees fit. The upshot of this is that although the pause still occurs it is much shorter (there's less to deal with) and doesn't occur for every t
    • Java is for those too lazy to learn C/C++
      ROTFLMAO..

      Thats my new signature.

    • Interesting numbers, I have 2000 users serviced by a single 128MB Tomcat running Jetspeed/Turbine, and has been running that for years now (Uptime can be measured in years)
    • if you have to restart the VM for some reason you kick all users off. Messy.

      With Tomcat, if I have to restart, it doesn't kick all the users off. Their sessions are serialized to disk and they can continue where they left off once the app starts again.
  • I assumed this was just another April fools day joke, especially when someone commented that Calgary was in Texas (!!omg!!), but it seems like the article went up too early for that which means... it is real?

    Java has some uses, some really good uses, but I stopped waiting for it to change the world years ago, Sun should pour the money it uses on pretending Java is going to change everything into development instead, then maybe some day we can actually use Java to make a decent graphical application, render
  • Wouldn't you have expected him to say instead that it was intelligently designed?
  • http://static.flickr.com/19/121338473_07823a9da0_b .jpg [flickr.com]

    yes, the guy in the yellow shirt is the java guy.

    http://static.flickr.com/19/121342959_449ed7dea0_b .jpg [flickr.com]

    it seems that java _can_ defend itself ;)
  • Having written in Java, C++, and now in the process of learning C#, I have to say that I prefer C#. It fixes a lot of what's wrong in C++, and it's new enough not to have suffered the bloat that Java has.

    Yes, bloat.

    If I never see another BuffereredDataStreamBufferReaderWriterBufferStrea m Reader (or whatever that was), it'll be too soon. Bleh. Java is soooo last-century.

    Don't start with me about Microsoft-only with C#. There's Mono, you know, so why not broaden that Linu-centric viewpoint you have,

Slashdot Top Deals

Don't be irreplaceable, if you can't be replaced, you can't be promoted.

Close