|
Replies:
17
-
Last Post:
Aug 26, 2006 12:30 AM
by: oleimann
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 5, 2005 6:06 AM
in response to: s690716
|
|
|
well that is why they do not want to make java open.
They are afraid anybody could fix it before they do it themself.
Its really just a shame!
I also submittes some (sometimes really critical) bugs, after one week a guys verified that its a bug and now they are there for 2-5years, only one (of about 8) has been fixed.
Congratulations and now explain me why I do not need any rights for the source - brrr...
lg Clemens
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 7, 2005 2:53 AM
in response to: linuxhippy
|
|
|
Idiot kid, you have the source and are free to implement your "fixed" (in your case most likely meaning "changed to do what I want it to do") version (of course you can't use that source directly).
You can even release it under the name Java if it passes the compatibility test.
But seeing as the OS zealots want control over the JLS in order to fork that into a gazillion different things all called Java, that probably isn't going far enough for you.
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 7, 2005 3:30 AM
in response to: jwenting
|
|
|
Please keep from name calling on this site.
D
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 8, 2005 3:50 AM
in response to: jwenting
|
|
|
1.) why should I fix something and after this give ANY rights of my code back to the company.
2.) have you ever tried to contribute something to sun. They do simply not put it into java - maybe they are afraid??
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 10, 2005 8:02 PM
in response to: linuxhippy
|
|
|
1) Why not?
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 9, 2005 1:53 AM
in response to: irisg
|
|
|
That JSR-203 is slipping yet again to Dolphin is extremely disappointing. Is it really that hard or is it just lack of priority?
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 18, 2005 9:12 AM
in response to: mthornton
|
|
|
Lack of priority I think.
Take a look at JConfig (http://www.tolstoy.com/corejava.html). It looks like a fairly decent design that solves a lot of shortcomings of the current File design...It appears to cover the vagaries of the three main platforms: Unix, Windows, Mac without simply catering to the lowest common denominator. Someone came up with this (and implemented it) years ago.
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Aug 26, 2006 12:30 AM
in response to: irisg
|
|
|
Bug 4285834 about not being able to traverse a directory
file by file (instead of one large String array for
java.io.File.list()) is not too bad.
I did a test on a directory with over 400,000 files:
C:\Stuff\Dev\4Filers\WIN32\fill_maxdirsize>java DirStat Y:\maxdirsize_test
Sat Aug 26 09:04:22 CEST 2006 start reading directory...
Sat Aug 26 09:04:51 CEST 2006 done reading directory (count=404597).
Processing 404597
Length Count
22 9
23 5
24 7
25 16
26 42
28 31
29 465
30 276
31 155
32 47732
33 29210
34 175580
35 28389
36 122680
Less than 30 seconds to get the list on a P4 2.66Ghz
System (with 1Gb of RAM).
It read a little over 2Mb/second on the Server, and the
directory inode was aver 40Mb.
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 10, 2005 5:23 AM
in response to: s690716
|
|
|
Appalling. I used to interview Java job candidates with the open-ended question "Can you give at least three reasons why java.io.File sucks?" Many good developers passed this test.
Appropriate answers included "no way to get volume size", "no way to get free space on a volume", "no access to TYPE/CREA on Mac OS", "no access to mime type on BeOS", "no access to 'nix file permissions", "concept of unique paths is wrong on Mac OS (could have multiple root-level devices with same name)", "no frickin' copy() method", "working around lack of copy() by opening input stream mangles files on non-trivial filesystems [eg, loses resource fork and TYPE/CREA on Mac OS]", "writing to a locked file is reported as cryptic FileNotFoundException", "can't renameTo() across a network share", "can't tell that a given path is a network share", "methods like renameTo(), mkdir(), and createNewFile() return an int instead of throwing an exception", etc.
java.io.File should be buried in a deep, deep hole, deprecated, and forgotten. This is another one of those half-assed API's where too many people with advanced needs just have to go native to fix its obvious flaws, which quickly leads to the "why are we doing this in Java at all" question.
--Chris (invalidname)
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 10, 2005 9:30 PM
in response to: invalidname
|
|
|
BWAHAAHAHAAHAA!!!! *snort* he he he.
All of your points are valid I'm sure. (Actually, I'm not sure, but will accept them as valid for the sake of argument)
The reason I laugh is that I remember the pain that was working with files in VB. Quick... for 200 bonus points which VB file open subroutine *doesn't* create the named file if it doesn't already exist?
I take the point from your examples that java.io is overly simplistic. This is not necessarily a bad thing:
The thing that was great about java.io in the early days was that it was really really fast (compared to other RAD languages, but slower than assembler of course). And its also really really easy to read.
At work I slapped together one of my standard read in a file and do something and then spit it back out somewhere else.
I made an offhand remark to one of our analysts who sat near me that perhaps I should spend some time commenting it. So he came over (he doesn't code anymore, so I think he was just interested in anything code related  and he was saying "no... I can read this". And another analyst came over and she was able to easily read through it as well. Neither of them have a Java background. I was floored. I often hear developers say that they dont need comments because their code is self documenting (or the even stronger claim that any code is self documenting), but invariably their code is ugly and horrible.
Particularly this surprised me because above all the two thing I strive for robustness (the author Terry Pratchett says in his books that since God created so many different types of beetles he must have "an inordinate fondness for beetles"... I would say I have "an inordinate fondness for exception handling"), and readability. I strive to make code look good, spend time considering whether there is enough white space etc. And so I like to think I know the difference between something just slapped together, and something that I've spent time polishing.
And in this case, I'd spent little or no time whatsoever polishing the code. So I can only give the credit to the java.io team, for creating an API that is easy to read and understand. This is not to say that there isn't more work that could be done to simplify it (eg having specified the name of the file, why then do we need to muck around with readers and writers and buffers and streams?).
So perhaps as well as creating a more complex api, it would also be good to have a stripped down 'common use' api, which allows similar ease of use to what you get with the better scripting languages.
eg:
SimpleFile sf = new SimpleFile("foo.txt");
sf.append("Some string");
sf.append(" or other\n");
sf.close();
or maybe
SimpleFile sf = new SimpleFile("foo.txt");
sf.erase();
sf.write("Some string");
sf.writeln(" or other");
sf.close();
and for reading
SimpleFile sfin = new SimpleFile(args[0]);
SimpleFile sfout = new SimpleFile(args[1]);
String s = "";
while (s != null) {
s = sfin.readLine();
// do something to s
sfout.write(s);
}
sfin.close();
sfout.close();
Or perhaps even that is too verbose, make SimpleParser, which
takes two arguments, the file in and the destination, and then
subclass it and override a parse method, which gets called on each
line of the input file, and returns a string to write out to the destination.
So you say that "many good developers passed this test" - but how many failed? Given a while I can come up with changes I'd like to make, but put on the spot my native instinct would be to say that java.io is a great api. In fact, I'd have to wonder how many other programming languages the interviewer has used? I can tell from your sample answers that you do know what you are talking about.
... but I'm sorry to say my first impression of anyone asking me that in an interview would be that they were an idiot.
In particular why are you looking for people that hate the language? Are your other questions things like "what 101 things suck most about java.awt?", "why is <insert (invalidname)'s favourite IDE> clearly superior to the alternatives?".
When I was interviewing for Java programmers, I'd look for someone that actually liked the language, and I'd try to get them to talk about it by asking them open ended questions. Of course I was interested if they had used 'the basics' (eg JDBC, file I/O, sockets), but I'd ask a question like:
"describe what streams are"
ie do they have a basic grasp of the concepts. But hey, maybe you wanted people who were specialists in I/O and nothing else?
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 11, 2005 7:10 AM
in response to: rickcarson
|
|
|
Re: interview technique. This was the late 90's - we were looking to tell the difference between those who'd used Java, and those who had just finished reading a book on it and were now in the job market. The idea being: if you've actually used the File class for anything non-trivial, you've run into one of these problems.
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 11, 2005 10:22 AM
in response to: invalidname
|
|
|
I tottaly agree, the fact is that we today store directories in an instance of java.io.File?!?!
This is a crazy world!
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 11, 2005 2:32 PM
in response to: mashi
|
|
|
> I tottaly agree, the fact is that we today store
> directories in an instance of java.io.File?!?!
> This is a crazy world!
Ok. A directory is a kind of file... but not a share, a volume, a symbolic link or link, a device node, special folders and so on.
Many modern PCs are connected to card readers and USB storage devices... visualized by an old fashioned floppy icon.
There is no device and/or platform independant way to determine device characteristics like free disk space, view/change attributes, accessing security descriptors.
Simple recursive file system access is not available (listFiles, delete on directories like deltree) and looping over a filesystem with listFiles even freeze a modern high end system.
|
|
|
|
|
|
|
|
|
Re: Eight years...?!
Posted:
Mar 12, 2005 12:41 PM
in response to: invalidname
|
|
|
hmm i think jaxlib (www.jaxlib.org) covers some of these drawbacks.
But you see some of your arguments are os specific, the java.io.File tries to be as generic as it gets, for the sake of portability.
Message was edited by: rizzix
|
|
|
|
|
|
|
|
|
Re: Eight years...?! - Politics @ Sun
Posted:
Mar 19, 2005 3:06 PM
in response to: rizzix
|
|
|
> hmm i think jaxlib (www.jaxlib.org) covers some of
> these drawbacks.
ok, c++ covers some of these drawbacks, too. but we speaking about a platform-independant oop language called java,
> But you see some of your arguments are os specific,
> the java.io.File tries to be as generic as it gets,
> for the sake of portability.
> Message was edited by: rizzix
Some are specific, most of them not - and still not available through java without jni. when you look at the JFileChooser with it's own Filesystem API as a workaround for missing java.io/java.nio support (called jsr 203), you know what i mean. the jfc team must implement a separate api to compensate the lack of basics in i/o.
It was planned for 1.4, then moved to 1.5, then targeted for 1.6 and now moved again to dolphin (1.7).
nio.2 should renamed to oldio.2... after six years of moving around.
this quote is also interesting and explains the missing implementation of jsr 203 and the missing support for community needs - simple (?) politics:
JSR-203, "More New I/O [(NIO)] APIs for the Java Platform (NIO.2)," is a proposed new input/output APIs. It was originally intended to appear in J2SE 5.0*, which has been publicly available since September 2004.
"Google is disappointed that JSR-203 has missed two targeted J2SE releases and that it has not moved out of the 'Expert Group Formation' phase in the two years since it started," the company stated in the comment area of its vote on JSR-270.
Officials were not available at press time for more comment on its issue.
Reinhold, who was the specification lead for the first NIO, JSR-51, said JSR-203 was originally pushed back with the intent of placing it into the next feature release, but the faster release model meant it wouldn't be developed in time for Mustang.
"At the time we dropped it from Tiger, we were still operating under the old release model which would have placed Mustang three years after Tiger, but when the new release model came along, we looked at [JSR-203] and thought, 'hmm, well, we could rush and try to do this in Mustang,' but it's sufficiently big and sufficiently important that we thought it was better to hold it off until J2SE 7, [code named] Dolphin.
"It will still come out three years after Tiger, it just won't be in Mustang," he added.
* error correction: "It was originally intended to appear in J2SE 1.4" and then the jsr was edited... 3 + 3 = 6
Source: http://www.aspnews.com/news/weekly/article.php/3487146
Conclusion:
Sometime we can read the following line:
"hmm, well, we could rush and try to do this in Dolphin," but it's sufficiently big and sufficiently important that we thought it was better to hold it off until J2SE 8...
Or 9, 10...?! who knows?
And don't ask for a platform independant TWAIN API... JNI is your friend. 
JSR 203 (NIO/2; was originally targeted for 1.4): http://www.jcp.org/en/jsr/detail?id=203
JSR 270 (Java 1.6 umbrella JSR): http://www.jcp.org/en/jsr/detail?id=270
JSR 270 (Votes and comment from Google Inc. about missing JSR 203 in Mustang): http://www.jcp.org/en/jsr/results?id=3058
|
|
|
|
|
java.net RSS
