- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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)
Admin
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?
Admin
"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:
dave
Admin
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!
Admin
haha
Admin
Sarcasm 1.1 no good for you?
Admin
Damn. I'm so used to ignorant Java bashing around here that I missed it. My bad.
Admin
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();
Admin
yes... and none of them require a shell call to do it.
Admin
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.
Admin
Admin
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!
Admin
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.
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`;
}
}
}
Admin
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.
Admin
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.
Admin
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.
Admin
Wouldn't that just read data from the first file?
Admin
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.
Admin
>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'.
Admin
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)