You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Ed Staub <es...@mediaone.net> on 2000/09/21 15:10:16 UTC
RE: Xerces2 Requirement 32 (1.1 compatibility)
Given the vetos on _removing_ item 32, I intend to call for a vote to
_approve_ item 32 on the next round of voting. (No votes now, please!)
If there are vetos on the _approve_ vote, then the requirement will be
removed.
See http://xml.apache.org/xerces-j/issues-process.html.
I've warped the process a little by calling for votes to _remove_ items,
just because in cases where I thought there would be consensus to remove, it
seemed like the clearer thing to do. On this item I misjudged; opinions are
pretty split.
The people who are most adamant about 1.1 compatibility are also those with
the most line-of-fire experience with the Xerces user base (the IBM guys).
So if they say 1.1 compatibility is needed, I give it quite a bit of weight,
even though my own preference is to not require 1.1 compatibility.
-Ed
-----Original Message-----
From: Edwin Goei [mailto:Edwin.Goei@eng.sun.com]
Sent: Wednesday, September 20, 2000 9:03 PM
To: xerces-j-dev@xml.apache.org
Subject: Re: [VOTE (PLEASE!)] Xerces2 Requirements 11, 20, 31, 32, 34,
37
Andy Clark wrote:
>
> Which puts us back where we started: we can't use the
> collections and make it work in 1.1 without using a tool
> to change the package imports and rebuild the jar. So I
> think that we should avoid relying on Java 1.2 just for
> convenience.
I would say that people who need to use 1.1 can use Xerces 1, which
works fine on 1.1. For Xerces2, which will be out in the _future_, we
should move to Java2 so that we can benefit from Java2 API features and
performance.
Could we aim for Java2 and if there is enough interest to get it working
for 1.1, have those people port it to 1.1?
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Andy Clark <an...@apache.org>.
Curt Arnold wrote:
> I'd like the requirements to suggest that the slight performance
> hit for using a platform provided list implementation should be
> taken. If the numbers were 1.0,0.98 and 0.67, it would be a
> different story.
I've done some tests where the same implementation between
interface methods and class methods was close to 15% difference
in performance. So going through an interface does hurt you if
you are focused on performance. Also, I try not to rely on
guesses of what future VM technology might be able to do.
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Ed Staub <es...@mediaone.net>.
Sounds like we're pretty much in agreement here, assuming the performance
measurements were perfomed in the context of a reasonable mix of Xerces
usage.
I'll wait a bit before trying to nail down the text.
Thanks!
-Ed
-----Original Message-----
From: Curt Arnold [mailto:CurtA@techie.com]
Sent: Friday, September 22, 2000 1:00 PM
To: xerces-j-dev@xml.apache.org
Subject: Re: Xerces2 Requirement 32 (1.1 compatibility)
b and c were "should" statements which to me indicate a statement on the
part of the requirement authors that can be set aside if its determined
during development that the requirement cannot be met in a way that
satisfies the "shall" requirements such as cutting edge performance and
timely delivery.
In the case of java.util.LinkedList vs a custom implementation vs
java.util.ArrayList, if initial exploration indicated the following
overall performance (lower is better) for implementations using
different list classes:
java.util.LinkedList 1.0
java.util.ArrayList 0.7
org.apache...LinkedList 0.67
I'd like the requirements to suggest that the slight performance hit for
using a platform provided list implementation should be taken. If the
numbers were 1.0,0.98 and 0.67, it would be a different story.
> A weaker form of "XX a" would make sense, something like:
>
> Where possible, method semantics should be identical to those for
Java
> Collections methods. Where methods have the same semantics as Java
> Collections methods, they should have the same name and signature. Where
> semantics differ significantly, methods should not use names from
> Collections which might be confusing.
Sounds reasonable to me. Ideally, if no custom semantics were defined
and collection creation was done through factory methods (vs having "new
ArrayList()"'s sprinked throughout the code) The switching Xerces 2
between different implementations of lists would only involve changing a
few lines.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Curt Arnold <Cu...@techie.com>.
b and c were "should" statements which to me indicate a statement on the
part of the requirement authors that can be set aside if its determined
during development that the requirement cannot be met in a way that
satisfies the "shall" requirements such as cutting edge performance and
timely delivery.
In the case of java.util.LinkedList vs a custom implementation vs
java.util.ArrayList, if initial exploration indicated the following
overall performance (lower is better) for implementations using
different list classes:
java.util.LinkedList 1.0
java.util.ArrayList 0.7
org.apache...LinkedList 0.67
I'd like the requirements to suggest that the slight performance hit for
using a platform provided list implementation should be taken. If the
numbers were 1.0,0.98 and 0.67, it would be a different story.
> A weaker form of "XX a" would make sense, something like:
>
> Where possible, method semantics should be identical to those for Java
> Collections methods. Where methods have the same semantics as Java
> Collections methods, they should have the same name and signature. Where
> semantics differ significantly, methods should not use names from
> Collections which might be confusing.
Sounds reasonable to me. Ideally, if no custom semantics were defined
and collection creation was done through factory methods (vs having "new
ArrayList()"'s sprinked throughout the code) The switching Xerces 2
between different implementations of lists would only involve changing a
few lines.
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Ed Staub <es...@mediaone.net>.
Curt Arnold wrote:
>Revoting on a softer Requirement 32: Xerces 2 "should" (not "shall")
>support JDK 1.1.
I agree, but need to wait to hear if there is dissent.
----------------
I object pretty strongly to XX a, b, and c (Xerces collections must look and
feel like Java Collections) on a couple of grounds.
1. "Private" implementation techniques which aren't exposed in the APIs
shouldn't be dictated by the requirements, beyond "ity" requirements of
readability, maintainability, etc. These requirements imply, in this case,
that if we don't use Collections we should have a darn good reason; they
_don't_ imply that we _must_ use Collections. And here's the darn good
reason...
2. Performance and data size. A lightweight, made-to-purpose functionality
is frequently has much smaller data and is more efficient than a general
one. As a highly relevant example, compare and contrast
java.util.LinkedList with the linked list implementation in
org.apache.xerces.dom.Childnode, et al. The LinkedList implementation
creates an extra object for every child node! With all of the complaints
about how bloated the data size of the DOM is already, I don't think we can
add this kind of constraint.
It may be that an array implementation (hopefully using ArrayList or
something homomorphic to it) will be better than either linked list
implementation, but that's a separate matter. At this point it appears to
be worse, from Arnaud's tests.
A weaker form of "XX a" would make sense, something like:
Where possible, method semantics should be identical to those for Java
Collections methods. Where methods have the same semantics as Java
Collections methods, they should have the same name and signature. Where
semantics differ significantly, methods should not use names from
Collections which might be confusing.
---------------
XX d (Xerces 2 "shall not" require "collections.jar" to be present when
running on JDK 1.2 or later) probably doesn't need to be stated. I'll put
it in if folks really want it. The reason it isn't needed is because Sun
does not license collections.jar for use with 1.2, only with 1.1. I believe
that using it with 1.2 is a violation of the license. See the pre-download
license when you click "continue" to download Collections 1.1 from
http://java.sun.com/products/javabeans/infobus/index.html. Also, the readme
at http://java.sun.com/products/javabeans/infobus/collectionsreadme.html
says:
1.1 Applications are free to use these APIs' in accordance with the
attached license. However 1.2 (Java2) based Applications are
required to use the java.util.* types in order to be compliant.
-Ed Staub
-----Original Message-----
From: Curt Arnold [mailto:CurtA@techie.com]
Sent: Friday, September 22, 2000 4:07 AM
To: xerces-j-dev@xml.apache.org
Subject: Re: Xerces2 Requirement 32 (1.1 compatibility)
We, of course, could continue going around on this. I would suggest the
following:
Revoting on a softer Requirement 32: Xerces 2 "should" (not "shall")
support JDK 1.1.
And would also propose the following additional requirements for voting:
Requirement XX. If collections are used:
a) Collection semantics "shall" conform to the semantics of the JDK 1.2
collection interfaces.
b) Collection implementation "should" be provided by or dispatched to
the platform's collection implementation.
c) Collection-using code "should" be isolated from difference in the
platform's collection interfaces.
d) Xerces 2 "shall not" require "collections.jar" to be present when
running on JDK 1.2 or later. (may be required during build, however).
Requirement XX+1: Xerces shall support XBase
-------------
Discussion:
XX: All this is conditioned on "if" collections are needed, at the low
level stuff that may not need collections, they can just ignore this.
XXa would ensure that we don't do something that is kind of like JDK 1.2
collections but a few things act a little differently. Which would be a
sure cause of developer anguish.
XXb would discourage us from trying to write our own faster XXXList or
XXXSet. Though we may be able to do it, later VM's and JDK's will make
the platform collections faster.
XXc would probably result in a
org.apache.Xerces.Collection.CollectionFactory , Collection[Proxy],
Iterator[Proxy] and similar classes that would act as factories and
proxies to the platform provided collections. An adaptive JDK 1.1/1.2+
implementation of these classes could dynamically load the appropriate
classes and wrap proxies around them. A JDK 1.2 only implementation
could be a handful of classes that are all "final Iterator iterator() {
return _native.iterator() }"'s. Hotspot should be able to optimize (at
least eventually) the overhead down to almost nothing.
XXd is pretty obvious.
XX+1 is implied in the requirement for XInclude, however XBase can be
done at a much lower level than XInclude, will impact other standards
and is already at candidate recommendation.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Curt Arnold <Cu...@techie.com>.
We, of course, could continue going around on this. I would suggest the
following:
Revoting on a softer Requirement 32: Xerces 2 "should" (not "shall")
support JDK 1.1.
And would also propose the following additional requirements for voting:
Requirement XX. If collections are used:
a) Collection semantics "shall" conform to the semantics of the JDK 1.2
collection interfaces.
b) Collection implementation "should" be provided by or dispatched to
the platform's collection implementation.
c) Collection-using code "should" be isolated from difference in the
platform's collection interfaces.
d) Xerces 2 "shall not" require "collections.jar" to be present when
running on JDK 1.2 or later. (may be required during build, however).
Requirement XX+1: Xerces shall support XBase
-------------
Discussion:
XX: All this is conditioned on "if" collections are needed, at the low
level stuff that may not need collections, they can just ignore this.
XXa would ensure that we don't do something that is kind of like JDK 1.2
collections but a few things act a little differently. Which would be a
sure cause of developer anguish.
XXb would discourage us from trying to write our own faster XXXList or
XXXSet. Though we may be able to do it, later VM's and JDK's will make
the platform collections faster.
XXc would probably result in a
org.apache.Xerces.Collection.CollectionFactory , Collection[Proxy],
Iterator[Proxy] and similar classes that would act as factories and
proxies to the platform provided collections. An adaptive JDK 1.1/1.2+
implementation of these classes could dynamically load the appropriate
classes and wrap proxies around them. A JDK 1.2 only implementation
could be a handful of classes that are all "final Iterator iterator() {
return _native.iterator() }"'s. Hotspot should be able to optimize (at
least eventually) the overhead down to almost nothing.
XXd is pretty obvious.
XX+1 is implied in the requirement for XInclude, however XBase can be
done at a much lower level than XInclude, will impact other standards
and is already at candidate recommendation.
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 11:35 AM -0500 9/26/00, rsanford wrote:
>> Because many other platforms and OS's do not now support Java 2 and
>> never will. The MacOS is the big one, but there are others. Also, the
>> open source VMs and class libraries are much closer to 1.1 compliance
>> than 1.2 compliance.
>
>MacOSX beta is out (installed on my iBook!) and currently supports
>JDK 1.3 according to the version info.
>
MacOS X is a completely new operating system. It is NOT the same as
MacOS. It will not run on the majority of the existing hardware, and
it currently has very close to a 0% market share.
Also, remember that Apple has repeatedly promised and demoed far
better Java support than they have ever delivered. They have also
repeatedly reneged on their promises to deliver better Java support.
It's interesting that what you've got claims to be JDK 1.3. In fact
it isn't. What you've got is a 1.2/1.3 hybrid that has not yet
reached full 1.3 compliance. They're promising full Java 1.3 for
sometime next year, but I won't believe it until I see it. Even then,
they will not be supporting this on the existing MacOS.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible (IDG Books, 1999) |
| http://metalab.unc.edu/xml/books/bible/ |
| http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
+----------------------------------+---------------------------------+
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by rsanford <rs...@nolimitsystems.com>.
> Because many other platforms and OS's do not now support Java 2 and
> never will. The MacOS is the big one, but there are others. Also, the
> open source VMs and class libraries are much closer to 1.1 compliance
> than 1.2 compliance.
MacOSX beta is out (installed on my iBook!) and currently supports
JDK 1.3 according to the version info.
rjsjr
Re: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Bill Schindler <de...@bitranch.com>.
Mike Pogue <mp...@apache.org> wrote:
> Where did you find that info on Apple? All I could find was MRJ 2.2.3 info,
> which is essentially JDK 1.1.8 .
Java2 is in Mac OS X (following the OS X links on Apple's site). Mac OS 9
(and earlier) aren't supposed to get anything newer than Java 1.1.x.
--Bill
Re: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Mike Pogue <mp...@apache.org>.
Where did you find that info on Apple? All I could find was MRJ 2.2.3 info,
which is essentially JDK 1.1.8 .
Thanks,
Mike
----- Original Message -----
From: Lawrence Fry <lw...@bbnow.net>
To: <xe...@xml.apache.org>
Sent: Saturday, September 23, 2000 6:01 PM
Subject: RE: Xerces2 Requirement 32 (1.1 compatibility)
> Elliotte,
>
> This is from Apple's web site:
>
> The word on Java 2
> "You know, we've worked very closely with Sun to get Java 2 into DP4,"
Jobs
> says. "And most of it's in there. The remaining parts that are yet to come
> will be fully in there. So we have a full Java 2 implementation when we
ship
> this, this summer, in our public beta. We're very, very pleased with it.
We'
> ve integrated Java 2 fully into Aqua, so that when you have Java 2 apps
they
> look beautiful running on Mac OS X. We've worked very, very closely with
> Sun."
>
> Most platforms have ongoing projects or implementations for Java 2 jvm and
> jdk, including apple.
>
> Regards,
>
> Lawrence
>
>
> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Saturday, September 23, 2000 12:54 PM
> To: xerces-j-dev@xml.apache.org
> Subject: RE: Xerces2 Requirement 32 (1.1 compatibility)
>
>
> At 2:56 PM -0700 9/21/00, Lawrence Fry wrote:
> >That's too bad. The use of hashmap in collections would have increased
the
> >performance over any hashtable implementation.
> >
> >Almost all app servers use Java 2 now, and even the Linux boxes have good
> >implemenations of Java 2. Netscape 6 also includes Java 2, which means
that
> >by the end of the year, most pc's will have Java 2.
> >
> >Why is there such reluctance to implement Xerces 2 with Java 2?
> >
>
> Because many other platforms and OS's do not now support Java 2 and
> never will. The MacOS is the big one, but there are others. Also, the
> open source VMs and class libraries are much closer to 1.1 compliance
> than 1.2 compliance.
> --
>
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> | The XML Bible (IDG Books, 1999) |
> | http://metalab.unc.edu/xml/books/bible/ |
> | http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
> +----------------------------------+---------------------------------+
> | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
> | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
> +----------------------------------+---------------------------------+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
One more point:
Most browser virtual machines only support Java 1.1, not Java 1.2. IE
will probably never ship with 1.2. Yes, there's the Java Plug-In but
nobody besides developers ever installs it. What you have to work
with is what the browser ships with. Anmd that's a 1.1 VM at best.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible (IDG Books, 1999) |
| http://metalab.unc.edu/xml/books/bible/ |
| http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
+----------------------------------+---------------------------------+
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 6:01 PM -0700 9/23/00, Lawrence Fry wrote:
>Elliotte,
>
>This is from Apple's web site:
>
>The word on Java 2
>You know, weve worked very closely with Sun to get Java 2 into DP4, Jobs
>says. And most of its in there. The remaining parts that are yet to come
>will be fully in there. So we have a full Java 2 implementation when we ship
>this, this summer, in our public beta. Were very, very pleased with it. We
>ve integrated Java 2 fully into Aqua, so that when you have Java 2 apps they
>look beautiful running on Mac OS X. Weve worked very, very closely with
>Sun.
This is tricky. Apple is deliberately spreading misinformation about
this and if you don't have a lot of background with Macs and pay very
close attention to exactly what Apple is and is not saying you'll
miss it.
MacOS X is a completely new operating system that will not ship until
sometime next year. It is NOT MacOS. It will not run on the MAJORITY
of existing Mac hardware being used today. It will run some but not
all of the MacOS software people use and depend on today. Furthermore
a substantial percentage of the installed base that can run MacOS X
will not upgrade their machines to this new OS. Java 2 will not be
provided on the classic MacOS that 100% of existing Macs (minus a few
beta testers) are running today.
I estimate that it will be about five years before the existing base
of MacOS machines has dwindled to the point where we can safely
ignore it.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible (IDG Books, 1999) |
| http://metalab.unc.edu/xml/books/bible/ |
| http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
+----------------------------------+---------------------------------+
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Lawrence Fry <lw...@bbnow.net>.
Elliotte,
This is from Apple's web site:
The word on Java 2
You know, weve worked very closely with Sun to get Java 2 into DP4, Jobs
says. And most of its in there. The remaining parts that are yet to come
will be fully in there. So we have a full Java 2 implementation when we ship
this, this summer, in our public beta. Were very, very pleased with it. We
ve integrated Java 2 fully into Aqua, so that when you have Java 2 apps they
look beautiful running on Mac OS X. Weve worked very, very closely with
Sun.
Most platforms have ongoing projects or implementations for Java 2 jvm and
jdk, including apple.
Regards,
Lawrence
-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
Sent: Saturday, September 23, 2000 12:54 PM
To: xerces-j-dev@xml.apache.org
Subject: RE: Xerces2 Requirement 32 (1.1 compatibility)
At 2:56 PM -0700 9/21/00, Lawrence Fry wrote:
>That's too bad. The use of hashmap in collections would have increased the
>performance over any hashtable implementation.
>
>Almost all app servers use Java 2 now, and even the Linux boxes have good
>implemenations of Java 2. Netscape 6 also includes Java 2, which means that
>by the end of the year, most pc's will have Java 2.
>
>Why is there such reluctance to implement Xerces 2 with Java 2?
>
Because many other platforms and OS's do not now support Java 2 and
never will. The MacOS is the big one, but there are others. Also, the
open source VMs and class libraries are much closer to 1.1 compliance
than 1.2 compliance.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible (IDG Books, 1999) |
| http://metalab.unc.edu/xml/books/bible/ |
| http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
+----------------------------------+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 2:56 PM -0700 9/21/00, Lawrence Fry wrote:
>That's too bad. The use of hashmap in collections would have increased the
>performance over any hashtable implementation.
>
>Almost all app servers use Java 2 now, and even the Linux boxes have good
>implemenations of Java 2. Netscape 6 also includes Java 2, which means that
>by the end of the year, most pc's will have Java 2.
>
>Why is there such reluctance to implement Xerces 2 with Java 2?
>
Because many other platforms and OS's do not now support Java 2 and
never will. The MacOS is the big one, but there are others. Also, the
open source VMs and class libraries are much closer to 1.1 compliance
than 1.2 compliance.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible (IDG Books, 1999) |
| http://metalab.unc.edu/xml/books/bible/ |
| http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
+----------------------------------+---------------------------------+
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Lawrence Fry <lw...@bbnow.net>.
That's too bad. The use of hashmap in collections would have increased the
performance over any hashtable implementation.
Almost all app servers use Java 2 now, and even the Linux boxes have good
implemenations of Java 2. Netscape 6 also includes Java 2, which means that
by the end of the year, most pc's will have Java 2.
Why is there such reluctance to implement Xerces 2 with Java 2?
Regards,
Lawrence
-----Original Message-----
From: Ed Staub [mailto:estaub@mediaone.net]
Sent: Thursday, September 21, 2000 2:50 PM
To: xerces-j-dev@xml.apache.org
Subject: RE: Xerces2 Requirement 32 (1.1 compatibility)
"approve" means to approve the statement:
The parser shall support Java 1.1.
In other words, to require that X2 run on JDK 1.1.
See http://xml.apache.org/xerces-j/issues.html.
-Ed
-----Original Message-----
From: Edwin Goei [mailto:Edwin.Goei@eng.sun.com]
Sent: Thursday, September 21, 2000 4:07 PM
To: xerces-j-dev@xml.apache.org
Subject: Re: Xerces2 Requirement 32 (1.1 compatibility)
Ed Staub wrote:
>
> Given the vetos on _removing_ item 32, I intend to call for a vote to
> _approve_ item 32 on the next round of voting. (No votes now, please!)
>
> If there are vetos on the _approve_ vote, then the requirement will be
> removed.
So does "approve" mean to require that X2 (Xerces2) runs on 1.1 or the
reverse? I think there is confusion as to what "approve" means because
the item being voted on is not clear.
Back to the original subject, though... to provide a more concrete
example, instead of the commonly used Hashtable, the Java2 collections
API has a HashMap. A HashMap is similar to a Hashtable, but has
unsynchronized access methods and allows "null" values to be placed in
it. Hashtable uses synchronized methods that negatively affect
performance in the usual case where synchronization is unnecessary. By
using HashMap instead, performance will be enhanced without affecting
code readability. (There is also a way to get the synchronized behavior
for HashMap.)
As someone else stated, there is a version of the collections API that
works with 1.1, but "import" statements in the Java files would need to
be changed. As a compromise, would it be acceptable to program X2 to
the Java2 API (JDK 1.2 and above) and have JDK 1.1 people who do not
want to use X1 for some reason to port X2 to 1.1? This would require
changing package names for the Collections API and perhaps implementing
a few other methods new in Java2.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
RE: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Ed Staub <es...@mediaone.net>.
"approve" means to approve the statement:
The parser shall support Java 1.1.
In other words, to require that X2 run on JDK 1.1.
See http://xml.apache.org/xerces-j/issues.html.
-Ed
-----Original Message-----
From: Edwin Goei [mailto:Edwin.Goei@eng.sun.com]
Sent: Thursday, September 21, 2000 4:07 PM
To: xerces-j-dev@xml.apache.org
Subject: Re: Xerces2 Requirement 32 (1.1 compatibility)
Ed Staub wrote:
>
> Given the vetos on _removing_ item 32, I intend to call for a vote to
> _approve_ item 32 on the next round of voting. (No votes now, please!)
>
> If there are vetos on the _approve_ vote, then the requirement will be
> removed.
So does "approve" mean to require that X2 (Xerces2) runs on 1.1 or the
reverse? I think there is confusion as to what "approve" means because
the item being voted on is not clear.
Back to the original subject, though... to provide a more concrete
example, instead of the commonly used Hashtable, the Java2 collections
API has a HashMap. A HashMap is similar to a Hashtable, but has
unsynchronized access methods and allows "null" values to be placed in
it. Hashtable uses synchronized methods that negatively affect
performance in the usual case where synchronization is unnecessary. By
using HashMap instead, performance will be enhanced without affecting
code readability. (There is also a way to get the synchronized behavior
for HashMap.)
As someone else stated, there is a version of the collections API that
works with 1.1, but "import" statements in the Java files would need to
be changed. As a compromise, would it be acceptable to program X2 to
the Java2 API (JDK 1.2 and above) and have JDK 1.1 people who do not
want to use X1 for some reason to port X2 to 1.1? This would require
changing package names for the Collections API and perhaps implementing
a few other methods new in Java2.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Xerces2 Requirement 32 (1.1 compatibility)
Posted by Edwin Goei <Ed...@eng.sun.com>.
Ed Staub wrote:
>
> Given the vetos on _removing_ item 32, I intend to call for a vote to
> _approve_ item 32 on the next round of voting. (No votes now, please!)
>
> If there are vetos on the _approve_ vote, then the requirement will be
> removed.
So does "approve" mean to require that X2 (Xerces2) runs on 1.1 or the
reverse? I think there is confusion as to what "approve" means because
the item being voted on is not clear.
Back to the original subject, though... to provide a more concrete
example, instead of the commonly used Hashtable, the Java2 collections
API has a HashMap. A HashMap is similar to a Hashtable, but has
unsynchronized access methods and allows "null" values to be placed in
it. Hashtable uses synchronized methods that negatively affect
performance in the usual case where synchronization is unnecessary. By
using HashMap instead, performance will be enhanced without affecting
code readability. (There is also a way to get the synchronized behavior
for HashMap.)
As someone else stated, there is a version of the collections API that
works with 1.1, but "import" statements in the Java files would need to
be changed. As a compromise, would it be acceptable to program X2 to
the Java2 API (JDK 1.2 and above) and have JDK 1.1 people who do not
want to use X1 for some reason to port X2 to 1.1? This would require
changing package names for the Collections API and perhaps implementing
a few other methods new in Java2.
-Edwin