Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Java Open Review Project

Posted by kdawson on Tue Dec 12, 2006 10:30 PM
from the many-eyeballs dept.
bvc writes "We Launched the Java Open Review Project today. We're reviewing open source Java code all the way from Tomcat down to PetStore looking for bugs and security vulnerabilities. We're using two static analysis tools to do the heavy lifting: the open source tool FindBugs, and the commercial tool Fortify SCA. We can use plenty of human eyes to help sort through the results. We're also soliciting ideas for which projects we should be reviewing next. Please help!"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
          • I'm not a big fan of Java, but to be fair:
            Unless you prefer an language in which you can be more productive
            Most of the slow development and painful complexity of Java has more to do with complex configuration of the popular application frameworks than the language itself. Our in-house Tomcat/Struts/Hibernate/XDoclet application has nearly 40 different XML configuration files. Java doesn't need any of those XML files beyond the single build file for the Ant build tool.
  • Wow (Score:5, Funny)

    by xenocide2 (231786) on Tuesday December 12 2006, @10:43PM (#17218492) Homepage
    You'd think someone asking for community participation would go to the effort of including a link to the community in question. Somehow, I think you'll get out of this request what you put into it.
  • FYI (Score:3, Informative)

    by guitaristx (791223) on Tuesday December 12 2006, @10:49PM (#17218540) Journal
    Link to the project's homepage [fortifysoftware.com]
  • Why so broad? (Score:3, Interesting)

    by kevin_conaway (585204) on Tuesday December 12 2006, @10:50PM (#17218544) Homepage

    Why so many projects?

    Why not pick one or two and really run them through the wringer? Most of the heavily used projects like Tomcat have already been viewed by thousands of eyes so a cursory overview probably won't be worth the time

    Anyways, good luck

      • Agreed. May as well just do it in one big hit instead of piece by piece. That way you will have one big mob that will target everything instead of a few dedicated people watching the programs that concern them?
  • by Anonymous Coward
    Static analysis becomes virtually unnecessary when you use a proper, statically-typed language like Haskell, Standard ML or OCaml. Furthermore, the use of garbage collection eliminates many of the buffer overruns that plague C and C++ software. Add in proper unit testing, and you're almost guaranteed to have a rock-solid system, developed very economically and often with extremely clean code.

    While Java is more difficult to exploit, it is still possible to crash an app (say, a servlet container running a maj
    • Static analysis becomes virtually unnecessary when you use a proper, statically-typed language like Haskell, Standard ML or OCaml. Furthermore, the use of garbage collection eliminates many of the buffer overruns that plague C and C++ software. Add in proper unit testing, and you're almost guaranteed to have a rock-solid system, developed very economically and often with extremely clean code.

      As nice as that is it runs into the difficulty that there are already millions of lines of code in Java and rewriting

      • Seems like JML & friends still don't support Java 1.5 yet, and now 1.6 is out. I've seen you mention this quite some time ago, but I write all my code in 1.5. Do you know if they are they working on 1.5?
        • Support for a.5 is in the works apparently, though it is the next major version of ESC/Java that will have it, so I don't know how soon that will come out. It is, at the least, in the works.
      • Really, crash an app because somebody is using an array rather than an ArrayList? So you're telling me that the programmer not knowing the difference between something with a static (ungrowable) size and a dynamic (growable) size is a fault of the language?

        That is the argument you hear all the time. E.g, most buffer overflows in C is due to people using fixed arrays for variable length strings... which makes little sense.

        Today, it seems that "archiving goals by lowering expectations" is the norm among

        • Today, it seems that "archiving [sic] goals by lowering expectations" is the norm among application developers... dumping down languages to avoid features that might burn developers.

          When you say "today", what are you comparing it to? When was the glorious time that software projects were simple enough, and well enough defined at the outset, that all targets were all met consistently and successfully?

          Have you been watching Lou Dobbs too much of late? The nature of the world is not significantly diffe

          • Have you been watching Lou Dobbs too much of late?

            Ha ha, that guy is so annoying :) Damn kids today!

          • I wasn't referring to projects, but to languages. You seem to have misunderstood me there. I disagree that Java is a *great* tool for many jobs, although it might be an adequate in many. The greatest advantage of Java is the bandwagon effect... as long as you choose Java, you can dodge responsibility for choosing the wrong language for the job, and also, it is easy to find mediocre programmers that can do some Java.

            And sorry about misspelling "achievements". I will try to be more careful, even if it is a s

    • While Java is more difficult to exploit, it is still possible to crash an app (say, a servlet container running a major web site) by sending data in such a way that an array's capacity is exceeded.

      You can't crash a Java App Server with just an ArrayIndexOutOfBoundsException. It will produce an error for that user, sure, but it won't propogate any farther than that. Read the specs sometime. The servlet container is responsible for trapping all exceptions thrown by the servlet, then dealing with them in an appropriate manner. Usually that means giving the user an HTTP 500 error.
      • Usually that means giving the user an HTTP 500 error

        Which, in webapp speak, is a crash... Yes it won't kill the server since the exception has been handled before that but if your index page dies with an HTTP 500 error it's exactly the same thing for the user : "Website doesn't work".
        • Which, in webapp speak, is a crash..

          No, it's an error. A crash would be if the server went down.

          it's exactly the same thing for the user : "Website doesn't work".

          Considering that the GPs point was that the user was trying to break it, I don't see what your complaint is. The server shrugs off the error and keeps chugging along.
        • And the obvious superiority you've conveyed with your tone is reflected quite nicely in the fact that so few people actually know of (never mind know) any of those languages.

          I guess it's tough being extra-right all the time and still being ignored. Sorry.
        • I really hate responding to shadows, but here goes:

          The only reason such tools are deemed necessary for Java, C and C++ apps is because those languages just aren't as suited for static analysis as most functional languages.

          There's a list of warnings [sourceforge.net] that FindBugs outputs. If you want to claim that static analysis is unnecessary for Haskell or OCaml, then go over the list and say why. It's not enough to just claim by fiat that your favorite language doesn't have that problem and then tell "Blub" to

            • You obviously know nothing about OCaml, Haskell, or Standard ML.

              I've looked into Haskell before. Just scratched the surface, really, but definitely more than "know nothing".

              If you did, you'd see immediately how they either take care of all those problems at compile time, or it's completely impossible for them to even be affected.

              Bold statements like this are bullshit. Any language can benefit from static analysis. How can you seriously claim otherwise? Obviously a language like C would benef

      • The JVM isn't written in Java.

        Which one? There is not just one JVM. There are JVMs that ARE written in Java, such as this http://joeq.sourceforge.net/ [sourceforge.net]

        However, there is a good reason why most JVMs aren't written in Java - the highest performance Java implementations use run-time optimisations from within a JVM. So you would need a JVM to run the Java which would implement the JVM - which is recursive. You need to bootstrap things somehow.
    • If a langauge will not let you commit security vilolations through design, then I can say with surity that language is not usable.

      Note I am NOT saying Haskell is unusable. What I am saying is that in all the languages you list, it is still possible to create code that by design will be insecure. Any time you take input from a user, and place that input into a database for example, you have an avenue for attack.

      As for the suggestion to use an ArrayList instead of basic arrays in Java, it makes me sudder to
      • As for the suggestion to use an ArrayList instead of basic arrays in Java, it makes me sudder to think of you designing any web systems that may be touched by a high volume of traffic

        Then it makes me shudder to think of the design atrocities you're going to commit if by default you use arrays. Use arrays (maybe) if and only if you have established that they are required to solve a proven performance problem. Using them on the offchance that they'll be needed is the height of premature optimisation folly.
    • Re: (Score:1, Flamebait)

      I'm sorry, I thought you wanted them to learn a real langugae [wikipedia.org].
      • Like +C+?

        Thanks for demonstrating that even open-minded coders like yourself still need a good QA team, even if it's just to fix the little language typos...

      • Real language like what C/C++ Grow up man, try to write an ENTERPRISE SYSTEM without a thick client server model using C/C++. Let me know once done.
        • DOne. Several times over. I wouldn't write anything more complex than Hello World in Java, it just doesn't have the performance.
          • An enterprise software with a thin client in c/c++!!!!!!!!!!!! Hats off to you. I love programming and started as c guy but I have no more patience for the reinvention of wheel several times. I like to solve business problems using code
    • I thought your "real language" is a rip-off of Java. Sounds like you should learn the *original* real [ibm.com] language....
  • Whoever the heck is kdawson, he certainly does not sound like he is from the many-eyeballs dept.