Return-Path: Delivered-To: apmail-xml-general-archive@www.apache.org Received: (qmail 64799 invoked from network); 8 Jul 2010 20:58:57 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Jul 2010 20:58:57 -0000 Received: (qmail 85355 invoked by uid 500); 8 Jul 2010 20:58:56 -0000 Delivered-To: apmail-xml-general-archive@xml.apache.org Received: (qmail 85304 invoked by uid 500); 8 Jul 2010 20:58:56 -0000 Mailing-List: contact general-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: general@xml.apache.org List-Id: Delivered-To: mailing list general@xml.apache.org Received: (qmail 85296 invoked by uid 99); 8 Jul 2010 20:58:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jul 2010 20:58:56 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mrglavas@ca.ibm.com designates 32.97.182.143 as permitted sender) Received: from [32.97.182.143] (HELO e3.ny.us.ibm.com) (32.97.182.143) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jul 2010 20:58:47 +0000 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o68KiGjC030056 for ; Thu, 8 Jul 2010 16:44:16 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o68KwPo8157206 for ; Thu, 8 Jul 2010 16:58:25 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o68KwPaS030910 for ; Thu, 8 Jul 2010 16:58:25 -0400 Received: from d25ml03.torolab.ibm.com (d25ml03.torolab.ibm.com [9.26.6.104]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o68KwPuv030902; Thu, 8 Jul 2010 16:58:25 -0400 In-Reply-To: <02AA127CD8DCDE48BC7D2DFB6C87083A11C44E@nwt-s-mbx1.rocketsoftware.com> References: <02AA127CD8DCDE48BC7D2DFB6C87083A11C44E@nwt-s-mbx1.rocketsoftware.com> Subject: RE: [POLL]: Dropping JDK 1.3 support for Xerces-J? X-KeepSent: EFC6DFCE:11418A1F-8525775A:0071245B; type=4; name=$KeepSent To: j-dev@xerces.apache.org Cc: "general@xml.apache.org" , "j-users@xerces.apache.org" X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: Michael Glavassevich Date: Thu, 8 Jul 2010 16:58:21 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/08/2010 16:58:25 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFDC9DFE2A2CB8f9e8a93df938690918c0ABBFDC9DFE2A2CB" Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org --0__=0ABBFDC9DFE2A2CB8f9e8a93df938690918c0ABBFDC9DFE2A2CB Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Gary, Gary Gregory wrote on 07/08/2010 02:02:2= 7 PM: > Gary Gregory > Senior Software Engineer > Seagull Software > email: ggregory@seagullsoftware.com > email: ggregory@apache.org > www.seagullsoftware.com > > > From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com] > Sent: Thursday, July 08, 2010 10:33 > To: j-users@xerces.apache.org > Cc: general@xml.apache.org; j-dev@xerces.apache.org > Subject: Re: [POLL]: Dropping JDK 1.3 support for Xerces-J? > > Hi Jake, > > "Jacob Kjome" wrote on 07/08/2010 12:58:49 PM: > > > I have a library I develop (XMLC [1]) that depends on JDK1.3 and > also depends > > on Xerces. That said, part of the reason of depending on JDK1.3 is= > > to stay in > > line with the Xerces dependency on JDK1.3. The other reason is > thatJDK1.3 is > > free and clear of any built-in XML APIs, which allows me to include= exactly > > the JAXP library of my choice (xml-apis.jar) without worry of compile-time > > binding to odd invalid APIs included in 1.4 (such as some stuff > meant for the > > HTML2 API that got placed in the HTML1 API DOM package namespace). = But if > > Xerces decides to move to a later version of Java, then I will > probably move > > XMLC right along with it. > > > > That said, I would think that if Xerces were going to bother > making a move at > > all it would move to JDK1.5 rather than bother with 1.4. Xerces 2.= 10 is > > always there for 1.3 and 1.4 codebases, which should all be well in= to > > maintenance mode meaning few, if any, library changes. > > It's often not a choice but a constraint of the environment the > developer is working in, having to write a new application on top of > a product stack which is stuck on one of these earlier JDK releases. > JDK 1.4 isn't dead yet; still in service for some vendors, including > Oracle/Sun if you're a business willing to pay for the support. Not > aware of any vendors supporting JDK 1.3 anymore though. > > > Moving to 1.5 would > > allow Xerces to take advantage of all the new language constructs a= dded in > > 1.5, as well as APIs added in 1.5 (e.g., StringBuilder -vs- StringBuffer). > > Right. We all talked about the benefits of moving up even higher to > Java 5 and 6 before, but have been quite conservative about > upgrading because of where we are in the food chain. > This seems like some harsh handcuffs for Xerces to live with. If an > app is stuck on Java 1.3, is it also evolving and keeping up with > Xerces versions and new XML and XML Schema standards? I think you missed my first point. > As argued above, you can always use Xerces 2.10, forever. Why not los= e > the shakles? What about getting started on Xerces 3.0 with a 6 > requirement and maintain Xerces 2.x on Java 3 with critical bugs > fixes only? And say ?Welcome to the 21st century J? Sure, that's technically possible but I think it's too early to be jump= ing directly up to 6. Not sure there are many ASF projects which would even= bundle a Java 6 only Xerces release today. Plus I can't think of anythi= ng Xerces would even use that's Java 6 specific. java.util.ArrayDeque mayb= e? but that's hardly a compelling reason to do it. > Gary > > > > So, +1 for changing JDK dependency in general, but I would prefer a= move > > straight to JDK1.5+ skipping JDK1.4 support. This also seems to be= > > what a lot > > of Apache commons libraries are doing, so it's certainly not unprecedented. > > > > [1] http://forge.ow2.org/projects/xmlc/ > > > > > > Jake Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com> E-mail: mrglavas@apache.org= --0__=0ABBFDC9DFE2A2CB8f9e8a93df938690918c0ABBFDC9DFE2A2CB Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Gary,

Gary Gregory <GGregory@seagullsoftware.com> wrote on 07/08/20= 10 02:02:27 PM:

> Gary Gregory
> Senior Software Engineer
> Seagull Software
> email: ggregory@seagullsoftware.com
> email: ggregory@apache.org
> www.seagullsoftware.com
>  
>  
> From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
> Sent: Thursday, July 08, 2010 10:33
> To: j-users@xerces.apache.org
> Cc: general@xml.apache.org; j-dev@xerces.apache.org
> Subject: Re: [POLL]: Dropping JDK 1.3 support for Xerces-J? >  
> Hi Jake,
>
> "Jacob Kjome" <hoju@visi.com> wrote on 07/08/2010 = 12:58:49 PM:
>
> > I have a library I develop (XMLC [1]) that depends on JDK1.3 = and
> also depends
> > on Xerces.  That said, part of the reason of depending o= n JDK1.3 is
> > to stay in
> > line with the Xerces dependency on JDK1.3.  The other re= ason is
> thatJDK1.3 is
> > free and clear of any built-in XML APIs, which allows me to i= nclude exactly
> > the JAXP library of my choice (xml-apis.jar) without worry of= compile-time
> > binding to odd invalid APIs included in 1.4 (such as some stu= ff
> meant for the
> > HTML2 API that got placed in the HTML1 API DOM package namesp= ace).  But if
> > Xerces decides to move to a later version of Java, then I wil= l
> probably move
> > XMLC right along with it.
> >
> > That said, I would think that if Xerces were going to bother =
> making a move at
> > all it would move to JDK1.5 rather than bother with 1.4. &nbs= p;Xerces 2.10 is
> > always there for 1.3 and 1.4 codebases, which should all be w= ell into
> > maintenance mode meaning few, if any, library changes.
>
> It's often not a choice but a constraint of the environment the > developer is working in, having to write a new application on top = of
> a product stack which is stuck on one of these earlier JDK release= s.
> JDK 1.4 isn't dead yet; still in service for some vendors, includi= ng
> Oracle/Sun if you're a business willing to pay for the support. No= t
> aware of any vendors supporting JDK 1.3 anymore though.
>
> > Moving to 1.5 would
> > allow Xerces to take advantage of all the new language constr= ucts added in
> > 1.5, as well as APIs added in 1.5 (e.g., StringBuilder -vs- S= tringBuffer).
>
> Right. We all talked about the benefits of moving up even higher t= o
> Java 5 and 6 before, but have been quite conservative about
> upgrading because of where we are in the food chain.
> This seems like some harsh handcuffs for Xerces to live with. = If an
> app is stuck on Java 1.3, is it also evolving and keeping up with =
> Xerces versions and new XML and XML Schema standards?

I think you missed my first point.

> As argued above, you can always use Xerces 2.10, forever. Why = not lose
> the shakles? What about getting started on Xerces 3.0 with a 6=
> requirement and maintain Xerces 2.x on Java 3 with critical bugs <= br> > fixes only? And say “Welcome to the 21st century J”

Sure, that's technically possible but I think it's too early to be = jumping directly up to 6. Not sure there are many ASF projects which wo= uld even bundle a Java 6 only Xerces release today. Plus I can't think = of anything Xerces would even use that's Java 6 specific. java.util.Arr= ayDeque maybe? but that's hardly a compelling reason to do it.
=
> Gary
>  
>
> > So, +1 for changing JDK dependency in general, but I would pr= efer a move
> > straight to JDK1.5+ skipping JDK1.4 support.  This also = seems to be
> > what a lot
> > of Apache commons libraries are doing, so it's certainly not = unprecedented.
> >
> > [1] http://fo= rge.ow2.org/projects/xmlc/
> >
> >
> > Jake

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org= --0__=0ABBFDC9DFE2A2CB8f9e8a93df938690918c0ABBFDC9DFE2A2CB--