meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
ancient_history [2020/09/03 12:59] – external edit 127.0.0.1ancient_history [2020/10/30 15:57] (current) – [Another name change. JavaCC (21)] revusky
Line 5: Line 5:
 Now, actually, the history of JavaCC is not so easy to piece together. In its early days (the only time it was actively developed) it was bounced around to a few different companies. The version history [[https://javacc.github.io/javacc/release-notes.html|here]] provides a history of releases and version numbers but does not provide any dates! There is a change log but no mention of who was responsible for any of the changes. (To be clear, the last two sentences refer to development prior to mid-2003, when Sun open-sourced JavaCC on java.net.) Now, actually, the history of JavaCC is not so easy to piece together. In its early days (the only time it was actively developed) it was bounced around to a few different companies. The version history [[https://javacc.github.io/javacc/release-notes.html|here]] provides a history of releases and version numbers but does not provide any dates! There is a change log but no mention of who was responsible for any of the changes. (To be clear, the last two sentences refer to development prior to mid-2003, when Sun open-sourced JavaCC on java.net.)
  
-Since an earlier draft of this page, I had a bit of correspondence with Sriram Sankar, who was the project lead on "Jack", the parser generator developed internally at Sun Microsystems, that would later be renamed to JavaCC. I had been trying to figure out when JJTree, the tree-building functionality, was added to the package. I had previously believed that JJTree must have been added in 1999 or so. I also had a strong suspicion that JJTree was not written by the same person or team that implemented the core JavaCC functionality. Dr. Sankar told me that JJTree was added to the package quite early, early 1997. He also confirmed my other suspicion: JJTree was mainly written by one Rob Duncan, a name I don't ever recalling hearing in connection with JavaCC development. In any case, seeing as JJTree is pretty clearly the last feature of any significance ever added to the package, that means that the time window in which JavaCC was really an actively developed project (by any reasonable definition) is quite short!+Since an earlier draft of this page, I had a bit of correspondence with Sriram Sankar, who was the project lead on "Jack", the parser generator developed internally at Sun Microsystems, that would later be renamed to JavaCC. I had been trying to figure out when JJTree, the tree-building functionality, was added to the package. I had previously believed that JJTree must have been added in 1999 or so. I also had a strong suspicion that JJTree was not written by the same person or team that implemented the core JavaCC functionality. Dr. Sankar told me that JJTree was added to the package quite early, early 1997. He also confirmed my other suspicion: JJTree was mainly written by one Rob Duncan, a name I don't ever recall hearing in connection with JavaCC development. In any case, seeing as JJTree is pretty clearly the last feature of any significance ever added to the package, that means that the time window in which JavaCC was really an actively developed project (by any reasonable definition) is quite short!
  
 ===== Let's start at the beginning ===== ===== Let's start at the beginning =====
Line 19: Line 19:
 Now, Metamata, Jack's (now JavaCC's) new home, was acquired by some other company called [[https://en.wikipedia.org/wiki/WebGain|Webgain]], that went belly up after the 2001 dot-com bust. However, in the ensuing liquidation of assets (and I am hardly sure of the exact details) JavaCC ended up back at its birthplace, Sun Microsystems. As best I can deduce, after that point, JavaCC was not actively developed at Sun in any significant way. In fact, well before that, development of the tool had crawled to a near standstill. The [[http://freshmeat.sourceforge.net/projects/javacc|archived Freshmeat site from that period]] lists two JavaCC releases, 2.0 dated 4 November 2000 and then a year and a half later, on 16 April 2002, a 2.1. The modifications in the [[https://javacc.github.io/javacc/release-notes.html#javacc-2.1|official version history]] list some changes but they are pretty thin if this is supposed to be a year and a half of development effort. Now, Metamata, Jack's (now JavaCC's) new home, was acquired by some other company called [[https://en.wikipedia.org/wiki/WebGain|Webgain]], that went belly up after the 2001 dot-com bust. However, in the ensuing liquidation of assets (and I am hardly sure of the exact details) JavaCC ended up back at its birthplace, Sun Microsystems. As best I can deduce, after that point, JavaCC was not actively developed at Sun in any significant way. In fact, well before that, development of the tool had crawled to a near standstill. The [[http://freshmeat.sourceforge.net/projects/javacc|archived Freshmeat site from that period]] lists two JavaCC releases, 2.0 dated 4 November 2000 and then a year and a half later, on 16 April 2002, a 2.1. The modifications in the [[https://javacc.github.io/javacc/release-notes.html#javacc-2.1|official version history]] list some changes but they are pretty thin if this is supposed to be a year and a half of development effort.
  
-t is fairly easy to deduce that Sun did not ever allocate any real development resources to JavaCC in this period. By the time Sun released the code as open source in 2003, it was really an orphan project that had not been actively developed for some time. Whoever made such decisions decided that they might as well release JavaCC as open source. In retrospect, this is probably a very typical pattern for [[https://doku.javacc.com/doku.php?id=nothingburger|nothingburger]] projects.+It is fairly easy to deduce that Sun did not ever allocate any real development resources to JavaCC in this period. By the time Sun released the code as open source in 2003, it was really an orphan project that had not been actively developed for some time. Whoever made such decisions decided that they might as well release JavaCC as open source. In retrospect, this is probably a very typical pattern for [[https://doku.javacc.com/doku.php?id=nothingburger|nothingburger]] projects.
  
 ===== Late 2001. My Own Involvement with JavaCC ===== ===== Late 2001. My Own Involvement with JavaCC =====
Line 105: Line 105:
 Now, first of all, to be clear about one aspect of all of this, FreeCC (now //JavaCC 21//) was never a "fork" in any real sense. A fork, i.e. a //bifurcation//, contains the implict idea that there are two (or possibly more) lines of //active development//. That is simply not the case here. As far as I know (and I would surely know it by now if this were not the case) the body of work that I did from Spring of 2008 to very early 2009, and am now resuming, is the //only// work of //any significance// that has been done on the JavaCC codebase that Sun open sourced back in 2003. Soon, that will have been 17 years ago and I do not believe that the amount of work done by the ostensible project maintainers amounts to what a single motivated person could do in a single month. There are some other people who got frustrated with the obstructionism of the canonical project maintainers and created their own "forks" of the codebase. However, I do not believe that any of them constitute a body of work remotely comparable to what was done on FreeCC. Now, first of all, to be clear about one aspect of all of this, FreeCC (now //JavaCC 21//) was never a "fork" in any real sense. A fork, i.e. a //bifurcation//, contains the implict idea that there are two (or possibly more) lines of //active development//. That is simply not the case here. As far as I know (and I would surely know it by now if this were not the case) the body of work that I did from Spring of 2008 to very early 2009, and am now resuming, is the //only// work of //any significance// that has been done on the JavaCC codebase that Sun open sourced back in 2003. Soon, that will have been 17 years ago and I do not believe that the amount of work done by the ostensible project maintainers amounts to what a single motivated person could do in a single month. There are some other people who got frustrated with the obstructionism of the canonical project maintainers and created their own "forks" of the codebase. However, I do not believe that any of them constitute a body of work remotely comparable to what was done on FreeCC.
  
-As I have stated quite bluntly above, the legacy JavaCC project is just one of these [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] projects. (It is not the only one out there!) Properly understood, it is not even about the people involved in the project currently. I do not recognize the names of most of the people involved in that currently. However, it doesn't matter. There is no remotely realistic prospect of them ever doing anything for a very simple reason:+As I have stated quite bluntly above, the legacy JavaCC project is just one of these [[nothingburger]] projects. (It is not the only one out there!) Properly understood, it is not even about the people involved in the project currently. I do not recognize the names of most of the people involved in that currently. However, it doesn't matter. There is no remotely realistic prospect of them ever doing anything for a very simple reason:
  
 //Nothing significant can be done with the legacy JavaCC codebase without a massive cleanup and refactoring.// //Nothing significant can be done with the legacy JavaCC codebase without a massive cleanup and refactoring.//
Line 111: Line 111:
 I undertook that cleanup and refactoring back in 2008 and it is largely done. The only basis for moving forward on the project is [[https://github.com/javacc21/javacc21|my version of the codebase]], the one that has been cleaned up. I undertook that cleanup and refactoring back in 2008 and it is largely done. The only basis for moving forward on the project is [[https://github.com/javacc21/javacc21|my version of the codebase]], the one that has been cleaned up.
  
-A couple of people have expressed misgivings about my taking the JavaCC name. One person said that this would "create confusion". I agree that there is potentially an issue there. However, my position is that the people creating confusion are the people running the legacy JavaCC project. In general, the people running a [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] project are the ones "creating confusion" because, like it or not, a cold-blooded analysis of the situation is that they are basically perpetrating a fraud, trying to portray an inactive project as something active.+A couple of people have expressed misgivings about my taking the JavaCC name. One person said that this would "create confusion". I agree that there is potentially an issue there. However, my position is that the people creating confusion are the people running the legacy JavaCC project. In general, the people running a [[nothingburger]] project are the ones "creating confusion" because, like it or not, a cold-blooded analysis of the situation is that they are basically perpetrating a fraud, trying to portray an inactive project as something active.
  
-A [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] is essentially a fraud, because it amounts to artfully arranging your bun and your condiments and creating a //trompe l'oeil// so that people get tricked into thinking there is actually some beef in there.+A [[nothingburger]] is essentially a fraud, because it amounts to artfully arranging your bun and your condiments and creating a //trompe l'oeil// so that people get tricked into thinking there is actually some beef in there.
  
 Meanwhile, //JavaCC 21// is what it is being presented as, the active continuation of work on the codebase that Sun open sourced back in 2003. Meanwhile, //JavaCC 21// is what it is being presented as, the active continuation of work on the codebase that Sun open sourced back in 2003.
Line 121: Line 121:
 //Nobody has ever filed a trademark in any jurisdiction on the name JavaCC.// //Nobody has ever filed a trademark in any jurisdiction on the name JavaCC.//
  
-In any case, the problem here is that this is the only feasible course of action. In the open source world, it frequently happens that people show up in a community, one of these [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] projects and propose some ideas and they are arrogantly dismissed and the people are told that they are free to go "fork" the project.+In any case, the problem here is that this is the only feasible course of action. In the open source world, it frequently happens that people show up in a community, one of these [[nothingburger]] projects and propose some ideas and they are arrogantly dismissed and the people are told that they are free to go "fork" the project.
  
 Well, this is technically true. You can create your own "fork" of an open source project, but the problem is that a project of the vintage of JavaCC has such an immense visibility advantage that it is not really feasible to fork off one's one version and "compete" with that. Now, your version is bound to be technically superior. But that does not really matter. Your version will receive almost zero attention and usage. It's fairly easy to see why this would be the case. You just have to visualize some person sitting in a cubicle in the corporate world out there, who is tasked with figuring out the tool stack to use for whatever project. That person will almost never download something like JavaCC and then download FreeCC and make a technical comparison between the two. For starters, in most cases, he never will have heard of FreeCC in the first places. But, more importantly, once something is well established as a standard thing in its space, rightly or wrongly, it will be perceived in the corporate world as the "safe" option. Our imaginary cubicle occupier is taking no risk by advocating the use of JavaCC, but if he did advocate something called "FreeCC" instead, he would be sticking his neck out and people would ask him: "Why not just use the standard thing?" (Which would be JavaCC in this case.) Well, this is technically true. You can create your own "fork" of an open source project, but the problem is that a project of the vintage of JavaCC has such an immense visibility advantage that it is not really feasible to fork off one's one version and "compete" with that. Now, your version is bound to be technically superior. But that does not really matter. Your version will receive almost zero attention and usage. It's fairly easy to see why this would be the case. You just have to visualize some person sitting in a cubicle in the corporate world out there, who is tasked with figuring out the tool stack to use for whatever project. That person will almost never download something like JavaCC and then download FreeCC and make a technical comparison between the two. For starters, in most cases, he never will have heard of FreeCC in the first places. But, more importantly, once something is well established as a standard thing in its space, rightly or wrongly, it will be perceived in the corporate world as the "safe" option. Our imaginary cubicle occupier is taking no risk by advocating the use of JavaCC, but if he did advocate something called "FreeCC" instead, he would be sticking his neck out and people would ask him: "Why not just use the standard thing?" (Which would be JavaCC in this case.)