Thread: RE: [Htmlparser-developer] Latest code Problems
Brought to you by:
derrickoswald
From: <dha...@or...> - 2003-01-08 14:00:36
Attachments:
BDY.RTF
|
I agree with Holger out here. Our base Java version to support should be JDK 1.2. -----Original Message----- From: Holger.Stenzhorn [mailto:Hol...@xt...] Sent: Wednesday, January 08, 2003 7:23 PM To: htmlparser-developer Subject: AW: [Htmlparser-developer] Latest code Problems Hi! ...stupid question: Do we really need to still support JDK 1.1? I know that relying on the new features of 1.4 would blow many current apps, so we should not do this for the time being. But the integration of e.g. the Collections framework introduced in JDK 1.2 (which is a long time ago) into HTMLParser should be possible and done. =20 So to add my opinion to the poll: I would like to drop support for JDK 1.1.=20 Holger -----Urspr=FCngliche Nachricht----- Von: Derrick Oswald [mailto:Der...@ro...] Gesendet: Mittwoch, 8. Januar 2003 14:11 An: htm...@li... Betreff: Re: [Htmlparser-developer] Latest code Problems <snip> > =20 > [2] HTMLLinkBeanInfo and HTMLTextBeanInfo dont compile. Are you=20 > relying on something in JDK 1.4 ? Bytway, htmlparser is JDK 1.1=20 > compliant. I am not sure if that should change, but then again, it=20 > really depends on the users of the parser. 1.1 compatibility is news to me. This has probably been broken for a=20 while (see ArrayList in ChainedException and Iterator in Translate). Version 1.1 is usually mandated by old browser JVM support, or legacy=20 (unsupported) operating systems. I don't think it's an issue here since it's not running as an applet. The use of the Vector class (required=20 under JDK 1.1) is a bit of a performance hit since the class is=20 synchronized. For now just delete those 'BeanInfo' files and it should compile OK, but I'll see if I can fix it for you, and then a decision can be made about=20 continuing 1.1 support. </snip> ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See! http://www.vasoftware.com _______________________________________________ Htmlparser-developer mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/htmlparser-developer ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld - Something 2 See! http://www.vasoftware.com _______________________________________________ Htmlparser-developer mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/htmlparser-developer |
From: Somik R. <so...@ya...> - 2003-01-08 17:41:32
|
Hi Dhaval, Holger, > I agree with Holger out here. Our base Java version > to support should be > JDK 1.2. I agree about JDK 1.2. I think its high time to move on. Some folks were using this with JDK 1.1 ages back in an applet. But about the Collections issue - did you take a look at HTMLVector ? Having our own vector class will enable us to avoid the performance hit in class casting. Regards, Somik __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Joshua K. <jo...@in...> - 2003-01-13 15:27:36
|
Folks, Of late, Somik and I have been using the HTML Parser for various tasks related to XML documents, not HTML. We have found that the parser's scanners make our life easier than it would be if we were to use Xerces. Yet I find it awkward for our code to interact with classes like HTMLNode when we are in fact working with XML nodes. I wonder if it makes sense to make the parser more generic so that it is clear that it is useful for both HTML and XML. I'd welcome any feedback on this idea. best regards jk |
From: Kaarle K. <kaa...@ik...> - 2003-01-08 19:33:47
|
At 09:41 8.1.2003 -0800, you wrote: >Hi Dhaval, Holger, > > > I agree with Holger out here. Our base Java version > > to support should be > > JDK 1.2. > >I agree about JDK 1.2. I think its high time to move >on. Some folks were using this with JDK 1.1 ages back >in an applet. As I looked at the code in CVS yesterday it did not compile OK with JDK 1.3 I needed to do it with JDK 1.4.1 Kaarle >But about the Collections issue - did you take a look >at HTMLVector ? Having our own vector class will >enable us to avoid the performance hit in class >casting. > >Regards, >Somik > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >http://www.vasoftware.com >_______________________________________________ >Htmlparser-developer mailing list >Htm...@li... >https://lists.sourceforge.net/lists/listinfo/htmlparser-developer --------------------------------------------- Kaarle Kaila http://www.iki.fi/kaila mailto:kaa...@ik... tel: +358 50 3725844 |
From: Derrick O. <Der...@ro...> - 2003-01-09 04:11:55
|
Karle, I've removed the reference to getPath() in HTMLLinkProcessor and removed the BeanInfo classes. It compiles under JDK 1.2.2 and 1.3.0 on NT and JDK 1.4.1_01 on Linux. Unit tests are all clear except for 21 failures when using JDK 1.2.2 on NT. These are mostly due to attribute rearrangement by toHTML() in various tags and URL resolution problems in HTMLLinkProcessor. Derrick Kaarle Kaila wrote: > As I looked at the code in CVS yesterday it did not compile OK with > JDK 1.3 > I needed to do it with JDK 1.4.1 > > Kaarle > |