Re: RFR (JAXP): 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer.

Thanks Lance! Joe On 7/29/2014 6:46 PM, Lance Andersen wrote: This looks ok joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Jav

Re: RFR (JAXP): 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer.

This looks ok joe Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 [email protected] Sent from my iPhone > On Jul 29, 2014, at 9:23 PM, huizhe wang wrote: > > >> On 7/29/2014 3:03 PM, L

Re: RFR (JAXP): 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer.

On 7/29/2014 3:03 PM, Lance Andersen wrote: Hi Joe, The javadoc documentation,http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javadoc.html#CHDIBDDD, suggests a format such as /** * @deprecated As of JDK 1.1, replaced by {@link #setBounds(int,int,int,int)} */ Ok, let's do:

Re: RFR (JAXP): 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer.

Hi Joe, The javadoc documentation,http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javadoc.html#CHDIBDDD, suggests a format such as /** * @deprecated As of JDK 1.1, replaced by {@link #setBounds(int,int,int,int)} */ I do not have a strong preference as to whether we need the "As o

Re: RFR (JAXP): 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer.

Hi Lance, You're right. The original content for deprecation was a copy of that of Xerces, which is incorrect for the JDK. What would you think about the following: For DOMSerializerImpl, the main class of the LSSerializer implementation: @deprecated Replaced by {@link com.sun.org.apache.xm

Re: RFR (JAXP): 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer.

Hi Joe, For your deprecated methods, would it be reasonable to add an @see or @link to point to public apis that are the replacements? DOMSerializerImpl has the @deprecated after the @author which you did not do in the other classes. Would be nice if we can be consistent if at all possible L

Re: WAR == single classloader was: Benefits of activeReferenceQueue

On 07/29/2014 10:05 AM, Jaroslav Tulach wrote: Plus, because there is a single classloader which loads all the classes from a WAR, by keeping the activerReferenceQueue thread alive and holding reference to the queue, we hold reference to its class and the classloader and thus all classes referenc

Re: Why is finalize wrong? was: Benefits of activeReferenceQueue

Hi Jaroslav, On 29/07/2014 7:24 PM, Jaroslav Tulach wrote: Hello David, the following suggestions are hard to argue with as they touch philosophical aspects of software engineering. In spite of that I will attempt to analyze and argue: Always happy to get philosophical about software design :)

Re: Benefits of activeReferenceQueue

On 07/29/2014 11:06 AM, Jaroslav Tulach wrote: > >This is basically a re-implementation of ReferenceQueue.remove(int > >timeout) instance method in terms of a static method, which only briefly > >"touches" the queue instance wrapped in a Reference but majority of time > >it waits for notification

Why is finalize wrong? was: Benefits of activeReferenceQueue

Hello David, the following suggestions are hard to argue with as they touch philosophical aspects of software engineering. In spite of that I will attempt to analyze and argue: Dne Út 29. července 2014 18:16:24, David Holmes napsal(a): > I think the fundamental flaw of activeReferenceQueue is in

Re: Benefits of activeReferenceQueue

Dne Út 29. července 2014 18:16:24, David Holmes napsal(a): > Thanks for the detailed explanation. It is an interesting problem. Good. I am glad it attracted your attention. I am also glad Peter came with his static method... > On 29/07/2014 6:03 PM, Peter Levart wrote: > > On 07/29/2014 04:16 A

Re: Overhead of a new thread was: Benefits of activeReferenceQueue

On 07/29/2014 10:18 AM, Jaroslav Tulach wrote: Thanks Peter, I had a feeling that two threads might address the issue and your work indicates they really can. I am sort of worried about the overhead of a single thread (~1MB?), but certainly using two threads is better than having our curren

Overhead of a new thread was: Benefits of activeReferenceQueue

Thanks Peter, I had a feeling that two threads might address the issue and your work indicates they really can. I am sort of worried about the overhead of a single thread (~1MB?), but certainly using two threads is better than having our current reflection which works on JDK7, JDK8, but is br

Re: Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

Hi Peter, Thanks for the detailed explanation. It is an interesting problem. But at this stage my only conclusion is that we are nowhere near the point of deciding to add a new method to a public API. I think the fundamental flaw of activeReferenceQueue is in trying to hide the thread manage

Re: WAR == single classloader was: Benefits of activeReferenceQueue

Hi Jaroslav, Please don't keep creating new email threads as yu are making it very hard to track the discussion. On 29/07/2014 6:05 PM, Jaroslav Tulach wrote: Hello David. Dne Út 29. července 2014 12:16:33, David Holmes napsal(a): So ... activeReferenceQueue is a reference queue that embodi

WAR == single classloader was: Benefits of activeReferenceQueue

Hello David. Dne Út 29. července 2014 12:16:33, David Holmes napsal(a): > So ... activeReferenceQueue is a reference queue that embodies a thread > that does the polling and implements a psuedo-finalization mechanism. > This works fine in the normal case where the lifetime of the queue is > the li

Re: Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

On 07/29/2014 04:16 AM, David Holmes wrote: Hi Jaroslav, So ... activeReferenceQueue is a reference queue that embodies a thread that does the polling and implements a psuedo-finalization mechanism. This works fine in the normal case where the lifetime of the queue is the lifetime of the "ap