• Majin (unregistered) in reply to brazzy

    So many developers here, and still nobody seems to argue about the wrong execution and the pitfalls Runtime.getRuntime().exec ("somecommand") has...

    At first, to the original point - this is a minor wtf - executing native code does have its point (as already said - you cannot change file attributes 770 etc with java - you need native code OR set sticky bit in all directories where your files will be put in)

    Second, to the pitfalls - exec is not a shell - so normally "somecommand -myparam" will lead to unexpected results ! So if you really want to use it, you should wrap it around a shell i.e.

    String[] cmd = {"sh","-c","myCommand"}

    (See http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html)

  • Anonymous Coward (unregistered) in reply to brazzy
    brazzy:
    Anonymous:

    You just don't get it, do you?


    Nope, it is you who doesn't "get it".

    Anonymous:
    The argument is about the existence of SortedSet.  It's implementations have nothing to do with it.  The fact that the best way to implement the functionality promised by a SortedSet is to use a tree structure has nothing to do with it.

    If there were no SortedSet interface, would that change the functionality of TreeSet in any way?  No.  TreeSet would simply be an implementation of Set with the additional property that the elements are accessed in order, you can get slices, etc.  Much like the way LinkedList provides additional capabilities over List (addFirst, addLast, etc.).  Instead, the designers of the standard API felt that a SortedSet was a useful enough concept to have a separate interface.  There is nothing "clean" about offering an interface that you expect only implementation of.


    Not really, but when you're promoting a "collections framework" and want people to use interface types wherever possible, having functionality that is only accessible through a concrete implementation class sort of stands out, so you do interfaces everywhere, even when they're not useful.

    How do you determine that something is "a useful enough concept to have a separate interface"? Either because you want it to represent a common behaviour between different concrete classes, or because can do something useful with only that behaviour and write methods that take the interface type as parameter. Neither is the case with SortedSet (nor with SortedMap). There is only one implementation, and all uses (see http://java.sun.com/j2se/1.5.0/docs/api/java/util/class-use/SortedSet.html) are either part of itself, the implementation class or utility methods that create wrappers - with one exception: a constructor of PriorityQueue, a class introduced in 1.5. So it took 6 years and 3 major versions of the Java API until the first first use of SortedSet that doesn't exist for its own sake. And all it actually does is to get the SortedSet's comparator and leave out an intialization step because of the ordering contract. It does not use the actual functionality of the interface. There is no such semi-useful application of SortedMap at all.


    Anonymous:

    (BTW, TreeSet is not the only class provided by the JDK that implements SortedSet.  I'll leave it as an exercise for the reader to determine the other(s).  You might want to start by reading the TreeSet javadoc.)


    Bzzt. Wrong. from http://java.sun.com/j2se/1.5.0/docs/api/java/util/SortedSet.html:

    <font size="-1"> java.util</font>
    Interface SortedSet<e></e>

    All Superinterfaces:
    Collection<e>, Iterable<e>, Set<e> </e></e></e>
    All Known Implementing Classes:
    TreeSet

    In case you were talking about the subsets returned by tailSet() , etc.: take a look at the sourcecode. Those are TreeSets too. Then there are a couple of wrappers in java.util.Collections - which only exists to offer subtype-specific versions of the general Set wrappers.

    Anonymous:
    Finally, WTF do mathematicians have to do with it?  Mathmetical names like set, ring, field, group, etc. denote concepts that did not already exist.  Do you really think that re-using a common word to describe something that doesn't exist is as big a WTF as using a common word (sort) to describe a concept that already exists and for which there is a word for (order) when the original word (sort) also has a meaning (categorize) that is also a transformation one performs on a bunch of objects?


    This isn't even hairsplitting, it's no argument at all, which you admit yourself with the word "also". "to sort" is, and always was, a perfectly correct word to describe ordering something by size. Quoting http://www.m-w.com/dictionary/sort:

    Main Entry: 2sort

    Function: verb

    transitive senses
    1 a : to put in a certain place or rank according to kind, class, or nature <sort apples> <sort mail> b : to arrange according to characteristics : <font size="-1">CLASSIFY</font> <sort out colors>

    Compare that to http://www.m-w.com/dictionary/order:

    Main Entry: 1or·der [image]

    Pronunciation: 'or-d&r

    Function: verb

    Inflected Form(s): or·dered; or·der·ing [image] /'or-d(&-)ri[ng]/

    Etymology: Middle English, from ordre, n.

    transitive senses
    1 : to put in order : <font size="-1">ARRANGE</font>

    So it's not even more precise. What exactly were you complaining about again?



    Boy, you need to work on your reading comprehension.  At least you are enjoining the correct argument now re SortedSet.

    Note that I said that "TreeSet is not the only class provided by the JDK that implements SortedSet."  I did not specify a public class or even a named class.  You admit above there are others and try to claim that they do not count.

    Now, "to put in order" is much more precise than "to put in a certain place or rank according to kind, class or nature."  Try it on a bunch of non-technical people.  Get a bunch of files (by which I mean those manila things that go in file cabinets) label them with names.  Then ask some of the people to order them and the others to sort them.  See what you get.

    Note that I can sort integers into primes and non-primes and nobody would blink an eye.  If I ordered integers using anything but the natural ordering an explanation would be required.

    Now the only thing that partially saves your argument is the word "rank" in the above definition of sort.  However, you make out much worse at dictionary.com (To arrange according to class, kind, or size; classify; http://dictionary.reference.com/search?q=sort) and by the OED online (arrange systematically in group; http://www.askoxford.com/concise_oed/sort?view=uk).  Can you find an instance in literature where sort is used in this sense, outside of computer science?

  • dave (unregistered) in reply to TheDauthi

    "Difficulty: I didn't know about the gethostname, gethostbyname, etc, functions. Nor did I even know about using ioctl to grab the data. I came up with something like ifconfig |grep -A2 eth0 |grep inet|cut -d":" -f2 |cut -d" " -f1

    What makes it worse is that you've got both a UUOG (Useless Use of Grep) and a UUOC (Useless Use of Cat) in that statement; this can be replaced by: ifconfig eth0 | awk -F '[ :]*' '$2 == "inet" { print $4 }'

    First lesson in shell programming - if you have a command piped into the same command then you're usually doing it wrong.

    Also: "Runtime.getRuntime().exec("mkdir -p /var/temp/foo/bar/uploads")

    Is asking for a security vulnerability. If you need to use temporary files, always:

    1. Use a private area (if possible)
    2. Explicitly set permissions on any directories you can
    3. Randomise the name of the file (and directories if you can)
    4. Check for softlinks first

    dave

  • JL (unregistered) in reply to thomas.galvin
    thomas.galvin:
    If a company gives you access to Google, it can quite as well give you access to the whole net. Fortunately, most software companies do that, otherwise this forum would be a lonely place.
    But I have a friend who works as a in-house-programmer for a para-govermental agency which has a strict internet policy, there are only a few selected websites (like oracle.com, since they are oracle shop) available and Google is not.

    And this is why they fail.  This is a demonstration of deep stupidity on behalf of the management, and I can't understand wanting to work in an environment like that.  I also have a friend in government work, and the stories she tells me make me wonder why the state hasn't collapsed yet.

    Anyway, the majority of programmers will have access to Google.  If they don't, their management wants them to fail, and you will see things like the above WTF.

    Uh, who said they fail? Just because you're incompetent without Google, doesn't mean everyone is. Believe it or not, some people actually need to know what they're doing. The horror!

  • whojoedaddy (unregistered)

    haha

  • (cs) in reply to RevMike
    RevMike:
    JohnO:

    Anonymous:
    I've done something like this before.....

    I needed to do a sort unique on a hundred odd meg file.

    Nice...There's no sort function available in Java either.



    java.util.SortedSet no good for you?

    Sarcasm 1.1 no good for you?

  • (cs) in reply to JohnO
    JohnO:
    RevMike:
    JohnO:

    Anonymous:
    I've done something like this before.....

    I needed to do a sort unique on a hundred odd meg file.

    Nice...There's no sort function available in Java either.



    java.util.SortedSet no good for you?

    Sarcasm 1.1 no good for you?



    Damn.  I'm so used to ignorant Java bashing around here that I missed it.  My bad.
  • moobar (unregistered)
    Alex Papadimoulis:
       <font color="#006600">// Create a temp directory for the attachments</font>
       Runtime.getRuntime().exec (<font color="#990000">"mkdir -p "</font> + Constants.UPLOAD_PATH);

    File check = new File (Constants.UPLOAD_PATH);

    }


    I don't understand why the original developer, who knows enough to create a File class to check the path, didn't just use File to build the path in the first place?

    ie, 
    File path = new File( Constants.UPLOAD_PATH); 
          if (!fileexists())
            file.mkdirs();


  • kahuna (unregistered) in reply to TankerJoe
    TankerJoe:

    The problem is that interacting with the file system is such a basic and intergral part of any programming language.  If he had to RTFM to know that the java.io.File class could be used to create a directory then he should not have been using Java to code this.  Quick, think of your "favorite" language that you consider yourself skilled in.  Can't you just say off the top of your head how to create a directory or file?


    yes... and none of them require a shell call to do it.
  • (cs) in reply to Anonymous Coward

    Anonymous:
    Now the only thing that partially saves your argument is the word "rank" in the above definition of sort.  However, you make out much worse at dictionary.com (To arrange according to class, kind, or size; classify; http://dictionary.reference.com/search?q=sort) and by the OED online (arrange systematically in group; http://www.askoxford.com/concise_oed/sort?view=uk).  Can you find an instance in literature where sort is used in this sense, outside of computer science?

    Can we agree on this:

    1. The usage of "sort" as a technical term in CS is not optimal.

    2. As technical terms go, there's a lot worse. Just take a look at management literature.

    3. There's nothing wrong with CS people for using a suboptimal technical term.

    4. Blame Knuth.

     

  • Zorro (unregistered) in reply to brazzy
    brazzy:
    4. Blame Knuth.
    that's a good one.
  • (cs) in reply to Zorro

    It's kind of interesting reading everyone's responses.  I particularly enjoy the ones that are pro/con Gene's comments on mkdir's portability.

    The truth is that it is not a portable statement.  It doesn't behave the same across all versions of windows.  There's no guarantee that it will function correctly across all *nixes either.  The argument made (and it is a valid one) at the outset was that there are portability issues with code written in a language that is designed to increase portability.

    I also enjoy reading the "I love/hate Java" posts.  There will always be "purists" on any particular side of an issue.  To me Java is just another language.  I've never been a fan of the platform mainly because its performance was so bad at the time I learned it.  They may have corrected a lot of those issues since but I've never had a business need to revisit the language yet ;)  It won't stop me from programming something in it if the requirements of what I am doing warrant it.  What I will say is that I've come to hate a lot of Java programmers for the same reason I despise a certain sect of the unix community that believes that simply because it is not Microsoft it must be good and that the more arcane knowledge you have about your platform of choice the more "uber 1337" you are.  Yeah, I've followed the "holy wars" a long time.  They crop up in lots of places: Windows vs. Mac vs. *nix, Netscape vs. Internet Explorer, VHS vs. Betamax, Paper vs. Plastic....  The truth is, none of the approaches are wrong.  There's popular and unpopular, a good use of a tool, and a poor one, etc.

    It's no more appropriate to hate the tool because an idiot used it and produced a piece of crap any more than it is appropriate to idolize a tool because a purist (albeit a clever one) managed to produce something great in an inefficient manner.  Just because a great statue can be carved with a chisel doesn't mean that trying to carve Mt. Rushmore with a chisel would be a wise idea.  Use the right tool for the job - dynamite doesn't work very well on statues (well, unless you don't particularly like them) and chisels don't work well on monuments carved into the side of a mountain (unless spending time away from a nagging wife is a goal!).  IMHO don't just use Linux because you hate Windows, use it because it really is a superior tool for your purposes.  Likewise, don't frown on Linux just because it's not as popular as Windows.  It's all I'll say on the matter ;)

    The ".net got it right and Java got it wrong" posts are also somewhat amusing.  Again, the core of this issue is portability.  .Net isn't portable - even across all versions of windows.  There isn't even a runtime for Windows 95.  Most of the Windows platforms do not support the ASP.Net functionality in the runtime.

    The reason Java would have left the functionality of being able to copy a file with all attributes out seems to be pretty common-sense if you ask me.  File attributes are not portable features of the concept of a "file." True, there are similarities.  There are also differences.  How would you go about implementing a sticky bit file attribute portably across all platforms?  And I'm not just talking about the "all platforms" that people usually refer to - Linux and Windows are certainly two platforms but hardly representative of the number of systems a Java runtime has been implemented for.  Take a look at http://schmidt.devlib.org/java/jdk-jre.html for a list of some of the platforms that have a runtime.

    The correct approach has been mentioned.  Non-portable code is not evil.  There is no way Java or any other language can do away with it completely.  Granted, it may not always be written for the right reasons but many times it is.  What one's job is when approaching non-portable code is to put it all in one place - as much as is practicable - and comment the hell out of that one place so that future developers that need to port your code know what you were doing and why.  Then, their job (or possibly your own if you get to have the distinct privilege of porting your own code) will be greatly simplified.  Port the non-portable stuff all in one fell swoop, test it and deploy it.

    A true WTF would have been if Sun had attempted to implement a "copy with attributes" method in every runtime.  This would have resulted in non-portable code as part of the framework itself.  Better to leave it out intentionally so that developers are aware of the reasons, I say.

    I know it's a bit long-winded but, if anything, hopefully provokes thought.  If someone finds some value in what I'm saying, it's the best I can hope for by investing a little of my time back into the group.

    Cheers!

  • Mr Reuben Red (unregistered) in reply to JohnO
    Anonymous:
    Just because Java is extremely portable, doesn't mean the software being developed is going to be used on every platform. Sure, it's a best practice to use more abstract functions, but this WILL work as long as the 'mkdir' command exists. This is a very minor WTF.

    It will work as long as mkdir exists and takes the arguments you expect.
    Under DOS/windows, this has the irritating side effect of creating a directory called '-p' somewhere you're not expecting it.
    JohnO:

    Portability aside, you should always avoid shelling whenever possible because the error-handling is so poor.  I consider this a major WTF.  If you are going to do this, why not just call a shell script to do everything?  Do you open files with shell scripts?


    Last week I was asked to debug some perl code whose author apparently hadn't heard of 'open' and 'close' He had the rather elegant functions:

    sub readdatafromfiles {
      foreach $g (@_) {
        return `cat $g`;
      }
    }

    sub writedatatofile {
      $m = $_[0];
      $first = "true"; # first argumite is the filename
      foreach $s (@_) {
        if ($first) {
          $first = undef; #false
        }
        else {
          $result = `echo >>$m $s`;
        }
      }
    }
  • (cs) in reply to AtomicTesting
    AtomicTesting:

    Yeah, I've followed the "holy wars" a long time.  They crop up in lots of places: Windows vs. Mac vs. *nix, Netscape vs. Internet Explorer, VHS vs. Betamax, Paper vs. Plastic....  The truth is, none of the approaches are wrong.  There's popular and unpopular, a good use of a tool, and a poor one, etc.



    Absolutely correct.  The one thing I will say on the subject, however, is that any use of emacs is bad and every use of vi is good.
  • Kim (unregistered) in reply to TankerJoe

    TankerJoe:

    The problem is that interacting with the file system is such a basic and intergral part of any programming language.  If he had to RTFM to know that the java.io.File class could be used to create a directory then he should not have been using Java to code this.  Quick, think of your "favorite" language that you consider yourself skilled in.  Can't you just say off the top of your head how to create a directory or file?

    Not necessarily. At my old University they have abstracted almost all IO into separate classes. I don't know if they ever come into contact with java.io.File in their first years.

  • (cs) in reply to AtomicTesting
    AtomicTesting:

    What one's job is when approaching non-portable code is to put it all in one place - as much as is practicable - and comment the hell out of that one place so that future developers that need to port your code know what you were doing and why.  Then, their job (or possibly your own if you get to have the distinct privilege of porting your own code) will be greatly simplified.  Port the non-portable stuff all in one fell swoop, test it and deploy it.

    interesting point.  besides... how long do you really expect your code to be relevant anyway. isn't it after all... disposable? Who develops code expecting it to survive several years or beyond? While the code might survive, the business rules it was designed for would most certainly change.. if the same business indeed survived. At least that's been my experience - surviving mutilple mergers and seeing many applications munged and discarded.

  • (cs) in reply to Mr Reuben Red
    Anonymous:

    sub readdatafromfiles {
      foreach $g (@_) {
        return `cat $g`;
      }
    }


    Wouldn't that just read data from the first file?
  • (cs) in reply to olddog
    olddog:
    interesting point.  besides... how long do you really expect your code to be relevant anyway. isn't it after all... disposable? Who develops code expecting it to survive several years or beyond? While the code might survive, the business rules it was designed for would most certainly change.. if the same business indeed survived. At least that's been my experience - surviving mutilple mergers and seeing many applications munged and discarded.


    There's lots of apps (and even hardware) that have survived WAY longer than anyone ever expected... remember the whole Y2K thing?

    Of course, if you write crappy, unmaintainable code then, yes, it probably will disposed of and, if it was a business-critical application, quite possibly the entire business will not not survive.

    ALL code that is not an ad hoc throwaway script should be written with the expectation that it will survive several years and beyond. Sure, it will be changed a lot, and that's the entire point: write it in a way that accomodates change easily. Then you won't have to discard and rewrite it.
  • scriptor (unregistered) in reply to dave

    >First lesson in shell programming - if you have a command piped into the same > command then you're usually doing it wrong.

    I've never heard that one before. Instead, the better rule is "if you are doing it in a way that is hard to read or hard to maintain, then you are doing it wrong".

    In reference to the command line in question, I prefer the multple calls to 'cut' to your trucky 'awk'.

  • SuperChuck (unregistered)

    First thing I noticed was that, due to java's "portability", the format for Constants.UPLOAD_PATH would have to change...

    Four pages of comments about a programmer who didn't look in the File class to create a directory, and we all overlook a flaw in the language?

    (Well, 2 flaws if you consider using the File object to create a directory)

Leave a comment on “Porting Java”

Log In or post as a guest

Replying to comment #:

« Return to Article