Do you have any plans or hopes to support JDK 1.5 syntax? I really like the javadoc-like framed layout you have, but we have projects using jdk 1.5. For them, about the only option is "the other" java2html (java2html.de), which supports the language features but really isn't a source browser.
Thanks, and great tool.
John Brugge
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to light a fire under Jason and the OS crowd ... for this very reason I modified java2html.de to a pale imitation of Jason's code browser.
* Made a launcher wrapper that builds a list of all .java files in the source directory and then starts the usual de.java2html.Java2Html main()
* Modified JavaSource2HTMLConverter.toHtml() to pass CODE "runs" through my trasnformer
* For each BumpyWord in the fragment see if I found a Java file that matches. If so, generate a link.
Then in Ant I run JavaDoc, run java2html, copy all the html output into the JavaDoc directory. Now the JavaDoc index displays java2html output. Heh heh.
This is a mockery of a sham of a travesty of a hack, but I'd be happy to share it until somebody gets Jason's far superior tool working on Java 5. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i've updated the code to work with the latest available Java1.5.jj from javacc-4.0.
it works quite well, but there are still some quirks (classes in generic type parameter lists aren't hyperlinked for example). but at least it is again possible to use the known functionality with current (jdk 1.5.0+) code :-)
so far i've just updated the syntax and tweaked the existing code a little here and there. quite some refactoring would be necessary to properly support nested classes and so on in a stable manner (imho). i don't have time for this at the moment, but still chances are, somebody might be interested in a working version.
if somebody can add me as a project developer i'll check in the updates ...
hope to hear from you
cheers
Leon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ps: please be somewhat patient when replying to me: my new sf mail alias is not yet activated ... (should happen within the next 24 hours according to sf ...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as i haven't heard from anyone so far, i've just uploaded two patches with the modified sources and compiled binaries with my changes for those who know how to deal with it.
the compiled binary should work as a drop-in replacement for the old j2h.jar - just with the new features supported.
have fun and thanks in advance for any comments, suggestions or constructive criticism,
cheers
leon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep, I looked at your patches. Looks like you've done some useful stuff. Will try and include most it.
The current code base maintains two parsers as I originally planned to include full hyper linking of all methods and object references. I think that if I want to implement such a thing then I need to implement it as two parse solution. What do you think? Of-course maintaing two sets of grammars files is not great though. I could perhaps use the Visitor pattern support provided by JavaCC, to do two parses with one grammar file. (probably a lot neater) what do you think?
Also, I need to implement some decent error recovery. Errory Recovery in top-down parsers is not so straighfoward as I understand it. You need to implement special error rceovery productions in the grammar for every production rule? Any thoughts ?
Will probably get to look at all this next week sometime, Im busy this weekend.
Have a good one. Will look at getting you setup as a developer.
Jason
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
two parse solution: well, yes and no. i agree it's probably necessary to make two passes over the input files for that purpose to keep the solution scalable to large code bases. however, i'd prefer a solution with one parser syntax for two reasons: 1) better to maintain. 2) change the parser syntax to build an in-memory model of the java file at hand. from this memory model we should understand, what the code actually does/mean and then generate the corresponding html. intermingling this task with the actual parsing process as is the current state, will make maintainability harder as new features will be added, as it interferes with the parsing and so on. in this way we would also be better off in correctly supporting nested/inner classes and generics arguments as we could add these one by one independent of everything else. this would be quite a refactoring however ...
error recovery: from my point of view, there's not too much reason to invest a great effort into this. when using the tool as a documentation help, we can assume that the source code being processed is valid and compilable (of which javac makes a pretty good job). which actually makes it unnecessary to provide error handling, imho.
accepting invalid code is never a good thing ... as the source code is the only valid reference of any software system ... ;-)
i'm currently very busy and won't have too much time for big time action, sorry. i'll be happy to help out as much as i can, can't promise anything however.
cheers so far
leon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well thanks for your support and your timely response, feel free to chip in when you want.
On the subject of Maven, I understand when you are coming from, but having worked in large organisations, tools like Maven are invaluable. What do you use instead of Maven? I did consider Gradle too.
Jason
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
easy. i haven't forgotten your tool, in fact it is still in use (the version with my patches for jdk 1.5 support). but i'm not very active in that project currently ...
maven: well, i still cling to plain old ant. that's where i'm in control and things are explicit. i don't like implicit stuff. i prefer to be able to read a script and see from it what it does. in maven, too much is by convention (for my taste), which requires me to always be aware of those conventions, e.g. know the manual by heart. not exactly self explanatory ... especially when having to deal with a lot of tools in a lot of environments on different OSs ...
but of course this is highly personal and tells more about my habits than about the quality of any tool like maven ...
cheers
leon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you have any plans or hopes to support JDK 1.5 syntax? I really like the javadoc-like framed layout you have, but we have projects using jdk 1.5. For them, about the only option is "the other" java2html (java2html.de), which supports the language features but really isn't a source browser.
Thanks, and great tool.
John Brugge
Yep, one day. Kind of hoping people might want to help out though.
Hence why I mate it opensource.
Jason
Just to light a fire under Jason and the OS crowd ... for this very reason I modified java2html.de to a pale imitation of Jason's code browser.
* Made a launcher wrapper that builds a list of all .java files in the source directory and then starts the usual de.java2html.Java2Html main()
* Modified JavaSource2HTMLConverter.toHtml() to pass CODE "runs" through my trasnformer
* For each BumpyWord in the fragment see if I found a Java file that matches. If so, generate a link.
Then in Ant I run JavaDoc, run java2html, copy all the html output into the JavaDoc directory. Now the JavaDoc index displays java2html output. Heh heh.
This is a mockery of a sham of a travesty of a hack, but I'd be happy to share it until somebody gets Jason's far superior tool working on Java 5. :-)
hi all,
i've updated the code to work with the latest available Java1.5.jj from javacc-4.0.
it works quite well, but there are still some quirks (classes in generic type parameter lists aren't hyperlinked for example). but at least it is again possible to use the known functionality with current (jdk 1.5.0+) code :-)
so far i've just updated the syntax and tweaked the existing code a little here and there. quite some refactoring would be necessary to properly support nested classes and so on in a stable manner (imho). i don't have time for this at the moment, but still chances are, somebody might be interested in a working version.
if somebody can add me as a project developer i'll check in the updates ...
hope to hear from you
cheers
Leon
ps: please be somewhat patient when replying to me: my new sf mail alias is not yet activated ... (should happen within the next 24 hours according to sf ...)
hi again,
as i haven't heard from anyone so far, i've just uploaded two patches with the modified sources and compiled binaries with my changes for those who know how to deal with it.
the compiled binary should work as a drop-in replacement for the old j2h.jar - just with the new features supported.
have fun and thanks in advance for any comments, suggestions or constructive criticism,
cheers
leon
Hi Leon, thanks for your help.
I didnt realise anyone was posting to this forum.
As it happens, I just yesterday released a version to support java 1.5 syntax. I apologise for this duplicated effort.
I will be checking this forum on a more regular basis from now on.
However, I will compare your updates with mine. yours may well have additional benefits which I had not considered.
And it's is good that someone else is familiar with the code base.
Thanks,
Jason
hi jason!
cool, already thought you abandoned the nice tool ...
well, looking forward to seeing the new code appear :-)
hope, i didn't mess too much with the original code for your taste ...
anyway, thanks again for your nice tool!
cheers
leon
Yep, I looked at your patches. Looks like you've done some useful stuff. Will try and include most it.
The current code base maintains two parsers as I originally planned to include full hyper linking of all methods and object references. I think that if I want to implement such a thing then I need to implement it as two parse solution. What do you think? Of-course maintaing two sets of grammars files is not great though. I could perhaps use the Visitor pattern support provided by JavaCC, to do two parses with one grammar file. (probably a lot neater) what do you think?
Also, I need to implement some decent error recovery. Errory Recovery in top-down parsers is not so straighfoward as I understand it. You need to implement special error rceovery productions in the grammar for every production rule? Any thoughts ?
Will probably get to look at all this next week sometime, Im busy this weekend.
Have a good one. Will look at getting you setup as a developer.
Jason
hi again
two parse solution: well, yes and no. i agree it's probably necessary to make two passes over the input files for that purpose to keep the solution scalable to large code bases. however, i'd prefer a solution with one parser syntax for two reasons: 1) better to maintain. 2) change the parser syntax to build an in-memory model of the java file at hand. from this memory model we should understand, what the code actually does/mean and then generate the corresponding html. intermingling this task with the actual parsing process as is the current state, will make maintainability harder as new features will be added, as it interferes with the parsing and so on. in this way we would also be better off in correctly supporting nested/inner classes and generics arguments as we could add these one by one independent of everything else. this would be quite a refactoring however ...
error recovery: from my point of view, there's not too much reason to invest a great effort into this. when using the tool as a documentation help, we can assume that the source code being processed is valid and compilable (of which javac makes a pretty good job). which actually makes it unnecessary to provide error handling, imho.
accepting invalid code is never a good thing ... as the source code is the only valid reference of any software system ... ;-)
i'm currently very busy and won't have too much time for big time action, sorry. i'll be happy to help out as much as i can, can't promise anything however.
cheers so far
leon
Hi Leon,
started to pick this up again (after so many years). Wondered if you wanted to help out.
I used your restructuring for the basis of a new version. Also moved over to Maven.
I'm trying to build a Maven Mojo too.
Jason
hi jason
sorry, have to turn you down, at least for the near future. too busy with other projects and i don't (yet) see the light at the end of the tunnel ...
maybe i'll find some time to give feedback if you have a new release. but other than that - no chance at the moment.
also, i must admit i'm not a fan of maven ...
cheers
leon
ps: yes, indeed, quite some years passed ...
well thanks for your support and your timely response, feel free to chip in when you want.
On the subject of Maven, I understand when you are coming from, but having worked in large organisations, tools like Maven are invaluable. What do you use instead of Maven? I did consider Gradle too.
Jason
easy. i haven't forgotten your tool, in fact it is still in use (the version with my patches for jdk 1.5 support). but i'm not very active in that project currently ...
maven: well, i still cling to plain old ant. that's where i'm in control and things are explicit. i don't like implicit stuff. i prefer to be able to read a script and see from it what it does. in maven, too much is by convention (for my taste), which requires me to always be aware of those conventions, e.g. know the manual by heart. not exactly self explanatory ... especially when having to deal with a lot of tools in a lot of environments on different OSs ...
but of course this is highly personal and tells more about my habits than about the quality of any tool like maven ...
cheers
leon