Javarrrgh!

by · March 19, 2013

Tags:

Christopher Carr

Christopher Carr does stuff and writes about stuff.

Related Post Roulette

55 Responses

  1. Morat20 says:
    March 19, 2013 at 2:48 pm

    I haven’t been watching the news the last few days, but in general you should turn Java off. It appears to have some security holes the size of a small bus that will allow Bad Things To Happen to you.Report

    • Mike Schilling in reply to Morat20 says:
      March 19, 2013 at 2:55 pm

      Yeah. Java is a great language for writing servers, an OK language for writing standalone client apps, and a really crappy thing to have running inside a browser.Report

      • Brandon Berg in reply to Mike Schilling says:
        March 20, 2013 at 12:20 am

        That stuff you said applies to the runtime. Java the language is mediocre at best.Report

        • Mike Schilling in reply to Brandon Berg says:
          March 20, 2013 at 2:03 am

          I disagree, but maybe that’s a generational thing. I’m a big fan of strong typing, and not much interested in minimizing keystrokes. Most young programmers I know reverse those, and thus prefer weakly typed languages like Python or Ruby.Report

          • Brandon Berg in reply to Mike Schilling says:
            March 20, 2013 at 3:04 am

            I prefer strong typing for anything serious, too. But there are languages with strong type inference, like Scala, which provide strong typing with fewer keystrokes. My main complaint about Java is the terrible support for higher-order functions.Report

            • Mike Schilling in reply to Brandon Berg says:
              March 20, 2013 at 4:38 pm

              That’s valid. You can do things along those lines with Java by using an instance of class that implements some interface as the equivalent of a function (in particular, an anonymous class), but it is a lot more cumbersome than in Scala or Groovy, or even JavaScript.Report

              • Brandon Berg in reply to Mike Schilling says:
                March 20, 2013 at 11:21 pm

                Right. You can do it, but the problem is that it’s so cumbersome that it’s often not worthwhile at all. What makes this really frustrating is that they’re obviously not even trying. For years there have been proposals for minor syntactic changes that would allow anonymous single-method interfaces to be implemented much more concisely, and they haven’t been picked up despite the fact that it’s the sort of thing an intern could do in a week.Report

              • Brandon Berg in reply to Brandon Berg says:
                March 20, 2013 at 11:30 pm

                Anonymous implementations of single-method interfaces, rather. Not anonymous interfaces.Report

              • Morat20 in reply to Brandon Berg says:
                March 21, 2013 at 10:51 am

                Effectively, you can do anything in any language. The question is: Do you want to? 🙂

                There’s a reason we have a zillion programming languages — they’re all optimized for different things.

                Java’s just a bit old PITA though, which I avoid.

                C#’s a fairly nifty little compromise that I’m fond of, although admittedly not for big projects. There’s a lot in it I’m not fond of, but it’s been quite a useful language for me the last few years. (Not professionally, though — all C++ here. And Fortran. And some other legacy crap. No Ada, thankfully).Report

              • Mike Schilling in reply to Morat20 says:
                March 21, 2013 at 11:06 am

                My theory is that, having sued Microsoft for, among other things, introducing method pointers into Java, Sun found it politically impossible to do the same. That’s why they invented ugly, cumbersome anonymous classes to do that job.Report

              • BlaiseP in reply to Mike Schilling says:
                March 21, 2013 at 11:23 am

                Why on earth would anyone want to use a function pointer in Java, given that it’s a dynamic language from the get-go? An object reference off the stack will give you access to the function.Report

              • Mike Schilling in reply to Mike Schilling says:
                March 21, 2013 at 12:21 pm

                For the kind of programming Brandon brought up, where you want to compose or otherwise operate directly on functions. Or, in the simplest case, to register a callback.Report

              • BlaiseP in reply to Mike Schilling says:
                March 21, 2013 at 4:52 pm

                Simplest possible callbacks in Java:

                public interface YooInterface { public String yooCalled(); }

                public class YooFoo implements YooInterface {
                @Override
                public String yooCalled() { return “YooFoo”; }
                }
                public class YooBar implements YooInterface {
                @Override
                public String yooCalled() { return “YooBar”; }
                }

                public class YooMain {
                public YooMain() {
                register( new YooFoo());
                register( new YooBar());
                }
                public void register(YooInterface someYoo) { say(someYoo.yooCalled());}

                public static void main(String[] args) { new YooMain(); }

                private void say(String s) {System.out.println(“YooMain: ” + s);}
                }

                // output:
                YooMain: YooFoo
                YooMain: YooBarReport

              • Mike Schilling in reply to Mike Schilling says:
                March 22, 2013 at 3:52 am

                I want to register a callback for an object that, oddly enough, does things other than get called back.

                Current Java: (Note that I will probably fish up the syntax, because it’s damned near impossible not to. This is the point.)

                obj.registerChangeHandler(new ChangedCallback() {
                public void changed(Event ev) {
                System.out.println(“Change event : ” + ev);
                }
                });

                Hypothetical Java with method pointers:

                obj.registerChangeHandler(this.changed);

                private void changed(Event ev) {
                System.out.println(“Change event : ” + ev);
                }

                Hypothetical Java with methods as first class objects:
                obj.registerChangeHandler(
                void (Event ev) {System.out.println(“Change event : ” + ev);}
                );Report

              • BlaiseP in reply to Brandon Berg says:
                March 21, 2013 at 11:12 am

                Ecch, with programming languages, the Second Law of Rocketry applies in these cases: “with enough thrust, anything will assume an aerodynamic form” which just means with a big enough rocket, you can get anything to fly. Which explains the Space Shuttle, a flyer made of bricks.

                Java is only a PITA if you don’t know how to build effective delegates. Lots to dislike about it, especially the uppercase numeric classes, Integer, Double and the like. It’s the frameworks which have given Java a bad name, especially the early incarnations of EJB, which would in turn give rise to better frameworks such as Hibernate.

                Every time I hear someone carrying on about how other languages are so great and the most-used languages are all crap, I just smile. I don’t care what language I write in any more. I write what the client wants. I can write in the most appalling languages: PHP is a true horror story but can be written reasonably well in classes. JavaScript is a right bastard of a language but again, properly compartmentalised, it does the job. Scala is interesting but really, it’s not terribly popular and I don’t see much demand for it. C# is just Microsoft’s admission that lots of people want to write Java and nobody wants to write in their screwed up VB.NET any more.

                Technology zealots always end up with their foot in the bear trap. “C’mon in, the water’s fine! I got HelloWorld to compile!” … and then the database and concurrency sharks come in to feed… mwahahaha!Report

              • Morat20 in reply to BlaiseP says:
                March 21, 2013 at 3:48 pm

                Hey, there’s actually a whole bit of theory and some nifty math that proves it. 🙂

                The short version is that since it all compiles down to machine code in the end, if your language is functionally complete you can get there one way or another.

                I think. Language and Compiler theory was quite some time ago, and I was really only there to pick up some rather nifty parsing techniques and get a bit of theory.Report

              • BlaiseP in reply to Morat20 says:
                March 21, 2013 at 3:58 pm

                BlaiseP’s Theory of Profiling:

                If it takes ten times longer to write a more-efficient module than will ever be saved in reduced execution time over the life of that module, fire the programmer.Report

          • Kim in reply to Mike Schilling says:
            March 21, 2013 at 4:06 pm

            ugg. those sorts of people never had to make arrays in basic (but basic doesn’t have arrays!… it’s got strings, dammit).

            strong typing is nice in most languages. in java it’s just a bitch — too much casting needed. all the fucking time.Report

    • Christopher Carr in reply to Morat20 says:
      March 19, 2013 at 3:01 pm

      It’s only happening when I am forced to use Internet Explorer by various IT minders. Otherwise, I’d be using a “modern browser”, like Chrome.Report

  2. Kazzy says:
    March 19, 2013 at 2:49 pm

    You’re doing it wrong.Report

  3. BlaiseP says:
    March 19, 2013 at 3:01 pm

    Here’s the problem in a nutshell: I’ve been writing Java since the first night it was available from Sun.

    The problem isn’t in Java-the-language. It’s in your browser. It stands to reason you do not want your browser to execute any old program it finds on a website. To that end, the browser executes Java programs in a Sandbox, supposedly a safe area, where such programs can do no harm to your machine.

    In the early days of the Internet and Java, a certain kind of Java program called an Applet could run in these Sandboxes. Developers hated them. They are now mercifully very rare: I do not allow them on any site I administer. Their security mechanism was very bad. Oracle never improved it. Applets have been stinking up the basement every since.

    Just turn off Java in your browser. It will not affect anything else you do. You are only forbidding the execution of these Applets.

    EDIT: JavaScript is NOT Java. Many websites use JavaScript, they are not affected by this leaky Sandbox issue.Report

    • Christopher Carr in reply to BlaiseP says:
      March 19, 2013 at 3:03 pm

      So why is DHS involved?Report

    • Christopher Carr in reply to BlaiseP says:
      March 19, 2013 at 4:50 pm

      “In the early days of the Internet and Java, a certain kind of Java program called an Applet could run in these Sandboxes. Developers hated them. They are now mercifully very rare: I do not allow them on any site I administer.”

      So, to continue your sandbox analogy then, Applets are like cat feces?Report

      • dragonfrog in reply to Christopher Carr says:
        March 19, 2013 at 6:32 pm

        Even in the absence of sandbox analogies, applets are like cat feces.Report

      • BlaiseP in reply to Christopher Carr says:
        March 19, 2013 at 7:22 pm

        My first professional Java deliverable was a Java Applet. It worked very well and it was reasonably secure. Some of the following might go zooming over your head: you asked about Applets and I will tell you about them, like the Ancient Mariner of his time at sea, for much of it has to do with problems in existing web security.

        Applets were, in their day, a good way to do graphics over the web. Browsers had no good standard but Java was cross platform. Applet provided useful controls and a richer interface than anything the web has yet to offer: perhaps HTML5 approaches the functionality of Applet.

        And Applet did something the Web still does not do well: for the Applet was stateful, like any other program you might run on your machine. HTTP was and is a stateless protocol. Ever try to hit the back key on your browser, trying to go back to a previous page of a web-based form, only to see the poor browser lose its tiny little mind? Ever lost a comment here?

        Statefulness is important. The Web is very bad at statefulness. The web was never designed for it. Now we are obliged to play with SESSION variables at the back end, shooting your browser HTML and CSS and JavaScript, trying to keep ten pounds of shit in the three pound sack by keeping seven of those pounds in midair. Web based programming is approaching the state of where mainframes were thirty years ago. You’ve just gotten used to how bad it is.

        Applets came in three flavours: unsigned, signed and self-signed. Unsigned applets couldn’t write or read from the client file system. It could however open a connection to the machine which had launched it. Signed applets could use CA-generated certificates, much as existing web security operates now, which is not without its problems, may I add: running off to validate a cert, only to find the granting authority won’t respond to auth validation requests in time… signed applets were good but not great. But they were more powerful.

        But it was self-signed Applet which created this nightmare: do you trust the idiot that developed this control? It was exactly the same problem as the old Microsoft ActiveX problem on Internet Explorer. Nobody should allow ActiveX components to run in their browsers, either, and for all the same reasons.Report

        • Aidian in reply to BlaiseP says:
          March 19, 2013 at 7:59 pm

          Write once, infect everywhere!Report

          • BlaiseP in reply to Aidian says:
            March 19, 2013 at 8:14 pm

            Java is still a good language and the Applet could have been a viable architecture. The Applet solved a problem nobody since was able to address. My own solution allowed hundreds of simultaneous secure connections to a single server, each a true View on a proper MVC architecture, long before any of the server side solutions were doing anything even remotely similar.

            But my security guy had the good sense to confine the Applet view to the least-trusted model. The signed and self-signed Applets should have been abandoned as fundamentally insecure.

            Few people have ever seen an Applet in operation these days. Now it’s all gone to JavaScript, an interesting language, which like the Web itself, has been repurposed to ends for which it was never designed.Report

    • sidereal in reply to BlaiseP says:
      March 19, 2013 at 7:14 pm

      “Here’s the problem in a nutshell: I’ve been writing Java since the first night it was available from Sun.”

      Wait, so Java’s busted security model is your fault, Blaise?

      🙂Report

      • BlaiseP in reply to sidereal says:
        March 19, 2013 at 7:36 pm

        Sun was run by a collection of idiots who never really understood the possibilities of Java. The Internet was never designed with security in mind and Java suffered for it.

        On the desktop, Java could be designed with good security. I routinely tied my security and authentication to IBM’s RACF security models or the operating system security model, usually some flavour of Unix — and never to Microsoft security.

        I never wanted to work for Sun, or Oracle. I wonder what might have happened if I had gone down that road…. (shakes head) Sun was run by idiots and Oracle by a colossal dick. Probably better that I stayed out here.Report

  4. Jeff No-Last-Name says:
    March 19, 2013 at 6:20 pm

    For the fairly non-techy among us:

    I use Chrome and Firefox, only ocasionally running IE. What do I need to do in each of these browsers to “turn off Java” without impacting any programs I might need?Report

  5. BlaiseP says:
    March 22, 2013 at 2:21 pm

    Hey Mike: I’m outdenting here:

    So you want to avoid those ugly closures, that’s what it seems like, to me. I’m not much on closures or inner classes, though I use them both routinely.

    Java supports a perfectly acceptable Event and EventListener paradigm. In this case, let’s look at how we’d handle a change to a single member of a bean:

    First the bean itself:
    public class YooBean {
    private final PropertyChangeSupport support;
    private int i;
    …

    Then the Listener class
    public class YooBeanListener implements PropertyChangeListener {
    with a method
    public void addPropertyChangeListener(String propertyName, PropertyChangeListener l) {

    And here’s the meat:

    public void rigBeanAndListener()
    {
    YooBean ybean = new YooBean();
    YooBeanListener ylistener = new YooBeanListener();
    // listen only for changes to a single member
    ybean.addPropertyChangeListener(“i”, ylistener);
    // change the i member
    ybean.setI(2);
    }

    And the output is:
    YooBean: bean constructed, added property change support
    YooBean: addPropertyChangeListener: propertyName is i
    YooBeanListener: iold: 0 inew 2    Report

TEN SECOND BUZZ

A Message From Devcat

Devcat image

Devcat is watching over, but if you notice any problems contact the editors and Devcat will be notified and deployed immediately.

HELP ORDINARY TIMES

Recent Comments

Comics