In our project, we provide a java sdk to other teams and there is no document.
With time going on and many developers come and go, we now even don't know how many interfaces we provide.
In this situation, is there any way to get all interfaces we provided?
You might want to take a look at JavaDoc
It can produce documentation in a nice html format, see: link
Good day!
With regards to my previous question about Java Swing being used for web development, I have a job interview today and they told me that their company uses Swing then convert it to javascript then deploy it on the web.
Can anyone explain this to me better? What books / websites should I study so that I could understand how this is done. Is this a good / common practice?
Thank you very much.
You can take a look at CreamTec's AjaxSwing. I've played around with it several times and it's the only product I know so far that takes your existing Swing GUI and converts it into something displayable in your browser.
Whether this is good practice or not is not really easy to answer. This solution works well as long as your application does not need to scale largely. CreamTec states that their solution is suited for about 50 clients IIRC.
The markup generated by AjaxSwing can in no way be called semantic but that is a common thing with these kinds of generators.
You can try AjaxSwing pretty easily since it does not require you to do much configuration but my recommendation is to use a dedicated web framework if you want higher scalability.
It sounds like GWT also. Granted that is not what the person said, but if it was a recruiter, they may been confused on the exact technology.
AjaxSwing is a run-time tool and needs a server license for commercial use.
You might want to try Mia Transformer www.mia-software.com. They change Swing Java code to GWT Java Code and GWT changes it to Javascript and then if you want you can use Google V8 compiler for faster execution. Of course it is not 100%. We are going to try it for a large project and see if it works.
The other link provided to us was http://swingweb.sourceforge.net/swingweb/. Have not checked it out though.
Will keep you posted. If you come across a workable solution please share.
I've got a big problem with IBM HACL for accessing a server which speaks 3270 protocol. The library keeps crashing, and our JNI wrapper is actually a bug-fixing layer for the poorly-implemented and poorly-documented library (and I suspect we have introduced new bugs with it too). Moreover, in our company, everybody knows Java, and could maintain the software if we didn't have the JNI-Layer and the IBM class library.
We have to use the C++ class library, because the IBM Java library is unusable: we get every non-printable character translated, and we lose all control characters along the way.
Now the question is: can we ditch this library and implement our solution in Java completely (we'd like to avoid using another library from another vendor)? Is the protocol well documented? Is the implementation of 3270-over-ssl really so complex?
Thanks.
https://www.rfc-editor.org/rfc/rfc1041
so i guess its documented (assuming i hit the right doc)
couldnt find a java implementation though, you'd need to code it over telnet, or maybe SSH
I am unfamiliar with the differences between 3270 and 5250 data streams, but there is a 5250 implementation in Java in the tn5250j project available from http://tn5250j.sourceforge.net/
It might be usable for you?
(also there is a 3270 screen scraping project at http://freehost3270.sourceforge.net/ but it appears to be abandoned).
freehost3270 doesn't look as abandoned as it might appear - CVS has changes from 2 years ago. There is always an arguement that good code won't need to be changed that often in any case if the requirements have not altered. There have been complimentary comments wrt to the codebase. If you don't particularly want to work with other vendors products then working with this code/project seems to be your best option.
Freehost is not good code. Do not even bother trying it. There is a reason that it seems dead. JIN TN3270 is better but is incomplete. Ideally you want to find the API that your company's Emulator software uses. I am still searching for one for ours.
Another option would be h3270. It is a Java front-end to the x3270 suite of tools.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Let's face it: You don't need to be a designer to see that
default Javadoc looks ugly.
There are some resources on the web which offer re-styled Javadoc. But the default behaviour represents the product and should be as reasonably good-looking.
Another problem is the fact that the usability of Javadoc is not up-to-date compared to other similar resources.
Especially huge projects are hard to navigate using Firefox's quick search.
Practical question:
Are there any standalone (desktop) applications which are able to browse
existing Javadoc in a more usable way than a browser would?
I'm thinking about something like Mono's documentation browser.
Theoretical question:
Does anyone know, if there some plans to evolve Javadoc, in a
somehow-standardized way?
EDIT: A useful link to Sun' wiki on this topic.
I have created a Markdown (java) Doclet which will take source comments in Markdown formatted text and create the same HTML Javadocs.
The new doclet also does some restyling on the text, but the HTML generated is not changed at this stage.
That goes some way to address the HTML-in-java-commenting issues which is probably the biggest usability problem with current Javadoc.
I don't think that the concepts of Javadoc are outdated. As far as i can see, these concepts are rooted years ago in a product named doxygen, which is still available for other languages (i.e. Objective-C where it is heavily used). Even this has it's predecessors - have a look at the programming environment used by Donald Knuth to create TeX (Literate programming).
Nevertheless it is a intriguing idea to have a single source for program code and documentation.
Besides of that, the presentation of the documentation can be customized to your special needs using a plug-in system supported by the JavaDoc tool. You might provide a plug-in (as we do) that publishes directly into a database which is directly accessible via web. Using collaborations anyone can provide additional comments or clarifications to the documentation that might find their way back into the original source.
Javadoc is the best source code auto-documentation generation system I've ever seen. Large part of that is that it's so simple - I can browse javadocs even with my 5 year old cell phone if I want to! While I agree that a bit of a facelift could be in order and especially JDK is a pain to browse through, I wouldn't dare reinventing the wheel entirely because what we currently have is a RESTful, easy to use solution for its purpose which works just about anywhere.
I recently got a mail forwarded that Sun is working on modernizing the Javadoc HTML output. From said mail:
We are proposing improvements to javadoc/doclet for JDK7. The
project wiki page is located at
http://wikis.sun.com/display/Javadoc/Home. As a part of the proposed
improvements, the UI of the javadoc output will be revamped. The new
design screenshots are uploaded to the project wiki. The javadoc output
markup will be modified to be valid HTML and WCAG 2.0 compliant.
So there is definitely still work going on there, even if somewhat late. However, in my eyes one of the biggest drawbacks of Javadoc is its very close coupling with HTML. Many classes have Javadoc which includes literal HTML and relies on the output being HTML, too. Unfortunate, but this won't change anytime, I think. Still, this means that developers are free to include whatever they want in HTML there which might as well be invalid, non-well-formed, etc. So adapting the output from the javadoc tool is only one part of this, the other won't and can't change and thus remains.
As for browsing documentation I also find the HTML documentation a little unwieldy. I usually use the Javadoc view in Eclipse. It has drawbacks as well (slow and you can't really search) but it's Good Enough™ for most things.
Personally I still find Javadoc to be very useful. Especially since it is standardized. I don't know of any major documentation style that I find easier to navigate (that might very well be subjective, but I personally find MSDN horrible to use, for example).
For the search: Use the Javadoc Search Frame, it makes using Javadoc of all kinds a lot easier. It's available as a Userscript for Firefox and as a Google Chrome Extension.
To answer your Practical Question, I googled and asked friends and came up with these. Forrestdoc,doclet and doxygen.
The second question, I would say that yes, its not very "Web-oh-twoeye" but At least your guaranteed to work in an offline environment, and its small enough to ship along with your API. i dispise the use of frames, but then it works rather well for javadoc. I have not seen any plans to change it.
Eclipse has some support for javadoc as far as reading, interpreting and generating it goes.
You might want to phrase that in a less agressive and overbearing manner. Most people don't care what a technical resource looks like, and "It's not Web 2.0 enough!" sounds like vapid marketroidspeak.
And what exactly would you consider "more usable"? Personally, I would definitely like a full text search and a better useage browser, and AJAX could probable help with those.
Well, the nice thing about JavaDoc is that it's the opposite of outdated - it's arbitrarily extensible. Why don't you go ahead and write a doclet that produces the kind of API doc you want?
Why nobody else has done that so far (which apparently is the case) is anyone's guess - maybe nobody else feels as strongly about it as you.
There's a DocBook doclet. DocBook is a richer document type than (X)HTML and is better for describing technical content. From DocBook source you can generate all sorts of different output formats.
I personally would like a more readable "comment documentation" standard than the HTML (and hence tag-wieldy) JavaDoc.
For example, MarkDown, as used here, would be excellent, human readable in the source, nicely formatted external to the source.
With the current JavaDoc, I imagine many people use JavaDoc comments, but don't actually document to the extent they could. I'm sure everyone has browsed an API's online JavaDoc that has been non-documented or barely-documented, and thus far harder to use than it should be.
This isn't helped by code-reformatters (e.g., within Eclipse, or maybe upon source commit) that totally destroy any readable structure you might have put within a JavaDoc comment (e.g., a list of items) into one big blob of text, unless you literally use two carriage returns where you wish to use one).
Does anyone know, if there some plans to evolve Javadoc, in a somehow-standardized way?
The corresponding JSR (JSR 260), which specifies enhancements to Javadoc, has been voted out of JDK 7 (for now). An overview of what was planned (from this site):
Upgrade Javadoc to provide a richer set of tags to allow more structured presentation of Javadoc documentation. This JSR covers: categorization of methods and fields, semantical index of classes and packages, distinction of static, factory, deprecated methods from ordinary methods, distinction of property accessors, combining and splitting information into views, embedding of examples and common use-cases, and more.
The overall outlook for JDK 7 is pretty grim.
JavaDoc is itself extremely flexible because you can replace the standard doclet with a custom doclet to provide something that meets your projects specific needs.
On the project I've been working on, we created an HTML/XML-based documentation system (using client-side XSLT 2.0 on JS) for our product with JavaDoc fully integrated. For this, a custom doclet was used to produce JavaDoc data in XML, this used tagsoup to ensure even HTML markup within code comments were well formed.
With this, we were able to deliver an interactive user experience using a single-page app (similar to a desktop tool), but all from within the browser - without any server-side code/infrastructure. The viewer included standard features such as search, tree navigation etc.
Here's a link to a sample entry point in the rather vast documentation:
JavaDoc viewer sample
Here's an image also:
A smart seachable javadoc viewer:
For many times, I face the problem of browsing JavaDoc. I was looking for something just like Adnroid doc search option. At last I get something like that. If you use firefox the solution is here.
Install the plugin GreaseMonkey, its kinda customizing web page the way we see. ( We need to customize any java doc page, so we can search on class name)
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
For greasemonkey to work, we need some user script for customization. This can be downloaded by greasemonkey automatically. Install the userscript from JavaDoc search frame or JavaDoc incremental search.
This works great for me.
i'm building my webapp using the wicket java web framework. there is one page that i'm building right now contains 20+ external links, a lot of them are pointing to the wikipedia pages. i'm currently hardcoding the url for all these links in the html page.
i could definitely add these links by using the framework (wicket has a class for external link), but i really wonder, is there really a point to do so? all these links are external and they very likely won't change for a long long time. it seems to me if i add them using the framework, it simply just increase the amount of code and it's just a matter of hardcoding java code vs hardcoding html. i really can't think of a reason to do them via the java side.
i'm just a newbie programmer who is trying to learn how to use web framework, so i wonder am i missing anything here? thanks for your help!
When in doubt, go the simple route. You can always refactor and add complexity later if it turns out you need to be more dynamic.
In my opinion, all of the text and links in a web application should be externalized. It's a minimal amount of effort to store this information in a properties file (or content management system for larger applications). This will make it easier to maintain and internationalize your application in the future.
Hope it helps!
--Neal
Remember KISS and YAGNI. If you think the links don't change, wait with programming until you need the flexibility. Flexibility comes always at a price!