Most Java apps are flawed on my system

[stax]

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.

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.

 

[Roedy Green]

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

 

[stax]

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

 

[Roedy Green]

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.

 

[stax]

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.

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

 

[mhsampson]

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

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[Oliver Wong]

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

 

[stax]

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.

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

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

 

[stax]

stax wrote:

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

 

[IchBin]

How dumb is you guys?

English must not be your first language?

--

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

 

[stax]

English must not be your first language?

It's not.

 

[Stefan Ram]

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

 

[Oliver Wong]

Oliver Wong schrieb:

I've posted that.


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

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

 

[stax]

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:

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.

Thanks, I'll make a bug report.

stax

 

[Timbo]

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?

 

[paul]

I said:

I've summarized the technical reasons for the problem here:

http://www.gnutellaforums.com/showthread.php?s=b443bdda9ec96e6db7a54aed0858e8f9&threadid=44579



Thanks, I'll make a bug report.

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

 

[Oliver Wong]

I said:

I've summarized the technical reasons for the problem here:

http://www.gnutellaforums.com/showthread.php?s=b443bdda9ec96e6db7a54aed0858e8f9&threadid=44579

You're right. I was lazy and didn't read the link. Sorry. =)

- Oliver

 

[Oliver Wong]

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