Thread: RE: [Htmlparser-developer] Latest code Problems

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

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

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

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 

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
>