Bob, Just an analogue to OpenVMS standards: User programs - nothing particular - developed on 6.0 (Alpha) will run under 8.2 (Alpha) WITHOUT change, compilation or link. Only if the images are linked against the operating system itself because they use (documented) system internals directly, they need at least to be relinked; sometimes recompilation is required, and in rare cases, code needs to be changed. Between minor releases (7.3-1 => 7.3-2 for example) NO CHANGE at all is required (unless you use undocumented fetaures or interfaces: not recommended and totally unsupported, so it's your own responsibility. This is generally accepted)
If a Java version changes (1.4 -> 1.5) the VM changes. That _may_ cause problems. I would expect it to happen if the java code links into the VM itself, and than it would be acceptable. However, most java code will not and so I would expect it to run without any extra activity. Therefore, if an application, developed in Java 1.4.1 does not run in the java 1.5 VM, AND the application does nothing "VM-internal", it SHOULD run under 1.5. Some applications do, some don't, or might not (so the original VM is supplied just because to be sure the application runs). So Tomcat runs on both 1.4 and 1.5 without change? Good. I wish there were more application that behaved that way.... It may be that the language changes - but that would always be extending the previous standard, and older code should still compile without changes. be it as a separate path within the compiler, but it should be accepted; that a waring or informational message is given is no problem. By the way: this is definietvely not specific for java - I have seen other environments where code breaks occur, even worse. As for new versions of tools: A new configuration in a new version is a pain - there can be good reasons, but it's a pain nevertheless. The job of the maintainer of a PRODUCTION environment would be eased tremendously if there was some kind of "compatibility mode", or a tool to do the basic translation. Often, a new configuration imples a new terminology; worse: the same name meaning something else. Confusion is a killer in these matters. Probably there would be extensive explanations and yes, release notes should be read in advance, and implications of the new version should clearly and completely be mentioned. But here again: only between major reeases. Tomcat 5 in completely new so I accept it. The same for application that rely on the tools: it should be clear - extensively - what the implications would be, and as much translation tools as possible should be delivered as well, or extensive documentation. Here, I do agree that writing documentation is something completely different that writing programs. There's quite a lot that comes together: knowledge of the application (or tools), knowledge of the intended audience and what they nmeed to knwo - and in what depth. It's a skill in itself, and it should NOT be left to the developer him/herself. He/She should have the ATTITUDE to write documentation as (less appreciated) part of the job. The extent depends on teh target audience: if your collegues on the job are the main users, it can be more technical, you will eb able to explain on-the-job. If your product spreads around the world, beyond your control, there is more elaborate documentation required. But again: it's the developer's attitude mostly. Where companies that supply commercial software, documentation is part of the product. Of course these companies can afford a staff of writers to do the job - and do it right. Of course, in a non-commercial or low-budget environment, you cannot. Of course the documentation suffers in both quality and quantity, opening markets for writers and editors to fill in. The amount of documentation grows large - and is so divers that it is virtually impossible to find the RIGHT documentation for YOUR problem. The same applies to the community help. I had help with my issues because they were rather basic. But I can fully subscribe - by experience in others - that one small question can be ansewered by tons of answers, far too many to handle. There may be the right, most approipate answer, but you can only tell after having read all of them. Apart from the tons of messages you are NOT interested in. Nice to use a mail client that allows you use automated rules, filtering messages into a separate location. But that is daling with symptoms, not the cause. Willem -----Oorspronkelijk bericht----- Van: Bob Bateman [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 28 oktober 2005 18:48 Aan: axis-user@ws.apache.org Onderwerp: Re: I give up On Fri, 28 Oct 2005 09:48:26 +0200 Willem Grooters <[EMAIL PROTECTED]> wrote: > Another important issue that I read in Kurt's > complaints, is the incompatibility of different Java > versions. I too have seen this. However, I have to say that the incompatibility wasn't as much with Java as it was with the tool. For example, Tomcat 4 and Tomcat 5 are different animals. Both run on Java 1.4 and 1.5. However, each has a different way of configuring the server and the application that you deploy. This IS the nature of the tool - and is NOT unique to Open-Source. I find myself, at times, using the generic term Java to mean the tools as well as the language. However, my use of Java to refer to the tools and applications I use and make is INCORRECT. Tomcat is NOT Java. Nor is Axis Java or SOAP. They are tools. In reading Kurt's comments, I fear he is using the term Java to refer to many things, not just the language or the VM. And this is unfair. Java 1.5 WILL run every application I write in Java 1.4 (sans bugs in the compiler implementation or the JVM of course...) But Tomcat 5 will NOT run a Tomcat 4 web application - nor should it. The folks that write the many applications that we rely upon go to great lengths to try to tell us what has changed when they release a version of their software. These patch notes and release readme's are an important part of every piece of software - whether it's FOSS or proprietary. > Documenation is another thing. If it exists (and alone > that is already a problem) it should be clear and > consistent. It often isn't: It's full of jargon, > too much omission of knowledge, therefore hard > to understand for newcomers, and asking the > community is not always a help: it takes too much > time to filter what's usable and what's not, and > to give things a try and find out why it doesn't > work; It's a good way of asking more specific things, > not the basic ones. But you NEED to if documenation > is simply missing. Documentation is a problem in EVERY project, whether it's FOSS or proprietary. When was the last time you looked at the books on the shelf at your local book store? How many Java books are there? And much of that content describes the same concepts and content over and over. Creating documentation for a newbie to a project is the most difficult thing to accomplish. Why? Just because I'm a newbie to AXIS and SOAP doesn't mean I'm a newbie to Java, Tomcat, Web Services, etc. So the question that each author needs to ask is: where do I start? And the answer to that question is usually the focus of the book/documentation. You may notice from this reply e-mail, that I can write fairly well (although not perfectly...) I've attempted to write documentation and to provide additional information to existing material. And I can tell you from first hand experience that writing docs is the most thankless of jobs - especially when I'm doing it for free! Why is it that there are so many books and publications in existance today? People who write well want to get compensated for their efforts - as they should. Look at any hardware or software vendor. They have *teams* of paid writers that produce their materials. We in the FOSS community are so blessed it isn't funny. We have access to the best documentation that can ever exist for a project: the source. But, having said that, I can say with 100% confidence that I can't follow 99% of the source of the Axis project. It's not that I'm stupid, or that the author of the code I'm looking at is so much smarter than I am (although I'm sure that's true!) My problem is putting into context the code I'm looking at in relation to the problem/task I'm attempting to solve. And no matter how well the code is documented, it's never enough. Another problem all products have with their documentation is you must almost be an expert with the tool before you can really write the documentation. Because who knows the tool better than the expert that created it? And writing documentation is not something most developers like to do. Bob Disclaimer: The information contained in this E-mail and its attachments is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance of the contents of this E-mail and any attachments is strictly prohibited and may be unlawful. The CIP or ISC is neither liable for the proper and complete transmission of the information contained in this E-mail and any attachments nor for any delay in its receipt. If received in error, please contact The CIP or ISC on +31(0)522 722222 quoting the name of the sender and the addressee and then delete it from your system. Please note that the The CIP or ISC does not accept any responsibility for viruses and it is your responsibility to scan the E-mail and attachments (if any). No contracts may be concluded on behalf of The CIP or ISC by means of E-mail communications.
