Hi Lance,
thanks for the detailed explanation, sounds great. I’ll work that in in my next
edition 😊
Best regards
Christoph
From: Lance Andersen
Sent: Mittwoch, 13. Februar 2019 23:53
To: Langer, Christoph
Cc: Alan Bateman ; nio-dev ;
Java Core Libs ; OpenJDK Dev list
; Volker Simonis
Subj
On 2/13/19 7:22 PM, Alan Snyder wrote:
If we take this route, how about changing the parameter type to Iterable?
Won't work. Where I've ended up is that we need to iterate over "this"
collection and, for each element, call contains() on the parameter. The
AbstractCollection.removeAll() implem
If we take this route, how about changing the parameter type to Iterable?
Alan
> On Feb 13, 2019, at 7:12 PM, Stuart Marks wrote:
>
> Right, as I mentioned in my earlier emails [1][2] this is related to
> JDK-6394757 [3] where the semantics shift depending on the relative sizes of
> the c
Right, as I mentioned in my earlier emails [1][2] this is related to JDK-6394757
[3] where the semantics shift depending on the relative sizes of the
collections. This has a complicated history. In JDK-6982173 [4] there is a lot
of discussion about what heuristics to use for iterating this vs th
On 2/8/19 5:13 AM, Tagir Valeev wrote:
I would argue that iterating the argument and calling remove() on "this" are the
right semantics, because you want set membership to be determined by this set,
not by whatever collection you pass as an argument. However, I note that
AbstractCollection.rem
Hi Christoph
> On Feb 13, 2019, at 5:30 PM, Langer, Christoph
> wrote:
>
> Hi Lance,
>
> thanks for looking.
>
>> Just starting to take a peek at this and noticed one quick thing in your
>> test:
>>
>> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
>> ——
>>
Hi Lance,
thanks for looking.
> Just starting to take a peek at this and noticed one quick thing in your test:
>
> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
> ——
>
> You do not need the test.dir property or the permission added to test.policy
> to access i
Hi Alan,
thanks for taking a first look into this new edition.
> I think the javadoc changes will need a few iterations but we can get to
> that once some of the finer details are sorted out. For example, "Posix
> Support" isn't quite right as this is about optional support for the
> POSIX view o
Hi Christoph,
Just starting to take a peek at this and noticed one quick thing in your test:
Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
——
You do not need the test.dir property or the permission added to test.policy
to access it, just reference the jar a
On 2/13/19, 11:55 AM, Lance Andersen wrote:
Hi Joe
Overall the change seems Ok, assuming all the tests are happy :-)
Yes, they all are happy.
One minor suggestion for:
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java
- line 150, plea
Hi Ivan,
The release note looks fine, Resolve -> FixDelivered to pass it on to
the tech writer for review.
Yes, communication is sometimes the hard part.
Thanks, Roger
On 02/12/2019 08:21 PM, Ivan Gerasimov wrote:
Uh, lots of paperwork, comparing to the actual change in the source
code :-
Hi Joe
Overall the change seems Ok, assuming all the tests are happy :-)
One minor suggestion for:
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java
- line 150, please put the ‘*/“ on its own line
> On Feb 13, 2019, at 1:15 PM, Joe Wang wro
Please review a cleanup patch for the OutputPropertiesFactory.
The original intention was to remove the (awkward) JDK 1.2-related code,
line 235-258 in the old file. I then went a bit further to remove
another nuisance that annoyed users with an error "Could not load the
property file 'output
I have to say that the example NPE messages this patch has
are like stuffing as much relevant information in the message
but they are not developer-friendly as Roger and David has
commented. Exposing bytecode-level details is very confusing
to Joe's developer while, from your perspective, anythin
Hi,
Please review the webrev[1] for 8217216. The fix makes sure on Solaris, when
LD_LIBRARY_PATH_64 is set, we setup LD_LIBRARY_PATH based on that value and
unset LD_LIBRARY_PATH_64 in the relaunched process.
Same approach was used before JDK-6367077, and the override is expected
behavior on S
Sorry, Roger, I must have messed up the bug id when pushing. Thank you for
fixing!
This would be a good thing to have a jcheck for.
..Thomas
On Wed, Feb 13, 2019 at 4:56 PM Roger Riggs wrote:
> Hi Thomas,
>
> This is a change that should have a release note, can you fill it in:
> https://bugs
Hi Thomas,
This is a change that should have a release note, can you fill it in:
https://bugs.openjdk.java.net/browse/JDK-8218924
Also, I had to do some manual updates to the issues to get the changeset
into the history.
The issue number should have been 8213192 in the summary lineand on the
e
On 12/02/2019 21:57, Langer, Christoph wrote:
Hi Alan, all,
here comes the next proposal for POSIX support in jdk.zipfs - which hopefully
represents the converged solution, at least in its overall design.
I don't have time to do a detailed code review right now but I did read
the updated propo
Hi Bernd,
I think this is a feasible idea, while I'm not sure whether
this is really critical information.
The stack trace already contains the names of Classes,
Inner classes etc.. Field names should be not that more
sensible information I guess, if at all.
> but maybe as a default?
You mean
Hi Mandy,
Thanks for supporting my intend of adding the message as such!
I'll start implementing this in Java and come back with a webrev
in a while.
In parallel, I would like to continue discussing the other
topics, e.g., the wording of the message. I will probably come up
with a separate we
20 matches
Mail list logo
