• (cs) in reply to RevMike
    RevMike:
    Actually, a class implementing SortedSet could work fine for identical records.  A primary key could be added to each record in order to provide uniqueness, but the Comparator is free to only use that key to perform arbitrary distinction amongst equivalent records when doing the sorting.

    Clever!

    I'd probably just use a class implementing SortedMap and map the line to the number of times it occured in the file.
    dobblego:
    How much?
    I need some money - Christmas is killing me.


    OK, just for the heck of it I wrote a quick and dirty Java program to sort and unique a text file (using TreeSet and the standard java.io.* stuff).  Even using the 1.3 (server) JVM on Solaris, Java surprised me.  I catted the unformatted man pages (several times over) into a 200 meg text file, and checked it against the Unix sort command.  Java was taking around 11.8 seconds and sort was taking around 9.9 (using several timings to make sure everything was cached).    And that was only after I used an argument to let sort eat more memory.

  • (cs) in reply to boohiss
    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.



    No, it will not.  MS-DOS has mkdir.  It is the same as md.  It does not have the "-p" parm though, so the code will not work.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to JohnO
    JohnO:

    ammoQ:

    But Runtime.getRuntime().exec() is easier to find (really!) and it's also likely that it has been abused before for similar operations, like moving files, for the folks who haven't found File.renameTo().

    Maybe if you don't know alphabetical order and worked in shell scripts for 10 years before you began using Java?



    The later is actually true, and might explain the situation.
    mod +1, insightfull
  • (cs) in reply to ammoQ
    ammoQ:
    TankerJoe:
    ammoQ:
    That's the quick-and-dirty solution for people who don't like to RTFM. I admit that todays WTF could almost be mine. (Of course it isn't, I would not have a "Constants" class, but rather write
    Runtime.getRuntime().exec("mkdir -p /var/temp/foo/bar/uploads") or omit it at all, since the directory _must_ exist.

    Sidenote: mkdir -p creates all the necessary directories on the way.
    Anyway, I've just checked the docs and IMO it's pretty hard to find the right way, because of its name. (For those who wonder, it's File.mkdirs(). I've looked for something in the line of createDirecory() first. No wonder people are tempted to go the easy WTF way.


    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?


    Create a file: yes. Create a directory: no.

    Seconded (granted, I know where i'd find it)

  • (cs) in reply to Suck My Lisp
    Suck My Lisp:

    OK, just for the heck of it I wrote a quick and dirty Java program to sort and unique a text file (using TreeSet and the standard java.io.* stuff).  Even using the 1.3 (server) JVM on Solaris, Java surprised me.  I catted the unformatted man pages (several times over) into a 200 meg text file, and checked it against the Unix sort command.  Java was taking around 11.8 seconds and sort was taking around 9.9 (using several timings to make sure everything was cached).    And that was only after I used an argument to let sort eat more memory.



    You'd likely do better at 1.4.2, and better still at 1.5.  And tuning your memory parameters might cause you to do even better.  JVM technology keeps improving.  Java 1.1 was dog slow, but now...

    In general performance should not be the deciding factor on whether or not to use Java.
  • (cs) in reply to Rank Amateur
    Rank Amateur:

    But this is portable code. Just ship it with the UNIX source included. Isn't that why they wrote it in C?

    --Rank

    *grin* Maybe Linux needs to be ported to the Windows API. Now there would be a scary beast.

  • (cs)

    Bashing...
    But how many of you know what the difference is between Runtime.getRuntime().exec ("mkdir -p " + Constants.UPLOAD_PATH);
    and
    new File(Constants.UPLOAD_PATH).mkdirs() ?
    Or do you know what is mkdir in the previous statement?

  • (cs) in reply to Omnifarious
    Omnifarious:
    Rank Amateur:

    But this is portable code. Just ship it with the UNIX source included. Isn't that why they wrote it in C?

    --Rank

    *grin* Maybe Linux needs to be ported to the Windows API. Now there would be a scary beast.




    You mean something like CoLinux? Or rather CygWin?
  • Steve (unregistered)

    Java itself gets a little of the blame for this one, not for the code that is shown, but in some code that I'm sure got snipped.  The problem is that the mail API supplies a data source object which reads from a file, but if you have the contents you want to send already in memory there is no obvious data source object to use.  So the programmer figured he/she had to write the contents to a disk file and then use the file data source.  Then he/she proceeded on to genius with the mkdir exec.

    The reason I blame Java a little for this is that ByteArrayDataSource is supplied in the API, but IN THE EXAMPLES, not in the actual API!  Once you know where to look for this, you might end up skipping the files altogether and sourcing the attachment right from memory, hence no need to even think about what directory to put the file(s) in.

  • (cs) in reply to trollable
    trollable:
    Bashing...
    But how many of you know what the difference is between Runtime.getRuntime().exec ("mkdir -p " + Constants.UPLOAD_PATH);
    and
    new File(Constants.UPLOAD_PATH).mkdirs() ?
    Or do you know what is mkdir in the previous statement?


    Are you referring to the new process or the extra object creation?
  • (cs) in reply to Steve
    Anonymous:
    Java itself gets a little of the blame for this one, not for the code that is shown, but in some code that I'm sure got snipped.  The problem is that the mail API supplies a data source object which reads from a file, but if you have the contents you want to send already in memory there is no obvious data source object to use.  So the programmer figured he/she had to write the contents to a disk file and then use the file data source.  Then he/she proceeded on to genius with the mkdir exec.

    The reason I blame Java a little for this is that ByteArrayDataSource is supplied in the API, but IN THE EXAMPLES, not in the actual API!  Once you know where to look for this, you might end up skipping the files altogether and sourcing the attachment right from memory, hence no need to even think about what directory to put the file(s) in.


    What are you talking about.  Something doesn't connect here.
  • Anonymous (unregistered) in reply to Anonymous Coward

    Inability to write portable code seems quite common among unixoids. Typical WTFs include:

    In my experience the opposite is true. Windows programmers live in this fantasy that there are no other platforms, whilst UNIX programmers are more than aware that they may have to support some other dodgy platform in the future.

  • (cs) in reply to Anonymous Coward
    Anonymous:

    Inability to write portable code seems quite common among unixoids. Typical WTFs include:

     

    • Using shell commands for everything, including operations that are provided by the language (e.g., mkdir).
    • Using regular expressions for all string comparisons, even trivial stuff like "is the first character in the string a Q".

    What is this operating system which does not support regular expressions? :)

  • (cs)

    Maybe a bit off-topic, but (almost out of desperation) I created similar code (using Runtime.getRuntim().exec()) for printing Jasper reports to a given printer.
    Printing a certain printer seems unreasonably difficult in Java to me, so I ended up exporting the report to a temporary PDF file, than using exec() to execute "lp -d".
    Problem is that the app shall be ported to Windows soon...

  • (cs) in reply to Steve
    Anonymous:
    Java itself gets a little of the blame for this one, not for the code that is shown, but in some code that I'm sure got snipped.  The problem is that the mail API supplies a data source object which reads from a file, but if you have the contents you want to send already in memory there is no obvious data source object to use.  So the programmer figured he/she had to write the contents to a disk file and then use the file data source.  Then he/she proceeded on to genius with the mkdir exec.

    The reason I blame Java a little for this is that ByteArrayDataSource is supplied in the API, but IN THE EXAMPLES, not in the actual API!  Once you know where to look for this, you might end up skipping the files altogether and sourcing the attachment right from memory, hence no need to even think about what directory to put the file(s) in.


    You're argument only hold weight if we are to assume that the programmer didn't understand what a java interface is.  Implementing the DataSource interface is a trivial exercise with a grand total of four methods to implement.  This should be obvious to any competent java programmer whether it is in the examples or not.  However, if what you assert is true, and indeed the programmer figured he/she had to write the contents to a disk file and then use the file data source,  that is simply the stupidity and laziness of the programmer.

    It's like the old saying, "It's a poor craftsman who blames his tools."


  • (cs) in reply to TankerJoe

    I'm not defending the WTF as there is clearly a valid abstraction around directory creation (be it a very unixy one - mkdirs?). However, Java fails to provide a decent abstraction around file manipulation. You cannot, for example, reliably copy a file. Check it: http://kentb.blogspot.com/2005/06/i-hate-java-part-1.html

  • Randal L. Schwartz (unregistered) in reply to mlathe
    mlathe:

    This kind of stuff happens a lot in PERL too.

    but sometimes its just so easy to

    cat tmpfile| sort

    But even that's wrong. That's a "useless use of cat" (google for it). Another WTF!

  • Pedant (unregistered) in reply to RevMike

    I'm not going to defend myself. At the time it was a quick hack to get it working. Worst thing was that it was on a very large superdome.
    Doing sorts in perl or whatever was a lot faster than in java ?1.3.1?


  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    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.


    No, it will not.  MS-DOS has mkdir.  It is the same as md.  It does not have the "-p" parm though, so the code will not work.


    mkdir on Windows will create missing intermediate paths if Command Extensions are enabled (which they usually are) which is what -p does on *nix

    If you have mkdir aliased to mkdir -p on a *nix machine, mkdir is a fairly portable command

    But the constant path is unlikely to exist on both machines
  • CrappyEng (unregistered) in reply to RevMike

    The point to be made has absolutely nothing to do with whether or not Java allows you to create a directory using portable Java classes. The point is that however good or bad a language may be, a less than perfect software engineer can create a real mess.

    A difference between Java and C++ is that the basic housekeeping issues (e.g. memory management issues) are much less likely to bite the unwitting engineer. But an unwitting engineer is an unwitting engineer and they will probably make a mess of things regardless of which language they use.

  • (cs) in reply to kentcb
    kentcb:
    I'm not defending the WTF as there is clearly a valid abstraction around directory creation (be it a very unixy one - mkdirs?). However, Java fails to provide a decent abstraction around file manipulation. You cannot, for example, reliably copy a file. Check it: http://kentb.blogspot.com/2005/06/i-hate-java-part-1.html


    One can, in fact, reliably copy a file in java. From your blog...

    If you take a look at the File [^] API documentation, you'll be disappointed to (still) not find a copy method of any sort. Sure, you can check whether a file exists or whether it's a directory. Heck, you can even rename a file. But you cannot copy a file (because that would be way too useful). A quick google [^] finds other people struggling with the same issue, confirming this fact.

    Maybe it would be simpler if I just showed you how to do it?
        // Copies src file to dst file.
    // If the dst file does not exist, it is created
    void copy(File src, File dst) throws IOException {
    InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dst);

    // Transfer bytes from in to out
    byte[] buf = new byte[1024];
    int len;
    while ((len = in.read(buf)) > 0) {
    out.write(buf, 0, len);
    }
    in.close();
    out.close();
    }
    The funny part is that just because you and supposedly others struggle with this doesn't mean that it is fact.  The solution above came from the 2nd result of your own google search.
  • (cs) in reply to CrappyEng
    Anonymous:
    The point to be made has absolutely nothing to do with whether or not Java allows you to create a directory using portable Java classes. The point is that however good or bad a language may be, a less than perfect software engineer can create a real mess.

    A difference between Java and C++ is that the basic housekeeping issues (e.g. memory management issues) are much less likely to bite the unwitting engineer. But an unwitting engineer is an unwitting engineer and they will probably make a mess of things regardless of which language they use.


    Amen!

    Any good software developer will compensate for the "bad parts" of the language by 1) not using them, 2) documenting them appropriately, and 3) isolating them appropriately.  For instance, todays WTF is pretty tolerable if the developer put all these environment specific calls in a single package, apart from everything else.
  • Chris (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    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.



    No, it will not.  MS-DOS has mkdir.  It is the same as md.  It does not have the "-p" parm though, so the code will not work.

    Sincerely,

    Gene Wirchenko

    Will too work.

  • (cs) in reply to TankerJoe

    TankerJoe, I was originally going to write a snarky response like that, but then I actually skimmed his entire blog entry and it seems like he was trying to do a great deal more then simply "copy a file"; he seems to want all the functionality of "cp" in methods on "File".

    I disagree with his article (I don't hate Java, at least as of 1.5), but his criticism is a little more insightful then the imbecility your condescending reply implies.


    Incidently, his code for simply copying a file is much better then what you were able to Google.  Most importantly, your code won't close "in" or "out" if an exception is thrown (consider what will happen if "src" exists but "dst" doesn't).  Also, his implementation uses java.nio, and will potentially be more efficient.  And it's documented better.

  • (cs) in reply to Chris
    Anonymous:
    Gene Wirchenko:
    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.



    No, it will not.  MS-DOS has mkdir.  It is the same as md.  It does not have the "-p" parm though, so the code will not work.

    Will too work.



    The "-p" parameter results in an error on my system.

    Sincerely,

    Gene Wirchenko

  • Zorro (unregistered) in reply to mlathe
    mlathe:

    This kind of stuff happens a lot in PERL too.

    but sometimes its just so easy to

    cat tmpfile| sort





    I think you mean:
     % sort tmpfile 
    ?

  • Zorro (unregistered) in reply to kipthegreat
    kipthegreat:
    I mean, they had to lookup Runtime.getRuntime().exec(), File.mkdirs() doesn't seem much harder...



    Yeah, but Runtime is probably the *only* things he needs to look up, after that it's just a matter of calling unix commands or scripts! :)
  • (cs) in reply to TheDauthi
    TheDauthi:

    Since we're on the subject, I'll tell a similar, awful story on myself.  Back when I was a wee developer just leaving windows for the first time, I was writing some program or another and needed the current system's ip address.

    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

    Erm.  Yeah.  I know better now.

    Don't feel bad. I've seen worse, in production code. That we purchased.

    Only instead of munging a call to ifconfig, they munged /etc/sysconfig/network.

    Horrible, horrible stuff.

  • (cs) in reply to TankerJoe
    TankerJoe:
    kentcb:
    I'm not defending the WTF as there is clearly a valid abstraction around directory creation (be it a very unixy one - mkdirs?). However, Java fails to provide a decent abstraction around file manipulation. You cannot, for example, reliably copy a file. Check it: http://kentb.blogspot.com/2005/06/i-hate-java-part-1.html


    One can, in fact, reliably copy a file in java. From your blog...

    If you take a look at the File [^] API documentation, you'll be disappointed to (still) not find a copy method of any sort. Sure, you can check whether a file exists or whether it's a directory. Heck, you can even rename a file. But you cannot copy a file (because that would be way too useful). A quick google [^] finds other people struggling with the same issue, confirming this fact.

    Maybe it would be simpler if I just showed you how to do it?
        // Copies src file to dst file.
    // If the dst file does not exist, it is created
    void copy(File src, File dst) throws IOException {
    InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dst);

    // Transfer bytes from in to out
    byte[] buf = new byte[1024];
    int len;
    while ((len = in.read(buf)) > 0) {
    out.write(buf, 0, len);
    }
    in.close();
    out.close();
    }
    The funny part is that just because you and supposedly others struggle with this doesn't mean that it is fact.  The solution above came from the 2nd result of your own google search.


    If you actually read my blog entry you'd realise why your code above does not reliably copy a file. It copies the file contents and discards file attributes.
  • (cs) in reply to Suck My Lisp
    Suck My Lisp:
    TankerJoe, I was originally going to write a snarky response like that, but then I actually skimmed his entire blog entry and it seems like he was trying to do a great deal more then simply "copy a file"; he seems to want all the functionality of "cp" in methods on "File".

    I disagree with his article (I don't hate Java, at least as of 1.5), but his criticism is a little more insightful then the imbecility your condescending reply implies.

    Incidently, his code for simply copying a file is much better then what you were able to Google.  Most importantly, your code won't close "in" or "out" if an exception is thrown (consider what will happen if "src" exists but "dst" doesn't).  Also, his implementation uses java.nio, and will potentially be more efficient.  And it's documented better.



    Ta Lisp - just saw your reply. I'm interested in hearing what you don't agree with. Or is it just that you don't think Java sux? Don't get me wrong, that title was just to grab attention. There are parts of Java (esp 5 as you mentioned) that I love. Read my other entries (http://kentb.blogspot.com/2005/08/i-hate-java-part-2.html and http://kentb.blogspot.com/2005/08/i-hate-java-part-3.html).

    Perhaps the most disappointing thing about Java to me is the attitude of people such as TankerJoe. Instead of being interested in improving the platform they take instant offence at any constructive criticism.

  • (cs) in reply to RevMike

    RevMike:
    Why would you port something from Unix to Windows?

    Um... because that's what your employer hired you to do?

  • Suomynona (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:

    Anonymous:

    Gene Wirchenko:

    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.



    No, it will not.  MS-DOS has mkdir.  It is the same as md.  It does not have the "-p" parm though, so the code will not work.


    Will too work.


    The "-p" parameter results in an error on my system.

    Sincerely,

    Gene Wirchenko


    On my system (WinXP with Command Extensions turned on), a test of "mkdir -p upload" creates BOTH a "-p" folder and an "upload" folder.

    Gene, maybe you don't have command extensions turned on, or you're using a different version. Enter "cmd /?" to see info about it.

    So Anonymous, the command as given may work, but if so it will not work as expected. If it works, it will create the desired folder, but will also create an unwanted folder as a side-effect.

  • (cs)

    Hey, if there is a way to do a project wrong, why not do it in Java? Get your hideously mismanaged application off on the wrong foot by writing in it in a language gaurenteeed to never get it right.

  • (cs) in reply to whojoedaddy
    whojoedaddy:
    Haha, that's hilarious. Doesn't even check the os to see if it's unix first.

    I'm not sure who scares me more. The people writing the glitches or some of the people commenting on them.

  • (cs) in reply to BiggBru
    BiggBru:

    Wow. The portability of Java, minus the stupidity of the programmer, equals useless code.

    Then again, how can we expect him to know that Windows and Unix require different commands? Honest mistake, right?

    [:P]

    again, who the hell lets these people program? They are scaryier that the original bug originator!!

    That's it, from now on, there will be tests, licenses, societies, and most important, horse whippings.

  • dur (unregistered) in reply to Xepol

    Wow,  Xepol, you have absolutely nothing worthwhile to say do you?

  • (cs) in reply to Suck My Lisp

    Suck My Lisp:
    TankerJoe, I was originally going to write a snarky response like that, but then I actually skimmed his entire blog entry and it seems like he was trying to do a great deal more then simply "copy a file"; he seems to want all the functionality of "cp" in methods on "File".

    I disagree with his article (I don't hate Java, at least as of 1.5), but his criticism is a little more insightful then the imbecility your condescending reply implies.

    Incidently, his code for simply copying a file is much better then what you were able to Google.  Most importantly, your code won't close "in" or "out" if an exception is thrown (consider what will happen if "src" exists but "dst" doesn't).  Also, his implementation uses java.nio, and will potentially be more efficient.  And it's documented better.

    Agreed.  His criticism is indeed more insightful than I mistakenly implied.  As far as my example, I guess thats what I get for a quick cut and paste to make a point.   Indeed. the java.nio package is prolly a better choice for copying the contents of a file.  As far as closing the in's and out's, using try catch blocks correctly would handle (excuse the pun) that.  I think that there was a post about that a couple days ago.... [:P]

  • (cs) in reply to kentcb
    kentcb:
    TankerJoe:
    kentcb:
    I'm not defending the WTF as there is clearly a valid abstraction around directory creation (be it a very unixy one - mkdirs?). However, Java fails to provide a decent abstraction around file manipulation. You cannot, for example, reliably copy a file. Check it: http://kentb.blogspot.com/2005/06/i-hate-java-part-1.html


    One can, in fact, reliably copy a file in java. From your blog...

    If you take a look at the File [^] API documentation, you'll be disappointed to (still) not find a copy method of any sort. Sure, you can check whether a file exists or whether it's a directory. Heck, you can even rename a file. But you cannot copy a file (because that would be way too useful). A quick google [^] finds other people struggling with the same issue, confirming this fact.

    Maybe it would be simpler if I just showed you how to do it?
        // Copies src file to dst file.
    // If the dst file does not exist, it is created
    void copy(File src, File dst) throws IOException {
    InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dst);

    // Transfer bytes from in to out
    byte[] buf = new byte[1024];
    int len;
    while ((len = in.read(buf)) > 0) {
    out.write(buf, 0, len);
    }
    in.close();
    out.close();
    }

    The funny part is that just because you and supposedly others struggle with this doesn't mean that it is fact.  The solution above came from the 2nd result of your own google search.



    If you actually read my blog entry you'd realise why your code above does not reliably copy a file. It copies the file contents and discards file attributes.

    I have gone back and read the entire blog entry.  My mistake for not doing that from the begining.  Maybe in my defense, its kinda long for "Right-before-I-get-off-of-work" read.  Nevertheless, point taken.  When I read your original post, my impression was that it was a "I-Hate-Java-Too" post that seems so common on this site.  Anyways, point conceded, there is not a way to copy a file, including attributes, in Java.  Apologies.

     

     

  • (cs) in reply to TankerJoe
    TankerJoe:
    kentcb:
    TankerJoe:
    kentcb:
    I'm not defending the WTF as there is clearly a valid abstraction around directory creation (be it a very unixy one - mkdirs?). However, Java fails to provide a decent abstraction around file manipulation. You cannot, for example, reliably copy a file. Check it: http://kentb.blogspot.com/2005/06/i-hate-java-part-1.html


    One can, in fact, reliably copy a file in java. From your blog...

    If you take a look at the File [^] API documentation, you'll be disappointed to (still) not find a copy method of any sort. Sure, you can check whether a file exists or whether it's a directory. Heck, you can even rename a file. But you cannot copy a file (because that would be way too useful). A quick google [^] finds other people struggling with the same issue, confirming this fact.

    Maybe it would be simpler if I just showed you how to do it?
        // Copies src file to dst file.
    // If the dst file does not exist, it is created
    void copy(File src, File dst) throws IOException {
    InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dst);

    // Transfer bytes from in to out
    byte[] buf = new byte[1024];
    int len;
    while ((len = in.read(buf)) > 0) {
    out.write(buf, 0, len);
    }
    in.close();
    out.close();
    }

    The funny part is that just because you and supposedly others struggle with this doesn't mean that it is fact.  The solution above came from the 2nd result of your own google search.



    If you actually read my blog entry you'd realise why your code above does not reliably copy a file. It copies the file contents and discards file attributes.

    I have gone back and read the entire blog entry.  My mistake for not doing that from the begining.  Maybe in my defense, its kinda long for "Right-before-I-get-off-of-work" read.  Nevertheless, point taken.  When I read your original post, my impression was that it was a "I-Hate-Java-Too" post that seems so common on this site.  Anyways, point conceded, there is not a way to copy a file, including attributes, in Java.  Apologies.

     



    Apology accepted. It is a long entry and I guess that's kind of the point. It took me a long time just to get files copying properly in a supposedly platform-agnostic environment.

    It's interesting to note that .NET does support file copying in its APIs. For example:

    using System;
    using System.Configuration;
    using System.IO;

    namespace CopyTest
    {
        class Program
        {
            static void Main(string[] args)
            {
                File.Copy(ConfigurationSettings.AppSettings["from"], ConfigurationSettings.AppSettings["to"]);
            }
        }
    }

    If I run this code on Mono (Mandrake) then file attributes are copied along with the file. Therein lies the difference. Of course, all this is a little OT since the OP was trying to create a directory, not copy a file.

    Anyhoo cya,
    Kent
  • Anonymous Coward (unregistered)
    Alex Papadimoulis:

    Love it or hate it, one of the great things about Java is its portability. It abstracts out many of the platform-specific things so that you, the programmer, need not worry about things like file systems and how to create directories and the like. That said, Nick Smith was a bit surprised to learn that he was tasked with porting a Java application that ran on a UNIX host onto a Windows server. Not a big deal, he thought, that's what Java was built for ...

    <font color="#000099">public static</font> MultipartRequest createMultipartRequest (HttpServletRequest req) 
      <font color="#000099">throws</font> IOException
    {
       [SNIP]
    

    <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);

    [SNIP]

    }



    The real WTF is that the Java servlet specification still does not require application servers to natively support file uploads.  All of this could have been prevented...

  • (cs) in reply to RevMike

    I feel this demonstrates more some of the basic desing flaws in the java class library than anything..

    Logically, how do you create a directory. Of course! through a File object!

    compared to .NET for example:

    System.IO.Directory.CreateDirectory(path);

    that is logically named and easy to get to.

    I can easily imagine someone thinking 'how the hell do I do something so simple'. The logical step to look in java.io isn't too bad, but the next step to look in File? You'd only do this out of desperation. Then mkdirs? I realise it's similar to mkdir, but for the majority of non-unix people, this also is an extremly badly named method.

  • Willie (unregistered) in reply to Anonymous

    >> Inability to write portable code seems quite common among unixoids. Typical WTFs include:

    > In my experience the opposite is true. Windows programmers live in this fantasy that there are > no other platforms, whilst UNIX programmers are more than aware that they may have to      > support some other dodgy platform in the future

     

    Over 80% market penetration is not fantasy.

  • na (unregistered) in reply to JohnO

    java.util.Arrays providers sort methods for primitives and Objects.

    Note that java.lang.Comparable can be implemented in your classes to determine how objects should be sorted.
    Using the java.util.Collections.sort assuming you are storing the values in List object.


  • mazurek (unregistered) in reply to Willie
    Anonymous:

    Over 80% market penetration is not fantasy.



    Which market? PC market - agreed, but  think about server, embedded, mobile, realtime or supercomputing applications - still 80%?
  • mazurek (unregistered) in reply to sammybaby
    sammybaby:

    Don't feel bad. I've seen worse, in production code. That we purchased.

    Only instead of munging a call to ifconfig, they munged /etc/sysconfig/network.

    Horrible, horrible stuff.



    Nize. Someone managed to create a program not only unportable between Unixes but also between Linux distributions.

  • (cs) in reply to Suomynona
    Anonymous:

    So Anonymous, the command as given _may_ work, but if so it will not work as expected. If it works, it will create the desired folder, but will also create an unwanted folder as a side-effect.


    This is not an unwanted side effect, but the wanted effect of -p also on Unix.
  • (cs) in reply to ammoQ
    ammoQ:

    Anyway, I've just checked the docs and IMO it's pretty hard to find the right way, because of its name. (For those who wonder, it's File.mkdirs(). I've looked for something in the line of createDirecory() first. No wonder people are tempted to go the easy WTF way.

    Graham:
    I feel this demonstrates more some of the basic desing flaws in the java class library than anything.. Logically, how do you create a directory. Of course! through a File object! compared to .NET for example: System.IO.Directory.CreateDirectory(path); that is logically named and easy to get to. I can easily imagine someone thinking 'how the hell do I do something so *simple*'. The logical step to look in java.io isn't too bad, but the next step to look in File? You'd only do this out of desperation. Then mkdirs? I realise it's similar to mkdir, but for the majority of non-unix people, this also is an extremly badly named method.


    So .net got it perfectly right (IMO) and Java got it horribly wrong (IMO). Funny, since I write Java code much more often than .net code.

  • Anonymouse (unregistered) in reply to ammoQ

    Hmm, I wonder if I should post that Java code I once wrote which execs "regedit.exe" to export a key from the Windows registry into a temporary file, then reads it back in to get a value from said registry key...

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

    Inability to write portable code seems quite common among unixoids. Typical WTFs include:

     

    • Using shell commands for everything, including operations that are provided by the language (e.g., mkdir).
    • Using regular expressions for all string comparisons, even trivial stuff like "is the first character in the string a Q".


    What's non-portable about regular expressions?
  • erlando (unregistered) in reply to cconroy
    cconroy:
    <font style="font-family: verdana;" size="1">
    ammoQ:
    Anyway, I've just checked the docs and IMO it's pretty hard to find the right way, because of its name. (For those who wonder, it's File.mkdirs(). I've looked for something in the line of createDirecory() first. No wonder people are tempted to go the easy WTF way.


    <font size="2">Agreed.  Gotta love the fact that the "portable" solution involves locating a method which is named after a particular OS's command for the operation.  JavaDoc is only helpful if you already have a good idea of what you're looking for.

    </font>
    </font>


    Oh come on! How hard is it to use Google: http://www.google.com/search?hl=en&q=java+create+directory&btnG=Google+Search ?

Leave a comment on “Porting Java”

Log In or post as a guest

Replying to comment #:

« Return to Article