Sun promises to open source Java - vnunet.com
Well, I have mixed feelings about Java going open source.
On the one hand, this would allow programmers who cared to bother, to inspect the Java source code.
At the very least, they could see how it worked. Specifically, they could see if it worked the way they thought it did - and maybe better understand how they should/could write Java programs properly.
As far as the latter reason goes, I do not think there is much need to do that. The Java documentation is excellent. The last time I had a huge bone to pick with it was around the year 2000. The technique for interacting with processes spawned from Java programs was powerful - but burdensome and unintuitive.
Better documentation would have avoided a lot of major problems in using it. Reading the C/C++ source code for the kernel of the JVM would have been a viable alternative. But hardly the one I would prefer.
Today, the documentation Sun provides at no cost to Java programmers is excellent.
Being able to fix bugs in Java, in theory, would be a fine thing. Given the complexity of the JVM, not to mention modern servers, only the most confident/competent or brave/stupid, software maintenance engineers are going to make a change in the JVM that they will rush into use in their production systems.
On the other hand, those with not just excellent but pretty good programming skills - and an average degree of self confidence could contribute some useful bug-fixes or performance enhancements to Sun to use in the baseline. Such modest changes by such helpful programmers could benefit hundreds of millions of Java users/programmers worldwide.
The sticking point is that some companies feel that whenever any of their employees help any person in any way, the company should be paid for it.
Others, will be indifferent to getting paid - figuring they are getting as much as they give out of this. They will be concerned with the risk (cost/probability) of being held accountable for a mistake if one is made, or someone merely believes one has been made.
If the programmer making the change normally works in an office, does all work on making the change at home, and does it all outside-of/in-addition-to his normal work hours for the day and week - it seems like the company is distanced from the equation in this case. But I am not a lawyer, and I have not seen all that many employment agreements - just mine, basically.
So, I guess while I am saying it might be great to have this power - people might be restrained from using it - by their own or others caution.
Now, one thing that probably will not occur to most people right off the bat - is debugging. The ability to have the source code while running a Java program, could help programmers trying to find/fix faults that live in the JVM.
They could single-step through the code, set breakpoints, get better stack traces when runtime faults occur and/or exceptions are thrown. It could be the cats pajamas for those of us who get tasked with solving problems that no one else can or will touch.
And if they have the ability to alter that source code, even just their own copy of it, that could be a godsend. They could instrument the code with whatever they want then - logging, assertions, you name it.
This seems like a rather innocuous special case of usage that I hope does get looked at by Sun and the Java community as worth taking care of nicely. In fact, I would make it a priority. I would make certain that this sort of use gets allowed sooner than other uses, and that the needs of programmers/testers doing it get primary consideration.
Later, based on what is learned, the restrictions can be further relaxed to allow distribution outside an organization, back to Sun, whatever. That redistribution thing seems to be where the thorniest problems stem from.
Once anyone looks at the software, there will be some intellectual property issues. Just as a copy of something existing in the computer opens some cans of worms, a copy of some of the information in the brain of someone also does. I am sure Sun is familiar and skillful at dealing with them, so it should not present a big problem for their lawyers to write the appropriately worded documents.
However, Sun will have to present that to the user community. No matter what they do, some will try to spin it as bad - or drive it into a bad place, claiming that is a good place. They will have to work out their plans thoroughly, before presenting the finalized rules for protecting intellectual property.
Java is probably going to continue to be popular for another decade - and conceivably much longer. Sun's formula for object-orientation, platform neutrality, and all those other good things - is as popular as the formula for a certain soft drink. It could be just as timeless too. Well, maybe not quite that timeless, but still pretty long-lived.
One of the biggest dangers of open sourcing however, is that some party grabs the goods and runs off with them. They already had one licensee make some unscrupulous changes that fall into this category. The changes were barred by the contract and/or license agreement, but they were made anyway. And the non-compliant software was then widely distributed by the broadest means possible.
Okay, I am guessing Sun does not have an interest in that happening again - and I know I do not.
The things we like about the Java stuff is that it can run on virtually all the popular platforms - almost certainly that includes whatever platform is being used to read this now. So that should be preserved.
It is wonderful to talk about standardization. But one has to realize before all that talk even begins, Sun has already delivered standardization.
Not only should they be lauded for that - but it should be recognized as fact. A rare fact, is what it is.
You have such standardization and interoperability - not to mention portability - with light bulbs. You do not have it with: word processor files, spreadsheet files, CPU instruction sets, GUIs, OS APIs, etc. Yet you do have it with Java.
A lot of companies made a lot of public statements, widely quoted when calling for Java to be open sourced back in the late 1990s. These quotes should be dragged out and repeated - to set the tenor of discussions. They themselves said Java was important. So, they themselves have to respect that the things that make it important be protected. This time.
Another reason I feel ambivalent about this is that I wrote an email to Sun arguing very strongly against following the de jure standards course when the subject of standardization came up in the 1990s.
I felt that it was a red herring by competitive forces, who would abuse the standards process. And instead of creating something with all the good qualities I mentioned earlier, they would warp that process to destroy those qualities of Java. Certainly the extrinsic ones, and probably the intrinsic ones as well.
I was told by someone at Sun that the email circulated quite widely within the organization very quickly.
I had been around the standards circle in an industry before, and I had seen how things that were supposed to
Anyway, Sun resisted the urge to throw Java on the desk of one of these standards organization and did something better. They improved the qualities it had, sharpening them to a diamond edge. Then, they formed a community process and a set of rules for it to operate under.
So now the question of open source.
I thank God, Lady Luck, and the Tooth Fairy that Sun did not rush out and follow a standardization process that promised to take away more from Java (and Java users/programmers!) than it gave.
I hope that as Sun looks down the path of going open source, that they again set forth conservatively with wisdom and not impatience setting them in motion. Personally, I like the idea of Java being open source enough for programmers to be able to debug Java programs right down to their roots, and testers able to search Java programs for the presence of bugs - or their causes - right down to the gossamer core of the Java Virtual Machine.
Java has done a lot for the computer industry for the last dozen years. Were it not for Java, many would still be arguing certain things it does were impossible. In fact, with no small amount of humor or irony, I note that there are still a few in the world who still argue what Java already does is impossible.
It is because of them, that I urge the utmost caution and careful planning in letting Java out of its secure slip, and sliding away from the safety of its dock - and then open waters beyond: the waters of Open Source.
Tom Sanders at JavaOne:
On the one hand, this would allow programmers who cared to bother, to inspect the Java source code.
At the very least, they could see how it worked. Specifically, they could see if it worked the way they thought it did - and maybe better understand how they should/could write Java programs properly.
As far as the latter reason goes, I do not think there is much need to do that. The Java documentation is excellent. The last time I had a huge bone to pick with it was around the year 2000. The technique for interacting with processes spawned from Java programs was powerful - but burdensome and unintuitive.
Better documentation would have avoided a lot of major problems in using it. Reading the C/C++ source code for the kernel of the JVM would have been a viable alternative. But hardly the one I would prefer.
Today, the documentation Sun provides at no cost to Java programmers is excellent.
Being able to fix bugs in Java, in theory, would be a fine thing. Given the complexity of the JVM, not to mention modern servers, only the most confident/competent or brave/stupid, software maintenance engineers are going to make a change in the JVM that they will rush into use in their production systems.
On the other hand, those with not just excellent but pretty good programming skills - and an average degree of self confidence could contribute some useful bug-fixes or performance enhancements to Sun to use in the baseline. Such modest changes by such helpful programmers could benefit hundreds of millions of Java users/programmers worldwide.
The sticking point is that some companies feel that whenever any of their employees help any person in any way, the company should be paid for it.
Others, will be indifferent to getting paid - figuring they are getting as much as they give out of this. They will be concerned with the risk (cost/probability) of being held accountable for a mistake if one is made, or someone merely believes one has been made.
If the programmer making the change normally works in an office, does all work on making the change at home, and does it all outside-of/in-addition-to his normal work hours for the day and week - it seems like the company is distanced from the equation in this case. But I am not a lawyer, and I have not seen all that many employment agreements - just mine, basically.
So, I guess while I am saying it might be great to have this power - people might be restrained from using it - by their own or others caution.
Now, one thing that probably will not occur to most people right off the bat - is debugging. The ability to have the source code while running a Java program, could help programmers trying to find/fix faults that live in the JVM.
They could single-step through the code, set breakpoints, get better stack traces when runtime faults occur and/or exceptions are thrown. It could be the cats pajamas for those of us who get tasked with solving problems that no one else can or will touch.
And if they have the ability to alter that source code, even just their own copy of it, that could be a godsend. They could instrument the code with whatever they want then - logging, assertions, you name it.
This seems like a rather innocuous special case of usage that I hope does get looked at by Sun and the Java community as worth taking care of nicely. In fact, I would make it a priority. I would make certain that this sort of use gets allowed sooner than other uses, and that the needs of programmers/testers doing it get primary consideration.
Later, based on what is learned, the restrictions can be further relaxed to allow distribution outside an organization, back to Sun, whatever. That redistribution thing seems to be where the thorniest problems stem from.
Once anyone looks at the software, there will be some intellectual property issues. Just as a copy of something existing in the computer opens some cans of worms, a copy of some of the information in the brain of someone also does. I am sure Sun is familiar and skillful at dealing with them, so it should not present a big problem for their lawyers to write the appropriately worded documents.
However, Sun will have to present that to the user community. No matter what they do, some will try to spin it as bad - or drive it into a bad place, claiming that is a good place. They will have to work out their plans thoroughly, before presenting the finalized rules for protecting intellectual property.
Java is probably going to continue to be popular for another decade - and conceivably much longer. Sun's formula for object-orientation, platform neutrality, and all those other good things - is as popular as the formula for a certain soft drink. It could be just as timeless too. Well, maybe not quite that timeless, but still pretty long-lived.
One of the biggest dangers of open sourcing however, is that some party grabs the goods and runs off with them. They already had one licensee make some unscrupulous changes that fall into this category. The changes were barred by the contract and/or license agreement, but they were made anyway. And the non-compliant software was then widely distributed by the broadest means possible.
Okay, I am guessing Sun does not have an interest in that happening again - and I know I do not.
The things we like about the Java stuff is that it can run on virtually all the popular platforms - almost certainly that includes whatever platform is being used to read this now. So that should be preserved.
It is wonderful to talk about standardization. But one has to realize before all that talk even begins, Sun has already delivered standardization.
Not only should they be lauded for that - but it should be recognized as fact. A rare fact, is what it is.
You have such standardization and interoperability - not to mention portability - with light bulbs. You do not have it with: word processor files, spreadsheet files, CPU instruction sets, GUIs, OS APIs, etc. Yet you do have it with Java.
A lot of companies made a lot of public statements, widely quoted when calling for Java to be open sourced back in the late 1990s. These quotes should be dragged out and repeated - to set the tenor of discussions. They themselves said Java was important. So, they themselves have to respect that the things that make it important be protected. This time.
Another reason I feel ambivalent about this is that I wrote an email to Sun arguing very strongly against following the de jure standards course when the subject of standardization came up in the 1990s.
I felt that it was a red herring by competitive forces, who would abuse the standards process. And instead of creating something with all the good qualities I mentioned earlier, they would warp that process to destroy those qualities of Java. Certainly the extrinsic ones, and probably the intrinsic ones as well.
I was told by someone at Sun that the email circulated quite widely within the organization very quickly.
I had been around the standards circle in an industry before, and I had seen how things that were supposed to
bubble upfrom the process failed to. And also how good things that were bubbling up, and really needed, were suppressed to suit a powerful sponsor. I Be Mentioning no names - they know who they are.
Anyway, Sun resisted the urge to throw Java on the desk of one of these standards organization and did something better. They improved the qualities it had, sharpening them to a diamond edge. Then, they formed a community process and a set of rules for it to operate under.
So now the question of open source.
I thank God, Lady Luck, and the Tooth Fairy that Sun did not rush out and follow a standardization process that promised to take away more from Java (and Java users/programmers!) than it gave.
I hope that as Sun looks down the path of going open source, that they again set forth conservatively with wisdom and not impatience setting them in motion. Personally, I like the idea of Java being open source enough for programmers to be able to debug Java programs right down to their roots, and testers able to search Java programs for the presence of bugs - or their causes - right down to the gossamer core of the Java Virtual Machine.
Java has done a lot for the computer industry for the last dozen years. Were it not for Java, many would still be arguing certain things it does were impossible. In fact, with no small amount of humor or irony, I note that there are still a few in the world who still argue what Java already does is impossible.
It is because of them, that I urge the utmost caution and careful planning in letting Java out of its secure slip, and sliding away from the safety of its dock - and then open waters beyond: the waters of Open Source.
Tom Sanders at JavaOne:
It's not a question of whether we'll open source Java, now the question isSchwartz told delegates in his opening keynote at the tradeshow.
how,
Technorati tags: java, opensource
posted by John Collins | 10:09 PM
0 Comments:
Post a Comment
<< Home