On 04/01/2015 20:29, Claes Redestad wrote:
For the record I would be very happy to update the implementation to use
System.lineSeparator() in PrintWriter/BufferedWriter rather than reading
line.separator, thus removing the unspecified behavior to be able to
hack the
current implementation via ma
This looks fine to me Peter. Thanks.
-Chris.
On 04/01/15 17:58, Peter Levart wrote:
Hi,
While investigating the following issue:
https://bugs.openjdk.java.net/browse/JDK-8029891
I noticed there's a bug in deserialization code of java.util.Hashtable
(from day one probably):
https:/
My mistake, thank you.
Peter.
On 5/01/2015 9:57 PM, David Holmes wrote:
Hi Peter,
Did you send this to the list? I haven't seen it turn up yet.
David
On 5/01/2015 6:51 PM, Peter Firmstone wrote:
Thanks Dave,
That's another way of checking invariants, you could expose A's check
method but y
Hi Peter and others,
A assume your approach described here (to use constructors for
deserialization) is motivated mainly by the fact that only constructors
are allowed to set the final fields. Otherwise the explicit features of
your ReadSerial API are more or less accessible even now by using
On 01/03/2015 09:36 AM, Peter Levart wrote:
On 01/03/2015 01:38 PM, Peter Firmstone wrote:
> Hi,
>
> I would like to know what are the potential issues with simple
> constructor chaining where each constructor checks the invariant of its
> class state (with the already initialized state of sup
On 01/03/2015 02:29 PM, Peter Firmstone wrote:
- Original message -
Wouldn't it be better to "register" for finalization just those instances that
complete their
construction or deserialization normally? I'm just trying to understand
why it is the way it is.
Perhaps that might be an o
On 04/01/15 18:58, Peter Levart wrote:
Hi,
While investigating the following issue:
https://bugs.openjdk.java.net/browse/JDK-8029891
I noticed there's a bug in deserialization code of java.util.Hashtable
(from day one probably):
https://bugs.openjdk.java.net/browse/JDK-8068427
The
On Dec 19, 2014, at 10:19 PM, Dan Smith wrote:
> I've submitted a couple of RFEs to support some simple optimizations on
> Streams. I noticed both issues while writing some code that forced me to
> choose between cluttering up my straightforward, uniform Stream logic and
> eating the cost of
On 01/05/2015 03:17 PM, David M. Lloyd wrote:
Would something like this prevent Finalizer attacks?
- leave finalization registration the way it is (at object allocation
time).
This was written incorrectly: "after Object default constructor completes"
- provide internal API with which a previ
Hi Ivan,
An enum for the OS is useful but as proposed is spread over too many
files and into the build system too.
The construct is not really a compile time constant since it is
initialized as part of a static initializer.
The initialization could just as easily be done in OS.java by checking
On 2015-01-05 10:51, Alan Bateman wrote:
On 04/01/2015 20:29, Claes Redestad wrote:
For the record I would be very happy to update the implementation to use
System.lineSeparator() in PrintWriter/BufferedWriter rather than reading
line.separator, thus removing the unspecified behavior to be able
Hi Ivan,
For this small difference in the implementations, I'd recommend against
having
two different source files. The path initialization function is a one
time function and
the performance improvement is not significant.
I'd suggest a few comments on your 2nd version[1].
- The windows c
On 04/01/2015 20:23, Ivan Gerasimov wrote:
Ah, I see.
Though, not needing to check for quotes allows a bit more efficient
implementation, so splitting the code for different platforms may also
make sense.
I did it with another helper class in this webrev:
http://cr.openjdk.java.net/~igerasim
On 01/05/2015 03:52 PM, Daniel Fuchs wrote:
On 04/01/15 18:58, Peter Levart wrote:
Hi,
While investigating the following issue:
https://bugs.openjdk.java.net/browse/JDK-8029891
I noticed there's a bug in deserialization code of java.util.Hashtable
(from day one probably):
https://b
On 05/01/2015 15:26, Claes Redestad wrote:
:
For printf/format/Formatter then having %n result in a call to
newLine() has some appeal. It's doable in Formatter but would require
a spec change.
If we do this (do we have to?), where do we expose the newLine?
Currently Appendable is the onl
Please review a typo in javadoc comment..
http://cr.openjdk.java.net/~sundar/8068279/ for
https://bugs.openjdk.java.net/browse/JDK-8068279
Thanks,
-Sundar
+1
On Jan 5, 2015, at 12:19 PM, A. Sundararajan
wrote:
>
>
>
> Forwarded Message
> Subject: RFR 8068279: (typo in the spec)
> javax.script.ScriptEngineFactory.getLanguageName
> Date: Mon, 05 Jan 2015 21:40:56 +0530
> From: A. Sundararajan
> To: core-libs-dev@openjd
On 05/01/2015 16:10, A. Sundararajan wrote:
Please review a typo in javadoc comment..
http://cr.openjdk.java.net/~sundar/8068279/ for
https://bugs.openjdk.java.net/browse/JDK-8068279
Looks okay to me.
-Alan
Well spotted Peter. The change looks good though I wonder if it should
be:
int length = (int)((elements + elements / 20) / loadFactor) + 3;
FYI, regarding Daniel's suggestion: When similar invariant checks were
added to the HashMap deserialization method we found code which relied
upon the il
On 05.01.2015 18:48, Alan Bateman wrote:
On 04/01/2015 20:23, Ivan Gerasimov wrote:
Ah, I see.
Though, not needing to check for quotes allows a bit more efficient
implementation, so splitting the code for different platforms may
also make sense.
I did it with another helper class in this w
Hi Roger!
I've updated the webrev similarly to what you've suggested:
1) Presence of quotes is checked when counting the separators.
2) If quotes weren't found, we'll execute the same optimized loop as for
Unix.
http://cr.openjdk.java.net/~igerasim/8067951/4/webrev/
Sincerely yours,
Ivan
On
Hi Ivan,
Looks pretty good.
Just a thought on ClassLoader:1754; If you avoid the local for
ClassLoaderHelper.allowsQuotedPathElements
then the compiler can optimize the code and may do dead code elimination
since it is a final static boolean.
On Mac and Unix it reduces to just the original c
Hi all,
Could I get a review for this? (Serves me right for posting this just before the
holidays.)
Turns out this is the root cause of some test failures.
Thanks,
s'marks
P.S. Happy new year, everyone!
On 12/23/14 5:24 PM, Stuart Marks wrote:
Hi all,
Please review this change, which add
On 05/01/2015 17:41, Ivan Gerasimov wrote:
:
Here's another update:
http://cr.openjdk.java.net/~igerasim/8067951/4/webrev/
The optimized loop is used both on Unix and on Windows, if there were
no quotes found in PATH.
Not a big deal, of course, but it should save a few nano-seconds
during st
Hi,
This discussion was a long time ago, I was just reading through it to check
again what was the last state of the discussion about the String.indexOf.
There is one part which I still do not understand, hopefully someone could
shed some light on it. A few emails ago Martin mentioned
"Hotspot se
Just wonder if we really need that "inQuotes" logic here? A straightforward
approach might
be "every time you have a quote, skip everything until you hit another one,
when counting,
or copy everything into the buffer until hit another one, when copying" ?
Since you are making copy (into the te
Hi Stuart,
Looks OK to me :-)
Best
Lance
On Jan 5, 2015, at 1:37 PM, Stuart Marks wrote:
> Hi all,
>
> Could I get a review for this? (Serves me right for posting this just before
> the holidays.)
>
> Turns out this is the root cause of some test failures.
>
> Thanks,
>
> s'marks
>
> P.S.
Evidence that hotspot tries to intrinsify String.indexOf:
do_intrinsic(_indexOf,
java_lang_String, indexOf_name, string_int_signature,
F_R) \
do_name( indexOf_name,"indexOf")
\
So
Thanks Sherman!
On 05.01.2015 22:10, Xueming Shen wrote:
Just wonder if we really need that "inQuotes" logic here? A
straightforward approach might
be "every time you have a quote, skip everything until you hit another
one, when counting,
or copy everything into the buffer until hit another
Thanks Peter(s): I think it's just about time to re-sync on the goals,
since there are an infinitude of issues with serialization, only some of
which we can address.
To that end, let me toss out some of the results of our recent
explorations with improving serialization, where we started out o
On 01/05/2015 12:41 PM, Ivan Gerasimov wrote:
Thanks Sherman!
On 05.01.2015 22:10, Xueming Shen wrote:
Just wonder if we really need that "inQuotes" logic here? A straightforward
approach might
be "every time you have a quote, skip everything until you hit another one,
when counting,
or copy
Yes, you're right, we can simply ignore the unpaired quotes.
I'll incorporate your suggestion, thanks!
Sincerely yours,
Ivan
On 06.01.2015 0:12, Xueming Shen wrote:
On 01/05/2015 12:41 PM, Ivan Gerasimov wrote:
Thanks Sherman!
On 05.01.2015 22:10, Xueming Shen wrote:
Just wonder if we reall
Hi,
Sharing in case you haven't seen it... Aleksey Shipilëv has a talk about
String optimizations, which discusses these questions and specifically the
Boyer-Moore algorithm.
http://shipilev.net/talks/joker-Oct2014-string-catechism.pdf
Page 85 talks about the intrinsification of indexOf and comp
Hi Brian,
The new version looks fine. One suggestion to consider: creating a small
private helper method to do the len, off, array-length check. (The two
copies of the logic are slightly different.)
Thanks,
-Joe
On 1/2/2015 4:09 PM, Brian Burkhalter wrote:
Hello all,
Thanks for the commen
Hi Joe,
The logic differs because one of the cases does not allow for zero length
whereas the other does.
Thanks,
Brian
On Jan 5, 2015, at 3:58 PM, Joseph D. Darcy wrote:
> The new version looks fine. One suggestion to consider: creating a small
> private helper method to do the len, off, a
> The default JTreg time out is 5 minutes...
I believe the default JTREG timeout is 120 seconds or 2 minutes.
Dan
On 12/17/14 6:11 AM, Yekaterina Kantserova wrote:
Hopefully the last version :)
Erik has recommended to skip the whole timeout concept. Instead the
test will loop until a decre
Hello,
Getting back to this issue in the new year, taking a closer look at the
existing class-level documentation, I don't really see a compelling case
for an edit this large.
I for one would be content if the bug were closed as "not an issue."
HTH,
-Joe
On 12/22/2014 10:46 AM, Brian Burkh
I personally have no objection but I cannot speak for the others who posted to
the discussion thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030376.html
Thanks,
Brian
On Jan 5, 2015, at 5:43 PM, Joseph D. Darcy wrote:
> Hello,
>
> Getting back to this issue in the
On 5/01/2015 6:51 PM, Peter Firmstone wrote:
Thanks Dave,
That's another way of checking invariants, you could expose A's check
method but you'd also need a couple of additional static methods to
obtain integers upper and lower from ReadSerial, so that B can ensure
its invariant.
Not sure I fo
Hi Brian,
On 01/05/2015 09:51 PM, Brian Goetz wrote:
Thanks Peter(s): I think it's just about time to re-sync on the goals,
since there are an infinitude of issues with serialization, only some
of which we can address.
To that end, let me toss out some of the results of our recent
exploratio
Please review http://cr.openjdk.java.net/~sundar/8068462/ for
https://bugs.openjdk.java.net/browse/JDK-8068462
Thanks,
-Sundar
41 matches
Mail list logo
