Menu

Support for JDK 1.5?

2007-02-19
2013-05-12
  • John Brugge

    John Brugge - 2007-02-19

    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

     
    • Jason S

      Jason S - 2007-03-03

      Yep, one day. Kind of hoping people might want to help out though.

      Hence why I mate it opensource.

      Jason

       
    • Jim Standley

      Jim Standley - 2007-06-15

      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. :-)

       
    • Leon Poyyayil

      Leon Poyyayil - 2007-06-27

      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

       
    • Leon Poyyayil

      Leon Poyyayil - 2007-06-27

      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 ...)

       
    • Leon Poyyayil

      Leon Poyyayil - 2007-07-03

      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

       
    • Jason S

      Jason S - 2007-07-17

      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

       
    • Leon Poyyayil

      Leon Poyyayil - 2007-07-19

      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

       
    • Jason S

      Jason S - 2007-07-21

      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

       
    • Leon Poyyayil

      Leon Poyyayil - 2007-07-25

      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

       
  • Jason S

    Jason S - 2013-05-12

    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

     
    • Leon Poyyayil

      Leon Poyyayil - 2013-05-12

      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 ...

       
  • Jason S

    Jason S - 2013-05-12

    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

     
    • Leon Poyyayil

      Leon Poyyayil - 2013-05-12

      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

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.