 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006Most Java apps are flawed on my system
I'm using a couple of free Java applications that easiliy outperform free native windows application. I'm very upset that those Java application share a common set of problems on Windows due to bugs in the Java libs and the authors are not willing to investigate and work around the problems. If I were a Java programmer I would probably send some patches to the authors or at least point to some resources but unfortunately I'm not a Java programmer. The reason why I post here is I hope to find some resources like code exmples that I can forward to the authors to work around the bugs. First issue is the Java applications save their settings in the root directory of my D partition. D:\.entagged D:\.LimeWire D:\.Phex Pretty much all Java apps got this all wrong because people get very upset if applications trash their system while they are supposed to write either xcopy style (windows power users prefer unanimously xcopy apps according to a poll I made because of the ultimate simplicity and transparency) to the startup dir where the application is located or to the user context as defined in Microsoft's design guidelines which would be 'C:\Dokumente und Einstellungen\Frank\Anwendungsdaten\' on my system and would translate to 'C:\Documents and Settings\Frank\Application data\'. Please note that the windows explorer wouldn't even allow to create a dir with preceding dot manually and no Windows user would want to use a name with esoteric characters, abreviations or casing. I've summarized the technical reasons for the problem here: http://www.gnutellaforums.com/showthread.php?s=b443bdda9ec96e6db7a54aed0858e8f9& threadid=44579 The second problem is that strings like "ain't" are saved as "ain-t" in filenames, this is unacceptable for a MP3 tagger and for any other reasonable application, on top of that there are casing problems as well. Nobody is willing to work around these bugs, it appears they stop to read my crys for help as soon as they read Windows, am very disappointed about Java, I got a couple of GTK+, QT, wxWindows and XUL apps working here on Windows starting rocket fast, looking beautifully and working amazingly well, some of 'em much better than most native apps. It's OK when a crossplatform app is a little out of the norm, I close the application and it's all good but messing with my files, folders and system is something I find very annoying. Regards, stax This problem is most likely specific to your particular configuration. The leading dot is very simply explained - it is the "hidden file" denoter on linux and other unix-like systems. The fact that D: is chosen seems to indicate that the java environment variable user.home points to D: - this is not usually the case. Take a look at your systems settings, you most probably at some point specified just that. The replacement is not specific to java either, and definitly not done by the standard libraries - however it is an accepted "good practice" not to have these characters in names, since many command interpreters will choke on them. The case problems you mentioned, similarly, probably originate from the program trying to work around deficiencies in some operating and file systems (such as FAT-based filesystems not being case sensitive at all) Long story short: You most likely have both a misconfiguration (the home directory) at hand, and treat some features as bugs. > This problem is most likely specific to your particular configuration. Of course it is as explained but my config makes sense no windows application would ever have a problem with that. It's a bug in the Java libs. > The leading dot is very simply explained - it is the "hidden file" > denoter on linux and other unix-like systems. I know this but the point is I'm not using a Unix like system, Windows has still a desktop share > 90% IIRC so it's pretty pointless for a Java app to bother Windows users with Unix conventions. > The fact that D: is > chosen seems to indicate that the java environment variable user.home > points to D: - this is not usually the case. Take a look at your > systems settings, you most probably at some point specified just that. Like I set Java determines it using the parent of the desktop dir using one of the many reg keys pointing to the desktop dir, this is dilettante as every other library uses the appropriate API call. > The replacement is not specific to java either, and definitly not done > by the standard libraries - however it is an accepted "good practice" > not to have these characters in names, since many command interpreters > will choke on them. Maybe a Linux or Mac interpreter but certainly not a Windows interpreter. The songs below are two of the best soul songs ever recorded: The Spinners - Could It Be I'm Falling In Love.mp2 James Brown - It's A Man's, Man's, Man's World.mp3 and this is what Java does with it: The Spinners - Could It Be I-m Falling In Love.mp2 James Brown - It-s A Man-s, Man-s, Man-s World.mp3 That's ridicoulous. > The case problems you mentioned, similarly, > probably originate from the program trying to work around deficiencies > in some operating and file systems (such as FAT-based filesystems not > being case sensitive at all) As a VB .NET and Windows user I find case sensitiveness as esoteric as curly braces. The programmer told me it's a Java problem. Regards, stax > Maybe a Linux or Mac interpreter but certainly not a Windows interpreter. The songs below are two of the best soul songs ever recorded: > [quoted text clipped - 7 lines] > > That's ridicoulous. That's for sure not Java changing the names, but the creators of the application simply trying to be platform independent. It might be better if they check the platform and change behavior according, but it's a lot of extra work generally just for supporting windows which has it's own less restrictive way of handling stuff. Bart > > This problem is most likely specific to your particular configuration. > > Of course it is as explained but my config makes sense no windows application would ever have a problem with that. It's a bug in the Java libs. A bug is behaviour contrary to the specification of the library. Where exactly is it behaving contrary to spec? > > The leading dot is very simply explained - it is the "hidden file" > > denoter on linux and other unix-like systems. > > I know this but the point is I'm not using a Unix like system, Windows has still a desktop share > 90% IIRC so it's pretty pointless for a Java app to bother Windows users with Unix conventions. Java is not a windows specific language. You just happen to use windows. If the programmer chooses a dot-starting name (probably because of a unix background?), this is his right and privilege... why does it bother you? > > The fact that D: is > > chosen seems to indicate that the java environment variable user.home > > points to D: - this is not usually the case. Take a look at your > > systems settings, you most probably at some point specified just that. > > Like I set Java determines it using the parent of the desktop dir using one of the many reg keys pointing to the desktop dir, this is dilettante as every other library uses the appropriate API call. I would not rule out that there could be improvements to the way the user home is determined, i don't know the process and so won't comment here. If anyone can shed light on how exactly its done, please comment. > > The replacement is not specific to java either, and definitly not done > > by the standard libraries - however it is an accepted "good practice" > > not to have these characters in names, since many command interpreters > > will choke on them. > > Maybe a Linux or Mac interpreter but certainly not a Windows interpreter. The songs below are two of the best soul songs ever recorded: Well, my bash does it under windows, as well as under linux ;) > The Spinners - Could It Be I'm Falling In Love.mp2 > James Brown - It's A Man's, Man's, Man's World.mp3 > > and this is what Java does with it: Your program does it, not java. > The Spinners - Could It Be I-m Falling In Love.mp2 > James Brown - It-s A Man-s, Man-s, Man-s World.mp3 > > That's ridicoulous. Take a good look at the configuration of your utility. Possibly you can turn of this substitution somewhere. > > The case problems you mentioned, similarly, > > probably originate from the program trying to work around deficiencies > > in some operating and file systems (such as FAT-based filesystems not > > being case sensitive at all) > > As a VB .NET and Windows user I find case sensitiveness as esoteric as curly braces. The programmer told me it's a Java problem. While i certainly won't tell you what to feel about things, it definitly is a FAT-specific limitation. IIRC there is case sensitivity in NTFS (not too sure, however). The programmer may simply have lied to you, or used some library without really knowing what it does. > A bug is behaviour contrary to the specification of the library. Where > exactly is it behaving contrary to spec? If a Java function that is supposed to return the home dir does not return the home dir then it's a bug. >>I know this but the point is I'm not using a Unix like system, Windows has still a desktop share > 90% IIRC so it's pretty pointless for a Java app to bother Windows users with Unix conventions. > > Java is not a windows specific language. You just happen to use > windows. If the programmer chooses a dot-starting name (probably > because of a unix background?), this is his right and privilege... why > does it bother you? Because I thik preceding dots and abreviations and Unix in general is esoteric and everytime I look in my root directory I'm reminded of that. >>The Spinners - Could It Be I'm Falling In Love.mp2 >>James Brown - It's A Man's, Man's, Man's World.mp3 >> >>and this is what Java does with it: > > Your program does it, not java. The programmer told me it's a Java Problem but I'll let him no that it's not. >>The Spinners - Could It Be I-m Falling In Love.mp2 >>James Brown - It-s A Man-s, Man-s, Man-s World.mp3 [quoted text clipped - 3 lines] > Take a good look at the configuration of your utility. Possibly you can > turn of this substitution somewhere. Unfortunately no stax On Wed, 08 Feb 2006 18:58:26 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >Because I thik preceding dots and abreviations and Unix in general is esoteric and everytime I look in my root directory I'm reminded of that. Everything in computers is a made up convention. If you don't know the conventions or if you know different ones, they seem like gibberish. Unix predates windows. Confusion comes from DOS and CPU ignoring Unix conventions seemingly just of the hell of it. There this no inherent reason why you should use / or \ as a file separator or : for the drive separator or even if there should be a distinction between drives and directories. It is a bit like being the inventor of the first car and trying to decide on right or left and drive.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Of course it is as explained but my config makes sense no windows > application would ever have a problem with that. It's a bug in the Java > libs. Well, how should I say it? I am not surprised that the authors of the Java applications ignore your change requests. If you (a) state you are not a Java programmer, but (b) claim there is a bug in a Java library, where (c) there isn't one (at least no one knows about such a bug, except you) it is likely that you get ignored. > I know this but the point is I'm not using a Unix like system, Windows > has still a desktop share > 90% IIRC so it's pretty pointless for a Java > app to bother Windows users with Unix conventions. People often write Java applications, because *they don't want to target Windows exclusively*. If you keep telling them they should target Windows exclusively, I am again not surprised that they ignore you ... > Like I set Java determines it using the parent of the desktop dir using > one of the many reg keys pointing to the desktop dir, this is dilettante > as every other library uses the appropriate API call. Sure, the Windows API call which on Win98 returns C:\WINDOWS as the home directory for each and every user? > As a VB .NET and Windows user I find case sensitiveness as esoteric as > curly braces. Well, the fact that your OS is very limited in that area doesn't mean other OS' should be as crippled as well. Your lack of imagination is in no way a problem of the Java library. > The programmer told me it's a Java problem. The programmer probably wanted to have you of his back and just told you what you wanted to hear. Or you just heard what you wanted to hear. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ Thomas Weidenfeller schrieb: >> Of course it is as explained but my config makes sense no windows >> application would ever have a problem with that. It's a bug in the [quoted text clipped - 5 lines] > where (c) there isn't one (at least no one knows about such a bug, > except you) it is likely that you get ignored. If a Java function that is supposed to return the home dir does not return the home dir then it's a bug, how hard is that to understand? >> Like I set Java determines it using the parent of the desktop dir >> using one of the many reg keys pointing to the desktop dir, this is >> dilettante as every other library uses the appropriate API call. > > Sure, the Windows API call which on Win98 returns C:\WINDOWS as the home > directory for each and every user? Even if that would be true it's no problem since Win98 is a dead system and imagine how fast would a Java app run on a system that old. stax stax schreef: > Thomas Weidenfeller schrieb: > > [quoted text clipped - 9 lines] > > If a Java function that is supposed to return the home dir does not return the home dir then it's a bug, how hard is that to understand? On my windows installation the function that return the user home dir (System.getProperty("user.home")) returns exact what windows define as the user home dir (%HOMEPATH%). Do if you point it somehow at D:\, the java program uses that one. On my system for instance, limewire stores it settings in c:\Documents and Settings\myname\.limewire. Ok, I agree that it should be in ...\Application Data following the windows way, but again, it would mean writing loads of platform dependent code which doesn't add anything to the functionality of the program in general. I'd rather like limewire working smoothly then trying to figure out where to store settings on each system. Bart Bart Cremers schrieb: > stax schreef: > [quoted text clipped - 17 lines] > java program uses that one. On my system for instance, limewire stores > it settings in c:\Documents and Settings\myname\.limewire. It's because your desktop dir is within your home dir, my desktop dir is on another partition because all my data is on another partition. > Ok, I agree that it should be in ...\Application Data following the > windows way, but again, it would mean writing loads of platform > dependent code which doesn't add anything to the functionality of the > program in general. I'd rather like limewire working smoothly then > trying to figure out where to store settings on each system. I rather have a few features less if that improved the quality of features that are there because all features should have the highest possible quality, I don't like half baked applications. stax > > On my windows installation the function that return the user home dir > > (System.getProperty("user.home")) returns exact what windows define as [quoted text clipped - 3 lines] > > It's because your desktop dir is within your home dir, my desktop dir is on another partition because all my data is on another partition. Well, that's what I say, both java and the java application are doing the job like it's meant to be. Storing the users settings in the users home dir. All systems, including windows, don't allow normal users to write data just anywhere on the system, that's the job of the administrator. Now, I know that on most home windows systems the normal user also has administrative rights, while on practicaly all *nix like systems, the normal user just has write access in his home directory (and maybe here and there an extra dir). Application developers can not foresee all possible setups on all possible systems, because there will always be a user with yet another setup asking for yet another way to store the user specific application settings. I'm pretty sure there are non-java applications will store application data in d:\Application Data on your system. Regards, Bart Bart >>>If a Java function that is supposed to return the home dir does not >>>return the home dir then it's a bug, how hard is that to understand? [quoted text clipped - 17 lines] > features that are there because all features should have the highest > possible quality, I don't like half baked applications. To summarize this entire thread, basically the programmers wrote a program that behaved in a certain way, and you don't like the way it's behaving. You called it a "bug", but actually the program is behaving exactly the way the programmers intended it to behave in that respect. While you might have your own definition of a "bug", under the definition that I think most people on this newsgroup use, the problem with your software isn't a "bug". I advise you stop calling it a "bug", because it may confuse other people. Also, some people don't like people who makes "false" claims of bugs. See, for example, http://www.catb.org/~esr/faqs/smart-questions.html#id264997 I don't agree with the everything written on that page, but I'm just giving you this as a warning that you might upset people by saying you've found a bug. Personally, it doesn't bother me much. Anyway, back to your problem. Here's what you can do: (1) Live with it. (2) Use a different program. (3) Learn Java and modify the program yourself (Limewire is open source). (4) Convince someone else to modify the program for you. Right now, it looks like you're going for (4), but it looks like no one on this newsgroup has any interest in modifying the program for you. Maybe if you offered to pay them, you'd get more positive responses. - Oliver > To summarize this entire thread, basically the programmers wrote a > program that behaved in a certain way, and you don't like the way it's [quoted text clipped - 3 lines] > think most people on this newsgroup use, the problem with your software > isn't a "bug". If 'getProperty("user.home")' don't return my home dir which it doesn't then it's a bug, period. http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html stax %HOMEPATH% is what on your machine? If unset, all the poor program can do is guess. It tries to do this in a way that fails in your one very special case, but works fine in multiple versions of windows. It looks to me as if you are actually complaining about the program not doing what you want it to do - programs which work just fine for a very large number of users. Do you really expect the writers to call you beforehand to inquire about your one very rare specific setup? Bottom line: Either make your home directory setting airtight (by setting it explicity), or don't complain about the results of the guesswork you force the application to do. ;) Stefan Schulz schrieb: > %HOMEPATH% is what on your machine? If unset, all the poor program can > do is guess. It tries to do this in a way that fails in your one very [quoted text clipped - 8 lines] > setting it explicity), or don't complain about the results of the > guesswork you force the application to do. ;) my home dir = C:\Dokumente und Einstellungen\Frank\ %HOMEPATH% = \Dokumente und Einstellungen\Frank\ getProperty("user.home") = D:\ // argh! I've worked out the code in C# however and if somebody would translate it to Java I could finally try to submit a patch and we could end this stupid argument. I have doubts however the path will be accepted because reading the replies of all the application authors and all of your replies I'm thinking most of you guys are pretty ignorant about Windows. private string GetSettingsDir() { if (Environment.OSVersion.Platform == PlatformID.Win32NT) return Path.Combine(Environment.ExpandEnvironmentVariables( "%APPDATA%"), Application.ProductName); else return Path.Combine(getProperty("user.home"), ".appname"); } stax I meant 'I have doubts however the *patch* will be accepted' On Thu, 09 Feb 2006 01:57:51 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >my home dir = C:\Dokumente und Einstellungen\Frank\ >%HOMEPATH% = \Dokumente und Einstellungen\Frank\ >getProperty("user.home") = D:\ // argh! If you don't like what Java is using for your home dir, you can override it, but not with HOMEPATH which is something I have never heard of. To learn how see http://mindprod.com/jgloss/properties.html#OVERRIDING You are lucky you got any help at all with that attitude. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > my home dir = C:\Dokumente und Einstellungen\Frank\ > %HOMEPATH% = \Dokumente und Einstellungen\Frank\ > getProperty("user.home") = D:\ // argh! Possible explanation: If the current drive in the app's environment is D:, and you do a system call looking for \Dokumente und Einstellungen\Frank\, then it will look for D:\Dokumente und Einstellungen\Frank\ If there is no D:\Dokumente und Einstellungen\Frank\, then it will return D:\ This is normal Windows behavior, as I recall. If this is true, then the solution might be to define your variable as: C:\Dokumente und Einstellungen\Frank\ MHS mhsampson schrieb: > If this is true, then the solution might be to define your variable as: > C:\Dokumente und Einstellungen\Frank\ I've tried to change the value 'HOMEPATH' of the reg key 'HKEY_CURRENT_USER\Volatile Environment' and also I've defined 'HOMEPATH' in the System properties. First gets reseted by the system after a new login and second does not have any affect and gets ignored. I have little hope that there is a cure other then somebody fix the bug in the Java lib or the authors work around the bug using code like I've posted. stax >> To summarize this entire thread, basically the programmers wrote a >> program that behaved in a certain way, and you don't like the way it's [quoted text clipped - 8 lines] > > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html Stax has claimed to have left the thread, so I don't know if (s)he will see this. Either way, I just wanted to point out that the above claim is over-simplifying things. From the JavaDocs to which Stax linked: <quote> public static String getProperty(String key) Gets the system property indicated by the specified key. First, if there is a security manager, its checkPropertyAccess method is called with the key as its argument. This may result in a SecurityException. If there is no current set of system properties, a set of system properties is first created and initialized in the same manner as for the getProperties method. </quote> And what it says for the getProperties method: <quote> The current set of system properties for use by the getProperty(String) method is returned as a Properties object. If there is no current set of system properties, a set of system properties is first created and initialized. </quote> In other words, ONLY if there is no current set of system properties, will a new set be created an initialized. So if there was, earlier, a manual call to setProperties(), the properties might not contain the property "user.home", or it may contain that property with any arbitrary data. So "'getProperty("user.home")' don't return my home dir" is not nescessarily proof of a bug, as the programmers may have intended to override that property with some custom value (however, I doubt this is what's happening in limewire). Stax says (s)he wasn't a Java programmer, so I assumed (s)he didn't have a debugger running to step through the code for Limewire. I don't even know if (s)he has confirmed that limewire ever actually makes a call to getProperty("user.home"), or is merely assuming that that is what it does. (S)he hasn't replied to Roedy's request to post the what he sees when he visits the WASSUP applet, and when (s)he posted a dump of his/her environment variables, I didn't see any reference to his/her home directory, so it's difficult to diagnose whether or not limewire should reasonably be able to detect Stax's intentions and do what (s)he wants. - Oliver Oliver Wong schrieb: > Stax has claimed to have left the thread, so I don't know if (s)he will > see this. Since now people are helping I'm back but won't respond to anybody any longer that tries to tell me that it's not a bug. > Either way, I just wanted to point out that the above claim is > over-simplifying things. [quoted text clipped - 32 lines] > override that property with some custom value (however, I doubt this is > what's happening in limewire). OK this might be the case but it's very unlikely and I will prove that it's not the case if necessary. > Stax says (s)he wasn't a Java programmer, so I assumed (s)he didn't have > a debugger running to step through the code for Limewire. I don't even know > if (s)he has confirmed that limewire ever actually makes a call to > getProperty("user.home") > or is merely assuming that that is what it does. No, it's not just a assumption. > (S)he hasn't replied to Roedy's request to post the what he sees when he > visits the WASSUP applet I've posted that. > and when (s)he posted a dump of his/her > environment variables, I didn't see any reference to his/her home directory, > so it's difficult to diagnose whether or not limewire should reasonably be > able to detect Stax's intentions and do what (s)he wants. I've posted the WASSUP output and 'user.home' wasn't included. I've changed my desktop dir to 'E:\Video\Test\Desktop' and now all my Java apps save their settings in 'E:\Video\Test', I've also download and installed JDK and Netbeans and made a test app using this code: System.out.print(System.getProperty("user.home")); It printed 'E:\Video\Test\' which is not my home dir but the parent of my desktop dir, I'm praying this since my very first post. stax > Oliver Wong schrieb: >> (S)he hasn't replied to Roedy's request to post the what he sees when he >> visits the WASSUP applet [quoted text clipped - 7 lines] > > I've posted the WASSUP output and 'user.home' wasn't included. Okay, I misunderstood and thought what you posted was the contents of your environment settings, not the output of WASSUP. Thanks for that clarification. > I've changed my desktop dir to 'E:\Video\Test\Desktop' and now all my Java > apps save their settings in 'E:\Video\Test', I've also download and [quoted text clipped - 5 lines] > It printed 'E:\Video\Test\' which is not my home dir but the parent of my > desktop dir, I'm praying this since my very first post. Maybe I missed it, but this is the first time I've heard you claim that System.getProperty("user.home") returns the parent of the desktop dir. In your first post, you just said files were appearing in your D:\ directory, which is a different set of information. Anyway, to me, your claim is now much more believable, as I could see that Sun might make the assumption that whatever the parent of the desktop directory "must" be the user's home directory. It sounds like you've gathered enough information to actually submit a bug report to Sun. The form for doing so is located at: http://bugs.sun.com/services/bugreport/index.jsp Just be sure to explain your problem clearly; If you phrase it like the first post of this thread, Sun will probably ignore you. Be sure to explain what the expected behaviour is, what the actual behaviour is, and how they differ. In this case, you expect for System.getProperty("user.home") to return the user's home directory, but the actual behaviour is that it returns the parent of the desktop directory. Then send in your configuration to show you why the two directories might not always be the same. - Oliver Oliver Wong schrieb: > Maybe I missed it, but this is the first time I've heard you claim that > System.getProperty("user.home") returns the parent of the desktop dir. In > your first post, you just said files were appearing in your D:\ directory, > which is a different set of information. I said: I've summarized the technical reasons for the problem here: http://www.gnutellaforums.com/showthread.php?s=b443bdda9ec96e6db7a54aed0858e8f9& threadid=44579 > It sounds like you've gathered enough information to actually submit a > bug report to Sun. The form for doing so is located at: [quoted text clipped - 3 lines] > Just be sure to explain your problem clearly; If you phrase it like the > first post of this thread, Sun will probably ignore you. > Be sure to explain what the expected behaviour is, what the actual > behaviour is, and how they differ. In this case, you expect for > System.getProperty("user.home") to return the user's home directory, but the > actual behaviour is that it returns the parent of the desktop directory. > Then send in your configuration to show you why the two directories might > not always be the same. Thanks, I'll make a bug report. stax stax schrieb: > Oliver Wong schrieb: > [quoted text clipped - 27 lines] > > stax long thread, short answer. It is a bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4480037 workaround: http://access1.sun.com/cgi-bin/rinfo2html?354930.faq He (stax) was right. paul > long thread, short answer. > It is a bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4480037 > workaround: > http://access1.sun.com/cgi-bin/rinfo2html?354930.faq > He (stax) was right. All these bug reports seem to spawn from the same original cause, but as far as I can tell, the workarounds provided won't solve Stax's problem. Essentially, he wants System.getProperty("user.home") to actually return the user's home directory by default. The problems listed in the above URLs all seem to be about hacking things (e.g. editing the registry, passing a -D command line argument, etc.) to get the System.getProperty("user.home") to return some specific path. Stax, being a .NET programmer, probably knows of some way of getting the "real" home directory path, so hopefully he can share his/her insight with Sun and they'll fix the behaviour of System.getProperty("user.home"). On the other hand, there's a chance they might not, due to backwards compatiblity issues... - Oliver As said, the user.home property points to the parent of the desktop directory on windows. The platform dependent way application programmers should resolve the real user profile directory for windows (note profile, not home) is through System.getEnv("USERPROFILE"). But using this requires application programmers to write some code to determine the platform. And therefore they use System.getProperty("user.home") instead which could be stated as returning a buggy value. I would not say it's a bug, it just a decision Sun has made to make the user.home property available on all platforms in all circumstances. Regards, Bart > As said, the user.home property points to the parent of the desktop > directory on windows. The platform dependent way application [quoted text clipped - 7 lines] > Sun has made to make the user.home property available on all platforms > in all circumstances. From the javadocs at http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#getProperties(), the "user.home" property is said to be "User's Home Directory". I don't know the Win32 platform well enough to know if this is the case, but if "User's Home Directory" has well defined semantics on the Win32 platform, and if it is not the same as what System.getProperty("user.home") returns, then I think that is a bug. On the other hand, if the platform doesn't really define a "User's Home Directory", then I'd say Sun is has some freedom to returning whatever they want. So it all depends on whether "User's Home Directory" actually means something on Win32 or not. - Oliver About the desktop issue? Yes, but not about the name replacements, and several other issues. So there is a bug reported, let's hope it gets fixed soon. :) > Oliver Wong schrieb: > [quoted text clipped - 8 lines] > > http://www.gnutellaforums.com/showthread.php?s=b443bdda9ec96e6db7a54aed0858e8f9& threadid=44579 You're right. I was lazy and didn't read the link. Sorry. =) - Oliver On Wed, 08 Feb 2006 18:43:17 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >If a Java function that is supposed to return the home dir does not return the home dir then it's a bug, how hard is that to understand? I just checked your assertion using the Wassup applet at http://mindprod.com/applets/wassup.html It displays the restricted user properties: user.home = C:\Documents and Settings\Administrator.ROEDY That is correct. There is no bug. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green schrieb: > On Wed, 08 Feb 2006 18:43:17 +0100, stax > <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly [quoted text clipped - 12 lines] > > There is no bug. How dumb is you guys? If a bug don't crop up on your machine don't mean that there is no bug. Move your desktop out of your home dir in windows and you will see that there is a bug. On Thu, 09 Feb 2006 10:13:33 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >How dumb is you guys? If a bug don't crop up on your machine don't mean that there is no bug. Move your desktop out of your home dir in windows and you will see that there is a bug. You are claming that it is a bug if the user.dir is not the way you would like. This is only true if what it does provide is totally unreasonable and your machine in not corrupt in some way. You troll-like attitude makes it hard to treat your objections objectively. If you seriously want to solve this please visit http://mindprod.com/applets/wassup.html select restricted ,and report back on what it says about your user.dir The do a set >temp.txt in a DOS box and post the results from text.txt SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. acl.write.default = deployment.browser.path = C:\PROGRA~1\MOZILL~1\FIREFOX.EXE deployment.cache.max.size = -1 deployment.console.startup.mode = HIDE deployment.javapi.trace.filename = deployment.javaws.home.jnlp.url = http://java.sun.com/products/javawebstart deployment.repository.askdownloaddialog.show = true deployment.security.askgrantdialog.notinca = true deployment.security.sandbox.awtwarningwindow = true deployment.security.sandbox.jnlp.enhanced = true deployment.system.security.trusted.jssecerts = C:\PROGRA~1\Java\JRE15~1.0_0\lib\security\trusted.jssecerts deployment.user.logdir = C:\Dokumente und Einstellungen\Frank\Anwendungsdaten\Sun\Java\Deployment\log deployment.user.security.trusted.cacerts = C:\Dokumente und Einstellungen\Frank\Anwendungsdaten\Sun\Java\Deployment\security\trusted.cacerts deployment.user.security.trusted.jssecacerts = C:\Dokumente und Einstellungen\Frank\Anwendungsdaten\Sun\Java\Deployment\security\trusted.jssecacerts deployment.user.tmp = C:\Dokumente und Einstellungen\Frank\Anwendungsdaten\Sun\Java\Deployment\tmp file.encoding.pkg = sun.io java.endorsed.dirs = C:\PROGRA~1\Java\JRE15~1.0_0\lib\endorsed java.home = C:\PROGRA~1\Java\JRE15~1.0_0 java.protocol.handler.pkgs = sun.plugin.net.protocol|sun.plugin.net.protocol|com.sun.deploy.net.protocol java.runtime.name = Java(TM) 2 Runtime Environment, Standard Edition java.vendor.applet = true java.vendor.url = http://java.sun.com/ java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi java.version = 1.5.0_06 java.version.applet = true javaplugin.proxy.config.type = direct package.restrict.access.org.mozilla.jss = true sun.io.unicode.encoding = UnicodeLittle sun.jnu.encoding = Cp1252 sun.net.client.defaultConnectTimeout = 120000 sun.os.patch.level = Service Pack 2 user.name = Frank Opera and stand alone correctly reports : user.home = C:\Documents and Settings\Administrator.ROEDY IE, Netscape, Mozilla, Firefox improperly refuse to divulge it even to a signed applet The fact one browser got it right suggests this is a browser problem not a Java problem. Netscape-Mozilla-Firefox borrow code from each other and from IE. That is how the error spread. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green schrieb: > Opera and stand alone correctly reports : user.home = C:\Documents and > Settings\Administrator.ROEDY [quoted text clipped - 5 lines] > not a Java problem. Netscape-Mozilla-Firefox borrow code from each > other and from IE. That is how the error spread. I'm getting tired of explaining each and every of you that the Java lib determines the home dir by using the parent dir of the desktop which does not work on my system as my desktop dir is not within my home dir. Since I'm the only one not being a complete moron posting to this thread I'm leaving now since with every ignorant reply I get I'm getting more angry. stax On Thu, 09 Feb 2006 14:57:30 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >I'm getting tired of explaining each and every of you that the Java lib determines the home dir by using the parent dir of the desktop which does not work on my system as my desktop dir is not within my home dir. Since I'm the only one not being a complete moron posting to this thread I'm leaving now since with every ignorant reply I get I'm getting more angry. Look you silly twit, when you come on like a teenage troll, you can't expect to be taken seriously. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Thu, 09 Feb 2006 14:57:30 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >I'm getting tired of explaining each and every of you that the Java lib determines the home dir by using the parent dir of the desktop which does not work on my system as my desktop dir is not within my home dir. Since I'm the only one not being a complete moron posting to this thread I'm leaving now since with every ignorant reply I get I'm getting more angry. no it doesn't. I have shown you that 3 browsers fail to provide it at all, so the application is doing that. Standalone and Opera work fine. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > I'm getting tired of explaining each and every of you that the Java lib > determines the home dir by using the parent dir of the desktop which > does not work on my system as my desktop dir is not within my home dir. > Since I'm the only one not being a complete moron posting to this thread > I'm leaving now since with every ignorant reply I get I'm getting more > angry. Is this guy actually for real? >> I'm getting tired of explaining each and every of you that the Java lib >> determines the home dir by using the parent dir of the desktop which does [quoted text clipped - 3 lines] >> > Is this guy actually for real? Yeah, and I'm convince (s)he's actually right about the bug now. I guess (s)he just have good communication/people's skills, which caused others to initially dismiss him/her. But the bug (s)he's reporting does seem to be a real one. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4480037 and http://access1.sun.com/cgi-bin/rinfo2html?354930.faq - Oliver >>>I'm getting tired of explaining each and every of you that the Java lib >>>determines the home dir by using the parent dir of the desktop which does [quoted text clipped - 8 lines] > initially dismiss him/her. But the bug (s)he's reporting does seem to be a > real one. I didn't really follow the thread, so I have no comment about the alleged bug, but just this sentence: "Since I'm the only one not being a complete moron posting to this thread" took my by surprise somewhat! >> Yeah, and I'm convince (s)he's actually right about the bug now. I >> guess (s)he just have good communication/people's skills, which caused >> others to Dropped a word: ^ that should read "(s)he just *doesn't* have good" etc. >> initially dismiss him/her. But the bug (s)he's reporting does seem to be >> a real one. [quoted text clipped - 5 lines] > > took my by surprise somewhat! Probably a snowball effect. People were dismissing the issue because of his/her attitude, so he got frustrated, and posted stuff like that in anger, which caused more people to dismiss the issue, etc. - Oliver > How dumb is you guys? English must not be your first language? SignatureThanks in Advance... IchBin, Pocono Lake, Pa, USA http://weconsultants.servebeer.com/JHackerAppManager __________________________________________________________________________ 'If there is one, Knowledge is the "Fountain of Youth"' -William E. Taylor, Regular Guy (1952-) IchBin schrieb: >> How dumb is you guys? > > English must not be your first language? It's not. >>How (...) is you guys? >English must not be your first language? But then, Joe Jackson sings: »Is you is or is you ain't my baby?« http://www.mondaypapers.com/jumpinjive/isyouisorisyouaint.html On Wed, 08 Feb 2006 10:35:29 +0100, stax <_r_e_m_o_v_e_stax0711-misc@yahoo.de> wrote, quoted or indirectly quoted someone who said : >The second problem is that strings like "ain't" are saved as "ain-t" in filenames, The ultimate choice of filename is the responsibility of the application programmer, not the Java language. If files are to be passed around between different OSes or if the program is to work on many platforms the programmer naturally avoids various characters that can't be handled on other OSes. The beauty of Java and the Internet is that it works for everyone, not just Bill Gates. see http://mindprod.com/jgloss/filenames.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.