Most Java apps are flawed on my system

[stax]

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

 

[Stefan Schulz]

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.

 

[stax]

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

 

[Bart Cremers]

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.

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

 

[Stefan Schulz]

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?

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?

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.

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.

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.

 

[Thomas Weidenfeller]

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

 

[stax]

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.

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?

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]

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.

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.

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.

Take a good look at the configuration of your utility. Possibly you can
turn of this substitution somewhere.

Unfortunately no

stax

 

[Bart Cremers]

stax schreef:

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

 

[stax]

stax schreef:




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.

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

 

[Bart Cremers]

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

 

[Oliver Wong]

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.


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.

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

 

[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
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".

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

 

[Stefan Schulz]

%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.

 

[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.

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

 

[stax]

I meant 'I have doubts however the *patch* will be accepted'

 

[Roedy Green]

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

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[Roedy Green]

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.