Was there a use you had in mind, or some other reason you thought the spec
should be modified to accomodate it?
Such as improve serial form evolution flexibility, when someone's forgotten to
call defaultReadObject|WriteObject?
I'm not sure how that can be implemented though, requires further th
What happens, to answer your question, is the fields, if any, won't appear in
the stream where they are supposed to be.
Again this will affect evolvability of serial form. In other words, incorrect
implementations are locked into their current serial form. I don't think
that's something that
If an object defines readObject(), then it is responsible for reading fields.
So lets say for arguments sake that all fields are transient in the first
version of an Object and it doesn't call defaultReadObject or GetFields before
reading in block data.
If at some later time the developer defin
There is an typo in the javadoc,
* @throws IndexOutOfBoundsException if index %lt; 0 ||
* index >= getStackTraceDepth()
Maybe using {@code index < 0 || index > getStackTraceDepth()} would be
better here?
Gruss
Bernd
I think you didn't understand the issue being discussed - it's not about
fields that are added/removed, which is very clearly defined in the
spec. It's about what happens when you don't call
defaultRead|WriteFields, which is required by spec but not always done
in practice.
On 03/20/2015 10:
On 3/21/15 4:36 AM, Andrew Haley wrote:
On 20/03/15 22:00, Vladimir Kozlov wrote:
On 3/20/15 9:08 AM, Andrew Haley wrote:
Webrev at
http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider
it is set if VM_LITTLE_ENDIAN is no
If you say so, John, I am okay with BE.
Vladimir
On 3/20/15 10:21 PM, John Rose wrote:
I'm glad to see this coming along… The code, javadoc, and spec all look good.
On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov mailto:[email protected]>> wrote:
http://cr.openjdk.java.net/~aph/unali
On Mar 20, 2015, at 10:23 PM, Brent Christian
wrote:
> Here's the latest:
>
> http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/
>
> That should have everything.
>
Looks good (i assumed all but the test code has remained unchanged).
I like the test. A minor comment:
125 private s
On 20/03/15 22:00, Vladimir Kozlov wrote:
> On 3/20/15 9:08 AM, Andrew Haley wrote:
>> Webrev at
>>
>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
>
> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider
> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp co
There are other places which accept CharSequence and iterate over it
not caring about possible concurrent modification (the only sane way
IMHO). Examples are String.contentEquals and String.join that uses
StringJoiner which iterates its argument char by char.
It looks like contains is the exceptio
On 20/03/2015 21:33, Roger Riggs wrote:
Please review two javadoc updates to java.lang.ProcessBuilder.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-typo-8073220/
Issues:
8071480: (process spec) ProcessBuilder.start spec linked to the
wrong checkRead and checkWrite methods
8073220:
On 20/03/2015 21:32, Brian Burkhalter wrote:
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8075655
Patch: http://cr.openjdk.java.net/~bpb/8075655/webrev.00/
This looks okay to me, I think a left over that only surfaces when
needing to re-generate these te
12 matches
Mail list logo
