3 ms·

I have to say I don't think Windows' Java situation is any worse than the mess that is gcj / classpath. Install4J is free-as-in-beer BTW, but you do tend to ge

by jrabone 14y ago

I have to say I don't think Windows' Java situation is any worse than the mess that is gcj / classpath. Install4J is free-as-in-beer BTW, but you do tend to get what you pay for on Windows, especially with virtualisation software. Deleting open files is another different-not-better situation - I've seen Linux server apps resurrect entire paths due to open inodes that looked like they were deleted but weren't. That was fun to debug on a production system doing $millions a month. Have you tried Qt or similar? Perhaps a script isn't the right answer if it needs to Just Work everywhere.

rogerbinns 14y ago
We've not had any Java problems on any of the platforms. Note that the script is used by developers to verify correct integration of an SDK for Android, so they already have Java installed. This is a somewhat different scenario from random end user machines. No installation is done - you just run the script. It has an accompanying data file which is actually a zip file and one member is the jar. It is extracted to a temporary directory and run and then deleted afterwards. (Performance is not a problem since this isn't run that often.) The open deletion isn't relevant to this but is something I've dealt with elsewhere. Note that you can still have problems doing deletions even after you have closed the file due to tagalongs. In this particular scenario a command line tool that has an exit code and can be automated via make, ides etc is the right solution. I've done cross platform GUIs before as well as cross platform servers. For one company the latter was done using Qt but there was no gui so it was QThread, QString etc. For cross platform GUIs there are roughly two approaches. One is where there is some sort of wrapper that uses the native platform widgets and tries to provide the same API on each platform. This often suffers from the lowest common denominator effect across the platforms. The other end is a toolkit that draws everything itself effectively mimicking the platform and provided the same underlying code on all the platforms. I really don't like the latter approach. There will always be discontinuities between the real platform and the mimc. The mimic will always lag the platform and its developers will have to spend a lot of effort just to stand still. For the first approach I like to use wxPython/wxWidgets. One neat thing they do is provide their own widgets (composed out of as many platform widgets as possible) when the platform doesn't have the relevant one so you do get a good set to develop on. That said I do user interfaces in HTML these days where possible so there aren't as many cross platform issues (and I never support IE6 although it often works well enough).

by jrabone 14y ago

rogerbinns 14y ago

We've not had any Java problems on any of the platforms. Note that the script is used by developers to verify correct integration of an SDK for Android, so they already have Java installed. This is a somewhat different scenario from random end user machines. No installation is done - you just run the script. It has an accompanying data file which is actually a zip file and one member is the jar. It is extracted to a temporary directory and run and then deleted afterwards. (Performance is not a problem since this isn't run that often.) The open deletion isn't relevant to this but is something I've dealt with elsewhere. Note that you can still have problems doing deletions even after you have closed the file due to tagalongs. In this particular scenario a command line tool that has an exit code and can be automated via make, ides etc is the right solution. I've done cross platform GUIs before as well as cross platform servers. For one company the latter was done using Qt but there was no gui so it was QThread, QString etc. For cross platform GUIs there are roughly two approaches. One is where there is some sort of wrapper that uses the native platform widgets and tries to provide the same API on each platform. This often suffers from the lowest common denominator effect across the platforms. The other end is a toolkit that draws everything itself effectively mimicking the platform and provided the same underlying code on all the platforms. I really don't like the latter approach. There will always be discontinuities between the real platform and the mimc. The mimic will always lag the platform and its developers will have to spend a lot of effort just to stand still. For the first approach I like to use wxPython/wxWidgets. One neat thing they do is provide their own widgets (composed out of as many platform widgets as possible) when the platform doesn't have the relevant one so you do get a good set to develop on. That said I do user interfaces in HTML these days where possible so there aren't as many cross platform issues (and I never support IE6 although it often works well enough).