Roger Brinkley's Blog

When 12% is really greater than 50%

When the 2005 WritersUA Skills and Technologies Survey initially was published a coworker forwarded me the results showing JavaHelp with a 12% of the respondents saying it was valuable or invaluable to them. I didn't understand at first why he was so excited. I mean after all if the number had been 13% I would have been rejoicing since that was the number I wore in my athletic days. No superstition here. But a 12% share that's nothing special, especially when HTML Help has a 55% share.

But further analysis shows this 12% is actually more like 50% and in fact is almost the same share of the market that HTML Help has. Take a closer look at the survey and in particular the platform section. Java users only make up 22% of the respondents where as Windows is used by over 95% of the respondents. That means that JavaHelp has 54% of the java users and HTML Help has 57% of the Windows users. That's a significant share of the market.

I believe that in the next year that this number will move higher for a couple of reasons.

• The use of the Java client for rich client applications is increasing. Recent Evans Data for 2005 shows the Java Client increasing from 37% in 2003 to 39%. While this isn't a significant increase it shows a forward movement in Java Client development. And it does make me wonder where the other 17% of the Java developers are in this survey.
  


• We've made some technical enhancements to improve the product. The latest release provided support for GTK look and feel and the capability of using alternative content viewers. The later is probably the most important as help authors now have the option of using a native browser or alternative browser like those available for Chimsaw and IceSoft.
  


• JavaHelp is being used in non traditional environments. Within Sun JavaHelp is the base platform for help in the Java Desktop System operating system including the Solaris 10 desktop, also in all of Sun's server based products as well as the traditional Java Client products like Netbeans. This demonstrates the variety of uses from Java Clients (our traditional use), to java server based applications, to Unix based native applications.
  

If you haven't considered JavaHelp in while maybe it's time to take another look. I'm sure that by next year the percent of users will increase significantly. I'm thinking a lot more than 13% for next year. Not that I have any superstitions about the number 13. ;)

Roger Brinkley
JavaHelp Engineering

Comments

• 
  JavaHelp is a nice library with strong architecture that does its job and I do thank for it to everybody involved - BUT

  
  It is full of worarounds from early Java 1.0 and 1.1 days.

  1] Reflection being used everywhere instead of proper method invocations just because the authors did not know whether they are running 1.1 or 1.2 so they tried to invoke method using reflection and ignored if the method did not exist. No need to say that I there are even some mispellings in the names of invoked methods....

  
  2] Instead of being cleanly implemented on top of JAXP when it comes to processing XML configuration file the JavaHelp still relyes on some ancient home grown push-parser that must be distributed
  as part of the library. I do not trust the parser realy conforms to XML specification.

  There are also some bugs and shortcommings I have to
  workaround now:

  3] There is also many bugs I have to workaround myself - e.g. build-in browser reload button does not work. Because to releod document in JTextPane you have to invoke
  textPane.getDocument().putProperty(Document.StreamDescriptionProperty,null);

  before you can repeat:

  textPane.setPage(same-url-as-before);

  3] Back Button starts to work only after third page is visited because of the order of initialization between HelpModel and HelpHistoryModel inside BasicHelpUI

  4] The JDIC integration is pathetic because the JDIC Webbrowser does not support same level of functionality as JTextPane - e.g. you can not highlight fulltext-search results....

  
  5] The sources that are available for download are incomplete, they
  do not cover the fultext search part. Also API description for fulltext
  indexer is missing.

  
  6] Part of the sources have been lost over the years so they are recreated by reverse-engineering (jad) .... without any comments and proper names of method arguments and local variables...

  
  Long Long LONG time ago SUN promised to opensource the library.
  It would allow me to contribute the fixes and there would be more manpower to get rid of all these Java 1.1 relicts.
  

  Posted by: vtec on August 29, 2005 at 11:25 PM

