On 10/4/18 2:31 PM, Magnus Ihse Bursie wrote:>> 4 okt. 2018 kl. 10:57
skrev Martijn Verburg :
I like this initiative. I'm wondering if some of these rules can be easily
codified or written into a jcheck style checker (ccheck?) so that Authors
can adhere to the conventions and not rely on a Human
Hi Kim,
> for XLC 16. Any information about "some C++14 features"? I haven't
> found any detail on that.
we will user our internal connections to IBM to find out :)
Best regards,
Goetz.
> -Original Message-
> From: Kim Barrett
> Sent: Donnerstag, 4. Oktober 2018 23:01
> To: Lindenma
Why does that actually throw an Exception on Linux/Unix, it is a perfectly
legal file name.
Gruss
Bernd
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: -2122936656m Auftrag von
Gesendet: Freitag, Oktober 5, 2018 11:00 AM
An: core-libs-dev@openjdk.java.net
Betreff
Hello Bernd,
On 05/10/18 2:51 PM, Bernd Eckenfels wrote:
> Why does that actually throw an Exception on Linux/Unix, it is a
> perfectly legal file name.
In the context of my test and the issue reported in Apache Ant, it fails
on Linux/Unix because there isn't actually a file present at that path.
On 04/10/2018 10:36, Jaikiran Pai wrote:
:
The javadoc of JarFile constructor(s) mentions that:
* @throws IOException if an I/O error has occurred
Given that the javadoc doesn't mention anything about this other
exception, would this throwing of java.nio.file.InvalidPathException be
con
Hello Alan,
On 05/10/18 4:15 PM, Alan Bateman wrote:
> On 04/10/2018 10:36, Jaikiran Pai wrote:
>> :
>>
>>
>> The javadoc of JarFile constructor(s) mentions that:
>>
>> * @throws IOException if an I/O error has occurred
>>
>> Given that the javadoc doesn't mention anything about this other
On 05/10/18 11:45, Alan Bateman wrote:
On 04/10/2018 10:36, Jaikiran Pai wrote:
:
The javadoc of JarFile constructor(s) mentions that:
* @throws IOException if an I/O error has occurred
Given that the javadoc doesn't mention anything about this other
exception, would this throwing of j
> I don't have access to create an issue for this in OpenJDK JIRA, so I'll
> go ahead and create one at bugs.java.com.
>
I just submitted the report. Internal review id 9057522 has been
assigned to the issue.
-Jaikiran
Hi Alan,
I second that the Unsafe::defineClass method should be removed at some
point. I'd very much prefer using a stable API over following up changes on
internal API.
However, for Java agents, there is still no good way to define auxiliary
classes. There is an open ticket on
https://bugs.openj
> On 5 Oct 2018, at 12:08, Jaikiran Pai wrote:
>
>> I don't have access to create an issue for this in OpenJDK JIRA, so I'll
>> go ahead and create one at bugs.java.com.
>>
> I just submitted the report. Internal review id 9057522 has been
> assigned to the issue.
And now in the JDK project:
On 05/10/2018 13:17, Rafael Winterhalter wrote:
:
However, for Java agents, there is still no good way to define
auxiliary classes. There is an open ticket on
https://bugs.openjdk.java.net/browse/JDK-8201784 and I have described
my concerns with the suggested API in the linked discussion as b
On 05/10/2018 12:06, Chris Hegarty wrote:
Given the stacktrace, from a previous email in this thread,
does it make more sense to wrap the IPE in an IOException,
rather then declaring that the ZipFile constructor can throw
IPE?
Right, there's no suggestion in this thread to change the spec, it's
> On 5 Oct 2018, at 14:58, Alan Bateman wrote:
>
>> On 05/10/2018 12:06, Chris Hegarty wrote:
>>
>> Given the stacktrace, from a previous email in this thread,
>> does it make more sense to wrap the IPE in an IOException,
>> rather then declaring that the ZipFile constructor can throw
>> IPE?
Hi,
Both StringBuilder and StringBuffer have two constructors:
1. StringBuilder(int capacity) - Constructs a string builder with no
characters in it and an initial capacity specified by the capacity argument.
2. StringBuilder(String str) - Constructs a string builder initialized to
the contents of
Thank you Chris.
I've attached a patch here which catches the InvalidPathException within
the implementation of ZipFile and wraps and throws a IOException. It's
the same patch which I mentioned earlier in this thread, but now also
includes jtreg testcase to reproduce the issue and verify the fix.
Thanks to Martin's hint, I revised the test to use UTF-8 consistently
and not utf.
Philipp
On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote:
> "utf8" is a thing. "utf" is not.
>
> On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz h> wrote:
> > Thanks to Sherman's hint, I revised the test
Hi Alan,
yes, I remember the discussion well. Unfortunately, I did not get the
impression that my argument was heard or even considered. I mentioned the
possible positive effects to mocking in Mockito as a supportive argument
but not at all as my main point. From my experience of implementing a go
Hi Jaikiran,
"wrap to throw a IOE" appears good. I will sponsor this patch.
Thanks!
-Sherman
On 10/5/18, 8:31 AM, Jaikiran Pai wrote:
Thank you Chris.
I've attached a patch here which catches the InvalidPathException within
the implementation of ZipFile and wraps and throws a IOException. It'
Hi
Please help review the change for JDK-8211728
issue: https://bugs.openjdk.java.net/browse/JDK-8211728
webrev: http://cr.openjdk.java.net/~sherman/8211728/webrev
The "intention" of JEP 238 is that the resources under META-INF
can't/shouldn't
be versioned. But it appears this is not documente
Hi Sherman,
The change looks OK
Best
Lance
> On Oct 5, 2018, at 12:48 PM, Xueming Shen wrote:
>
> Hi
>
> Please help review the change for JDK-8211728
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8211728
> webrev: http://cr.openjdk.java.net/~sherman/8211728/webrev
>
> The "intention"
Thank you Sherman.
-Jaikiran
On 05/10/18 9:59 PM, Xueming Shen wrote:
> Hi Jaikiran,
>
> "wrap to throw a IOE" appears good. I will sponsor this patch.
>
> Thanks!
> -Sherman
>
> On 10/5/18, 8:31 AM, Jaikiran Pai wrote:
>> Thank you Chris.
>>
>> I've attached a patch here which catches the Inval
21 matches
Mail list logo
