As more and more tool/resource developers characterize their tools/resources in NITRC (or any of the other tool information services such as NIF, NDG, IATR, etc.), the community has the opportunity to establish some standards and conventions for best practices in this area.

As a specific example, I'd like to pose the question regarding the 'best practices' in declaration of 'Operating Systems' supported for a tool/resource when the tool/resources utilizes Java as it's programming language.

In looking at the current (small) sample of 10 NITRC tools that use Java as the programming language, there are a number of tools that select 'OS Independent' for the operating system, and another set of tools that identify some number of specific operating systems.

So the 'quandary' (that might benefit from an accepted convention) is, since Java itself is pretty OS independent, should not most Java-based tools select 'OS independent' in the operating system selection? OR, despite the OS independence of an application, should the developer ONLY declare the specific operating systems on which they themselves have actually tested or otherwise gained experience with their tool's operation?

Comments are welcomed on this thought...

As a potential user, if I was searching for a particular tool, on a particular platform, then I would personally want the results to include e.g. Java programs that should probably work, regardless of whether the developer(s) tested them on my platform yet.

I think notes about which platforms things have been tested on (and perhaps to what extent, etc.) could most usefully be included in the detailed description of the package, but needn't be in a searchable field like "Operating Systems". Also, in the spirit of open source, presumably users other than the developers could/should contribute by adding comments noting additional platforms which do or do not work.

On the other hand, developers mustn't feel under pressure to support more platforms than they have time to cope with, simply because they have listed their tool as OS Independent. Perhaps a separate "supported on" field could clarify what they are willing to commit to? Otherwise, again, I think a few words in the description could convey this message.

So, is the 'consensus' (of two opinions!) that Java programs should select 'OS Independent' in their categorization, and NITRC can host somewhere a listing (probably wiki for the time being...) of 'tested platforms' that can be contributed to by either the developers, or the community when they try various platforms and find it to work (or not)?

I'm agreeable to the two-person consensus in which Java programs should be categorized as OS Independent. My only other suggestion would be to potentially add a sub-category distinguishing Java programs from other programs that are OS Independent, since it's clear that they represent a distinct case.

right, bad idea - my last suggestion introduces redundancy with the programming language categorization!

So, there are two classes of information: 1) programming language, and
2) operating system. Programming languages other than Java can result
in operating system selection of OS independent. Does this not
already provide the flexibility of description for which you are
asking? If not, can you give an example of the type of categorization
you'd like to see?

Thanks for participating in the discussion!

I've read through the comments here in the discussion, so I'll share the experience we've had developing our program.

While Java claims to be OS independent, there are certain aspects of the LONI Pipeline that we've had to code specifically for each operating system in order to make the program function on each platform. Most programs probably won't try to access the 'system functionality' as much the Pipeline does, so ours may not be the typical scenario.

I do however think that integration into the operating system is something that should be noted/listed/commented in the program description. On OS X, there is a huge diference between running the JAR file from the Windows build vs. using a bundled .app with integration into the system menu bar and prefs. Also, in Windows an installer is the expected distribution method for applications, so noting whether that exists would helpful to the user. Finally, on Solaris/linux, some launch scripts or even .debs or .rpms would go a long way toward integration.

I don't think I have the answer to the problem, but I thought I'd just share some more data. :-)

Best,
Arash