• Where do I begin.

  Reflection being used everywhere instead of proper method invocations

  All of the 1.1 reflection calls were removed when we made the decision to no longer support 1.1. That doesn't mean that there still isn't reflection calls in the source.

  Reflection is still necessary though as support for new APIs from newer JDKs are incorrporated into the JavaHelp releases. Specifically, if the user is on 1.2 then print page setup is handled differently depending on the OS your on; on 1.3 then drag n drop is enabled in Favorites; and on 1.4 the popup wheel mouse is enabled for popups.

  Reflection is also necessary to enable the dynamic aquistion of icons, views, merge types, presentations, and help actions. Since all of these data types are stored as text in the HelpSet files the only way of extracting them is through reflection. The side benefit is that this allows for developer created icons, views, merge types, presentations and help actions which would extend the JavaHelp API beyond the standard.

  Instead of being cleanly implemented on top of JAXP

  JAXP wasn't added until JDK 1.5. As such we need some type of XML processing for prior versions. While the processor isn't the best in the world is does work. Of course this doesn't mean that we shouldn't use JAXP since it's in the JDK's where available, but it's a very low priority since what we have works..

  There is also many bugs I have to workaround myself

  If you file bugs with suggested fixes they will be fixed. Otherwise all the complaining in the world won't fix them. Goto http://bugs.sun.com/services/bugreport/index.jsp to file the bug. Your specific point on refresh will be looked at for the next release.

  Back Button starts to work only after third page is visited
  
  Interesting. I'll take a look at it. But once again filing a bug report with a suggested fix is the best way to get the problem fixed.

  The JDIC integration is pathetic because the JDIC Webbrowser does not support same level of functionality

  Search highlighting is based on the JEditorPane. In retrospect that was the incorrect implementation. In some future release I'd like to look into changing the search engine so that it isn't dependent on the JEditor pane but the text itself. What the native JDIC browser (or alternative 3rd party browsers) gives you is the better rendering and more extensive plugins. It's a trade off between better rendering versus search highlighting. Tough choice that hopefully sometime in the future we can address.

  The sources that are available for download are incomplete

  And will remain this way for the near future. This is consistent with sources in JDK. You don't get all the source of the JDK (though this is changing with the Mustang project on java.net). In particular the search engine will not be included as it's proprietary work. If we did open source JavaHelp the sources for the search would not be included but a jar file would be made available.

  Part of the sources have been lost over the years

  We have all the sources available internally. I'm not sure why this would be done in the first place (restoring), but I am realatively certian that it would be a violation of the license agreement. If there is something that has been removed then you need to speak up. I don't
  believe we have removed any APIs, but you shouldn't be coding to anything other than the API. Implementations might have changed dued to tighting of the specification but no functionality was never reduced.

  Long Long LONG time ago SUN promised to opensource the library

  Last fall there was some consideration of JavaHelp being added to the JDK for mustang. That is no longer an option so open source is again a possibility. However, keep in mind that all changes would be reviewed for compatibility and consistency reasons by the original developers. Not all changes would be accepted. And as mentioned before the 1.1 relics were removed in 2.0.

  Posted by: brinkley on August 30, 2005 at 12:09 PM

• Hello Mr. Brinkley

  Thanks for your answers.

  
  You are probably right about those missing decompiled sources, I might have done it myself in desperate need of debugging ;-(. Please consider adding more into the source bundle (e.g. CustomKit.java, XML parsing related files and other non-fulltext search related) ... these are often necessary to understand what is going on.

  
  JAXP is part of Java since 1.4 but it was the defacto standart during 1.3 lifetime as well - there are no exuses to avoid it.

  
  About these 1.1 relicts - seems they are more 1.2 != 1.3 != 1.4 relicts (e.g the MouseWheel...). I would suggest to break this backwards compatibility and create 1.5 complient release.... The users of older JVMs should use older JavaHelp - that would make 99% of users happy and provide more comfort to evolve the library.

  
  Please dont forget to fix JHelpContentViewer.reload(); that does not work properly as I mentioned in 3] of my original post because of
  in BasicContentViewerUI line 317 is missing call html.getDocument().putProperty(Document.StreamDescriptionProperty,null)

  
  Please dont forget to enhance CustomKit.ObjectView1.getClass(String string) to try context classloader in addition to the classloader that was used to load JavaHelp itself - if JavaHelp is installed as JRE extension then there is no way how to load client components...

  
  Please dont forget to fix CustomKit.clone() method - it should call super.clone() instead of using constructor - it was a VERY PAINFULL DISCOVERY.

  
  

  Posted by: vtec on August 31, 2005 at 12:54 AM

• Hi Mr. Brinkley

  i implement in JavaHelp with my application and now i can invoke the other function of JavaHelp such as content, index , search in menuBar and it's work well. But My confusing if i want make convenience to user i want to create a quick search that function will activate when user input keyword in comboBox and press enter then it should return a list of relevant of keywork to show (in this it similar user typing a keyword on search navigator, i don't know how should i coding to show the result in GUI that i expect.

  And Next of question, in JavaHelp that have a problem with viewer renderer. i read article of you and i try to implement with the JDIC native brower that will show same of original html that i create with CSS but it's has a next problem with some function that not correct working such as print page not map of viewer pane , when a resize JavaHelp window that not show scroll bar and other. Then i found webrender that have support the CSS that i download to try that i don't know how to set instead of BasicViewerUI of JavaHelp.

  Thanks so much for your sugession

  ps. i read the user guide that explain in test database of indexer.bat that buid database of search and i try to do that it work well , i run
  jhsearch.bat that show that result that found then i think if i know working step of that then i apply to use with my case , it will work.

  Posted by: santa_ja on September 01, 2005 at 03:09 AM

This work is licensed under a Creative Commons License.