Bill Compton

Yes I think that workaround could definitely help understand what's gone wrong if this problem happens to a user. I'll think about incorporating the idea. Thanks!

Of course, it would be even better to find a reliable solution for getting the path to a good directory for storing the user's files.

Does anyone know how Eclipse (or a similar tool) decides on the full path to the default workspace (or other user-data) directory?

Thanks for the pointer to bug 4787931. This does seem to probably be the root cause. Given that the bug has been open and griped about since 2002 I don't think I should wait for a fix.

I agree that I need to continue monitoring for recurrences on my computer, and I'm certainly doing that.

Given that this software is a desktop application meant for commercial sale and use, any identified source of instability is, in my opinion, unacceptable. My Windows XP computer isn't unusual in any particular way, so if the problem occurs for me I have to assume it will bite some our users too - not ok.

Surely other Java applications have needed a reliable way to find a directory for storing files. For example, Eclipse has a default location for the workspace dir. How does the app find the path to such directories reliably?

I appreciate the inputs. And yep, it does seem right that Windows was in a weird state those times. Rebooting definitely fixed it.

However, just fixing it on my computer isn't the real question. Finding a reliable way to get the path to a directory where the software can store and retrieve files is the question. If the user.home property returns something unreliable under Windows on my computer, it's likely that will happen to others, too, and that's not ok. I can't just blame Windows if a user who paid for our software suddenly loses all their files (or at least looks like it).

So, if user.home under Windows isn't reliable, what's a reliable way to find a "home" directory? Surely there must be a better way!

Idea: is the APPDATA environment variable reliable?

The code has been run a little on Mac and Linux (and worked fine) and has been run a LOT on two other computers, both Windows XP, with no issues either.

We're building a desktop app that needs to store some files in a reliable location. Currently we call System.getProperty( "user.home" ) and append a directory from there. It's been almost perfectly reliable for over a year, returning C:\Documents and Settings\{my user id}. However twice it has returned something else. Once, I got back C:\WINDOWS\system32\config\systemprofile and once I got C:\Documents and Settings\LocalService. Both times, after rebooting, the return from System.getProperty( "user.home" ) went back to "normal."

Is System.getProperty( "user.home" ) the wrong way to get a reliable user-related directory (i.e. "home") location? If that's wrong, what's right?

If it matters, I'm on Windows XP Home running Java 1.6.0_18-b07. The application is only for Windows for now, but will also be adapted to Linux and Mac later.

Thanks much for any advice!

I need to stand up a public web site that will include fairly standard login / logout / "register" (create account) / "remember me" functions. I can write custom servlets for it all from scratch but surely this wheel has been invented many times. Does anyone know of a package or tool I could use to jump start the project?

Thanks in advance!

Maneesh - Thanks again. The prospects of using native code and snagging screenshots (the first and second links above) seem inconsistent with the goal of commercial-grade reliability but the last one on alpha mask transparency seems promising (if I understand it so correctly so far). I will look further into what the author recommends.

However, I still need a basic recommendation on starting the design - is it best to [A] extend JFrame, [B] build on top of JWindow, or [C] something else?

The discussion on this JavaRanch forum also discusses the future of JavaFX.

Maneesh - Thanks! JavaFX looks really cool, and definitely includes some of what I'm after. However, I'm worried about a warning at the bottom of the referenced page:

Note: the com.sun.awt.AWTUtilities class is not part of an officially supported API and appears as an implementation detail. The API is only meant for limited use outside of the core platform. It may change drastically between update releases, and it may even be removed or be moved in some other packages or classes. The class should be used via Java Reflection. Supported and public API will appear in the next major JDK release.

My application needs to be extremely reliable, and this capability seems "not quite ready for prime time".

I'd like to develop a GUI for my app with custom selection and arrangement of common window controls (move, resize, iconify, maximize, close, title bar, etc.) as well as several ordinary Swing components. If you've seen the latest Windows Media Player, that's (very roughly) the kind of look / feel I'm going for. Is it better to [A] extend JFrame (changing behaviors by overriding some methods), [B] build up behaviors I want by building on top of JWindow, or [C] do something else? Extremely reliable behavior and performance are critical, in case that drives the design. Any recommendations? Thanks in advance!

Ah, quite right. I was looking at the "jre" directory (that must come with the jdk) not the actual download for the jre. Thanks!!

I am designing a software tool I intend to sell commercially. This is a general purpose tool that will be (I hope) used by the complete spectrum of computer users, including non-technical people and people with slow internet connections. Extreme simplicity of use, including installation, is paramount. Although I would love to write the tool in Java, I believe that this would require packaging a complete JRE, requiring a download of ~70 MB, which would take too long. I understand the JRE licensing agreement to preclude packaging only the portion of the JRE I actually need. It would be too risky to depend on users already having a sufficiently current JRE available. So, it seems like, at least for the primary target of Windows users, I will probably need to write the app in C++.

Does anyone know of a way to build a tool like this in Java and not incur these unacceptable delivery / installation problems? Thanks in advance for any help!

We need at least two experienced Java software engineers for a project that is very exciting. The details cannot be discussed in the open but this is a chance to play a significant role on a team that is building the next generation of software for a vital world-wide industry. When this project goes live, it will (literally) guide millions of people world-wide every day, and the contributing software engineers will be able to point and say, "I helped build that."

If you are a mid- to senior-level software engineer in the Denver, Colorado area and you meet the qualifications for the "Java/C# Software Engineer" or the "Senior J2EE Developer" here please email your resume today to jobs@infofusion.net with "JavaRanch" in the subject line.
[ September 18, 2008: Message edited by: Bill Compton ]

We have a task that may run for as little as 2 minutes or as long as 2 days. It will spawn a series of child processes that do most of the work, waiting for each child to finish before starting the next. While it is running, we need to be able to report status (either polling or monitoring a JMS topic is fine) and the user needs to be able to stop it before it finishes. We may want to run this under an app server (probably WebLogic).

What's the best approach for this? MDBs and session beans both seem like they are not the best for this. For background, here are some related topics from this forum:
This topic says there is no built-in solution, which could imply that we should just create a custom class that starts a new Thread. This topic indicates that a session bean with a transaction attribute of NotSupported would be good.

Suggestions? Thanks in advance.

-Bill

Follow up:

The time reported by -verbose:gc does not appear to be increasing like the increase in the time the application takes. Without more complicated instrumentation, it's hard to be precise, but this appears to be the case.

I switched the JProfiler session to the "Full Instrumentation" call collection strategy, and I'm still not seeing garbage collection showing up explicitly among the times charged to any methods. I don't see a garbage collection method under java.* that I can add to the list of methods to "un"filter. Is garbage collection done within the VM itself rather than by a java class?