On Dec 2, 2013, at 1:47 PM, Xueming Shen wrote:
> On 12/01/2013 01:13 PM, Nick Williams wrote:
>> On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote:
>>
>>> On 12/1/13 10:29 AM, Nick Williams wrote:
>>>> I filed these bugs back in June. I noticed today that
On Dec 1, 2013, at 3:13 PM, Nick Williams wrote:
>
> On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote:
>
>> On 12/1/13 10:29 AM, Nick Williams wrote:
>>> I filed these bugs back in June. I noticed today that they were migrated to
>>> the JIRA instance:
>&
On Dec 1, 2013, at 12:52 PM, Xueming Shen wrote:
> On 12/1/13 10:29 AM, Nick Williams wrote:
>> I filed these bugs back in June. I noticed today that they were migrated to
>> the JIRA instance:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8016742
>> https:/
some light on 8016742's status and why the
heck 8016743 isn't getting fixed until Java 9?
If not, can someone point me to a more appropriate list that I can escalate my
frustrations on? These awesome new date & time types are useless if they aren't
supported in Java's i18n/
On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:
> On 9/18/2013 9:22 AM, Nick Williams wrote:
>> Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
>> await responses from Mandy.
>>
>> On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
>>
On Sep 18, 2013, at 11:28 AM, Mandy Chung wrote:
>
> On 9/18/2013 9:20 AM, Nick Williams wrote:
>> On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
>>
>>> >On 9/9/13 10:02 AM, David Chase wrote:
>>>> >>Take this lightly informed suggestion with a
On Sep 4, 2013, at 6:23 PM, Mandy Chung wrote:
> On 9/1/2013 1:16 AM, Nick Williams wrote:
>> Class getCallerClass(): Retrieves the class of the caller of the method
>> calling getCallerClass(). This is identical to the new
>> Reflection#getCallerClass() added in Java
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
> On 9/17/13 10:32 AM, cowwoc wrote:
>> Hi,
>>
>>Has this been any new progress on this thread?
>> http://mail.openjdk.java.net/pipermail/
ace() and multiple thread IDs version
>>>> (a) local (b) remote
>>>>
>>>> Since it's a new StackTraceFrame class, you have to provide a new method
>>>> replacing #1 and #2. I don't see any need to provide a new API equivalent
>>>
>> Since it's a new StackTraceFrame class, you have to provide a new method
>>>> replacing #1 and #2. I don't see any need to provide a new API equivalent
>>>> to Thread.getAllStackTraces() and java.lang.management.
>>>>
>>>>
On Sep 4, 2013, at 11:38 PM, Andrew Thompson wrote:
> Indeed if giving access to arbitrary Class is going to introduce such
> headaches as exposing sun.* and trying to support arbitrary class loaders
> then Ralph has the right point.
> It's also an example of the advantages or mirrors that Gil
ely. That gives me an
> impression that permission check on individual stack frame might be a
> non-issue?
I'm not sure exactly what you mean here, but okay. There are security
restrictions. So, you're probably right, we're bound to run into trouble
eventually. I'd like to eliminate that
Alright, I'm back! I'm sorry about my extended absence. I am over a month
behind on my book (as mentioned in an earlier email) and I have been heads-down
for a couple of weeks trying to get it finished. Still not finished yet, but I
know people here are awaiting my feedback. I have several email
On Sep 3, 2013, at 12:16 PM, Peter Levart wrote:
> On 09/03/2013 04:39 PM, Nick Williams wrote:
>>> >
>>> Do you mean sun.reflect.CallerSensitive can go away? This is very
>>> important part of the design that we need to detect which methods are
>>
On Sep 3, 2013, at 9:30 AM, Mandy Chung wrote:
>
> On 9/3/2013 5:52 AM, Nick Williams wrote:
>> Do, I don't understand the rationale. Alan said the security issues couldn't
>> be discussed openly. I can get a Class object MANY different ways without a
>&
On Sep 3, 2013, at 9:39 AM, Nick Williams wrote:
>
> On Sep 3, 2013, at 9:30 AM, Mandy Chung wrote:
>
>>
>> On 9/3/2013 5:52 AM, Nick Williams wrote:
>>> Do, I don't understand the rationale. Alan said the security issues
>>> couldn't b
On Sep 3, 2013, at 9:40 AM, David M. Lloyd wrote:
> On 09/03/2013 09:30 AM, Mandy Chung wrote:
>>
>> On 9/3/2013 5:52 AM, Nick Williams wrote:
>>> Do, I don't understand the rationale. Alan said the security issues
>>> couldn't be discussed open
er parameters.
Yep.
Nick
> Please correct/add if I miss anything.
>
> More will be discussed tomorrow.
>
> Mandy
> [1] http://openjdk.java.net/jeps/176
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019397.html
> [3] http://mail.openjdk.java.net/piper
On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
> On 02/09/2013 18:45, Nick Williams wrote:
>> :
>>
>> I didn't decide to ignore the security concerns, I just don't see any
>> security concerns. As has been /clearly/ established in the last three
On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote:
> It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So
> the suggestion to start out small was to leave that out and focus on some of
> the use-cases initially. I don't think this suggestion is unreasonable as it
> allows th
ail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019381.html
So David says he thinks he can find someone at RedHat to sponsor this, assuming
it looks good.
Nick
On Sep 1, 2013, at 12:13 PM, Alan Eliasen wrote:
> On 09/01/2013 09:50 AM, Nick Williams wrote:
>> Interesting. I
at 4:25 AM, Alan Bateman wrote:
> On 01/09/2013 09:16, Nick Williams wrote:
>> :
>>
>> I believe I have followed all of the procedures as closely as possible. I
>> await feedback and hope for some support on this, so that we can get a
>> public replacem
ally I'd like to establish the
> notion of either StackFrames or StackTraceFrames.
>
> I did a quick visual review and I didn't find anything horrific or
> questionable - which obviously wasn't a security audit, just a sanity check.
>
> And, yes, https
I have completed and am proposing a patch for replacing
sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw
no point in duplicating an issue, even though it's over 10 years old, so I'm
indicating that this is a patch for 4851444
(http://bugs.sun.com/bugdatabase/view_bu
On Aug 30, 2013, at 9:12 AM, Alan Bateman wrote:
> On 30/08/2013 15:01, Jörn Huxhorn wrote:
>> Has there been a decision about a replacement for Reflection.getCallerClass
>> in Java 8?
>>
>> The last info I know of is that it will be reactivated in j7u40 but will be
>> gone in j8.
>>
>> There
ds are, rather than referring the
> reader to the JLS without even a link. If you forget what the methods
> are you can always look in any enum, such as Thread.State
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.State.html>,
> but you shouldn't have to.
>
>
That method doesn't exist in the actual java.lang.Enum base class. It gets
generated automatically when the enum is compiled and is part of the compiled
enum class, not part of the Enum base class.
With that said, I don't disagree that it could use some documentation. I've
often wondered why ja
I have patch for a public API for this just about complete. I'm going to re-run
unit tests tonight and then submit it. But I need some help.
I quickly figured out that I can't just `hg diff` from the root directory,
because of the whole "forrest" thing. Ick.
So, is there a specific way that I n
gt; make
> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/
> *jdk_core*
>
> -Chris.
>
> On 31/07/2013 15:49, Nick Williams wrote:
>> That's how I'm running it.
>>
>> $ pwd
>> /foo/bar/jdk8/jdk8
>> $ cd
On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote:
> On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
>> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
>> estimate about the impact of this change.
>
> Eh, no. Try
> http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%
That is, indeed, great news!
I have almost completed a patch that I will propose later this week to make
this a public API.
Nick
On Jul 31, 2013, at 3:42 PM, mark.reinh...@oracle.com wrote:
> FYI, we're going to revert this method to its previous behavior in
> JDK 7u40: http://bugs.sun.com/vie
In native code (library_call.cpp), if I have an oop (which I can convert to a
jobject if need be), how do I get a ciObject? I see that ciEnv has a ciObject*
get_object(oop) method, but it's private. And ciObjectFactory has a ciObject*
get(oop) method, but I can't figure out how to get the ciObje
jdk/test/ProblemList.txt so that they are not run.
>
> There is general work underway to improve/simplify the Makefile support for
> jtreg, that should address this problem.
>
> -- Jon
>
> On 07/31/2013 07:49 AM, Nick Williams wrote:
>> That's how I'm runni
n the work into
>> separate jtreg runs on separate parts of the test suite.
>>
>> -- Jon
>>
>>
>> On 07/30/2013 01:13 PM, Nick Williams wrote:
>>> Okay, this is indeed very interesting. After two hours it was only
>>> about half-way through the
ome
> infrastructure-inserted frames are hidden-away just for @CallerSensitive
> methods which might be less optimal and not needed for normal methods.
>
>
> Regards, Peter
>
> On 07/31/2013 01:11 AM, Nick Williams wrote:
>> Quick question for those of you that
Quick question for those of you that know anything about @CallerSensitive...
After looking at the code and experimenting some, I've discovered that
getCallerClass() doesn't actually keep going until it finds the first method
without @CallerSensitive. It only returns the caller of the caller. So,
error". If you're driving the tests through
> the makefiles, the makefiles may partition the work into separate jtreg runs
> on separate parts of the test suite.
>
> -- Jon
>
>
> On 07/30/2013 01:13 PM, Nick Williams wrote:
>> Okay, this is indeed very interest
ame();
>} catch (UnknownHostException e) {
>hostname = "unknown";
> }
>
>
>
> On 07/30/2013 01:50 PM, Nick Williams wrote:
>> Gotchya.
>>
>> I commented out the java.io tests locally for now.
>>
>> By the way, I noticed s
aught from test
java/io/BufferedReader/Lines.java: java.lang.NullPointerException
On Jul 30, 2013, at 1:39 PM, Nick Williams wrote:
>
> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>
>>
>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>>
>>>
On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
>
> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
>
>> On 30/07/2013 11:02, Nick Williams wrote:
>>> I'm running the core libs tests locally (for the first time), and every
>>> java.io test is fai
On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
> On 30/07/2013 11:02, Nick Williams wrote:
>> I'm running the core libs tests locally (for the first time), and every
>> java.io test is failing. They're all failing for the same reason (output
>> below), and I s
I'm running the core libs tests locally (for the first time), and every java.io
test is failing. They're all failing for the same reason (output below), and I
suspect it's something local and not an actual problem. But the test output is
not very helpful. Note that all of the java.beans tests pa
I'm working on a patch for some core libraries (hence why I'm emailing here --
hopefully someone will be sympathetic and help) and need to run the JDK tests.
I'm following the instructions on http://openjdk.java.net/jtreg/build.html to
get jtreg installed so that I can run it. I have JDK15HOME a
annotated @CallerSensitive. In these cases, use of any new public
>> API must use reflection (sudo code: If Java 8, use new public
>> caller-sensitive API), so it needs code that it can pass a number into.
>>
>> Nick
>>
>> On Jul 30, 2013, at 7:17 AM, Peter Lev
that it can pass a number into.
Nick
On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:
>
> On 07/27/2013 09:01 PM, Nick Williams wrote:
>> All,
>>
>> In the last two months, there have been a number of discussions surrounding
>> stack traces, Classes on the stac
tform as a whole and reaffirm the
> "Java is slow" mantra. If keeping the "but this wasn't part of the public API
> so we did nothing wrong" stance is worth all of this then feel free to just
> ignore our objections.
>
> Seriously, I fail to understand ho
On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:
>
> On 7/29/2013 9:31 PM, Alan Bateman wrote:
>> On 29/07/2013 19:17, David M. Lloyd wrote:
>>>
>>> Your phrasing makes me think I missed something: is the
>>> Reflection.getCallerClass() method being removed due to some technical
>>> issue th
At the very least though, generalizing access to the classes on the call
> stack would have a lot of uses. We know that it is possible to access the
> call stack, given that there are at least two places which do it, so maybe it
> makes sense to build from there.
>
> On 07/2
method -
>> if a timely fix will exist at all at that point. Throwing
>> UnsupportedOperationException all of a sudden isn't exactly the most subtle
>> way of handling this.
>>
>> And please don't argue that everyone should just add that runtime property.
&g
>> I find it very interesting that reflection is no less than two orders of
>> magnitude faster than the security manager solution. How big was the stack
>> in these tests? It makes me wonder if maybe the implementation of the
>> security manager's getContex
or Java 8 not to have an equivalent
replacement for getCallerClass().
Nick
On Jul 27, 2013, at 2:01 PM, Nick Williams wrote:
> All,
>
> In the last two months, there have been a number of discussions surrounding
> stack traces, Classes on the stack trace, and caller classes [1], [2], [3
All,
In the last two months, there have been a number of discussions surrounding
stack traces, Classes on the stack trace, and caller classes [1], [2], [3].
These are all related discussions and the solution to them is equally related,
so I wanted to consolidate it all into this one discussion
On Jul 26, 2013, at 10:27 AM, Stephen Colebourne wrote:
> On 26 July 2013 14:49, David M. Lloyd wrote:
>> You took one step outside of logic, in my opinion. Yes, the spec is a
>> guide, in practice. But to use that to justify not even trying to conform
>> or not encouraging people to conform i
On Jul 25, 2013, at 7:16 PM, Jonathan Gibbons wrote:
> On 07/25/2013 02:01 PM, Nick Williams wrote:
>> Okay. To address some of your points (not in order):
>>
>> - I do not interpret "no end tags" as a strict prohibition on self-closing
>> elements. I thi
also like to see javadoc more forgiving in
> its input while still generating conformant output. Yes, that might mean
> fixing
> up minor transgressions. But not today.
>
> -- Jon
>
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019262.html
>
tp://w3c.org>W3C|. In such cases, the solution is to
>>put quotation marks around the value.
>>
>
> -- Jon
>
>
>
> On 07/25/2013 11:14 AM, Alan Bateman wrote:
>> Re: Invalid "self-closing element not allowed" JavaDoc error.eml
>>
>>
Correction: I see now that we're using Frameset doctype for the parent page and
Transitional for the pages within frames. I misunderstood that. My bad.
On Jul 25, 2013, at 3:19 PM, Nick Williams wrote:
> Point of interest: JavaDoc uses the HTML 4 "Loose" specification, not the
; people actually *do*.
>>
>> There is no doubt in my mind that br space slash is very common
>> indeed. Its certainly my default. The javadoc validator should be as
>> lenient as browsers are in this case.
>>
>> Stephen
>>
>>
>> On 25
My apologies if this is not the right place to address this. If so, please
forgive and direct me to the correct list.
There are a lot of people/projects complaining about Java 8's new "self-closing
element not allowed" error when compiling JavaDoc that has legal tags in
it (just google "self-c
"This bug is not available."
On Jul 19, 2013, at 8:41 PM, Mandy Chung wrote:
> Peter,
>
> FYI. I have filed this RFE:
> 8020968: Load resource files using the caller's class and class loader
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020968
>
> Mandy
>
> On 6/25/2013 6:50 PM, P
On Jun 24, 2013, at 10:14 AM, Stephen Colebourne wrote:
> One point lambdaification that I haven't seen mentioned is addition
> static factory methods for the main collection interfaces. (Strictly,
> this proposal is not point lambdaification as it does not involve
> lambdas, but it is very much
Indeed. Thanks!
On Jul 1, 2013, at 1:11 AM, Alan Bateman wrote:
> On 30/06/2013 22:26, Nick Williams wrote:
>> In java.sql.DatabaseMetaData, the Javadoc for supportsResultSetHoldability
>> fails to properly close a tag, and so everything following that
>> method is mon
In java.sql.DatabaseMetaData, the Javadoc for supportsResultSetHoldability
fails to properly close a tag, and so everything following that method
is monospace. To be precise:
ResultSet.CLOSE_CURSORS_AT_COMMIT
However, it should be:
ResultSet.CLOSE_CURSORS_AT_COMMIT
Nick
On Jun 25, 2013, at 5:50 AM, Peter Levart wrote:
> Hi,
>
> I know that @CallerSensitive annotation was introduced to bring some order to
> JDK internal plumbings. It's scope was to support JDK internal usage, so it's
> use is limited to classes loaded by bootstrap or extension class-loaders. I
On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote:
> On 17 June 2013 12:40, Alan Bateman wrote:
>> On 17/06/2013 11:05, Nick Williams wrote:
>>>
>>> Thanks. I have filed two different bugs for these two different problems.
>>
>> Here they are:
>&
not JSR-310.
>
> Stephen
>
>
> On 17 June 2013 09:40, Nick Williams
> wrote:
>>
>> On Jun 15, 2013, at 1:34 PM, Nick Williams wrote:
>>
>>> Currently, MessageFormat /only/ supports SimpleDateFormat and instances of
>>> java.util.Date or j
On Jun 15, 2013, at 1:34 PM, Nick Williams wrote:
> Currently, MessageFormat /only/ supports SimpleDateFormat and instances of
> java.util.Date or java.util.Calendar for date/time values. Because of this,
> it's impossible to use Java 8 date/time types with any of the i18n and
On Jun 17, 2013, at 1:55 AM, Peter Levart wrote:
> On 06/15/2013 09:59 PM, Nick Williams wrote:
>> On Jun 15, 2013, at 2:22 PM, Remi Forax wrote:
>>
>>> Could you be a little more clear why you need a class for your logging API,
>>> exactly, why the class name
On Jun 17, 2013, at 1:12 AM, Peter Levart wrote:
> On 06/17/2013 08:06 AM, Jeroen Frijters wrote:
>> Nick Williams wrote:
>>> What if we also added a getStackFrames() method to Throwable? That would
>>> meet my needs but it would also satisfy what I'm observing i
On Jun 16, 2013, at 9:29 AM, Nick Williams wrote:
>
> On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:
>
>> Nick Williams wrote:
>>> I'm going to stick by my original assessment that I'm not convinced
>>> there's a security issue. It's po
On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:
> Nick Williams wrote:
>> I'm going to stick by my original assessment that I'm not convinced
>> there's a security issue. It's possible that getClassContext() filters
>> out classes the caller can&#
On Jun 15, 2013, at 5:05 PM, Peter Levart wrote:
>
> On 06/15/2013 11:06 PM, Nick Williams wrote:
>> B) A Class loaded by a child class loader obtains a StackTraceElement
>> containing Classes loaded by a sibling class loader. This would obviously be
>> the more danger
On Jun 15, 2013, at 3:21 PM, Alan Bateman wrote:
> On 15/06/2013 19:33, Nick Williams wrote:
>> :
>>
>> Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls
>> JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find
>
On Jun 15, 2013, at 2:22 PM, Remi Forax wrote:
> On 06/15/2013 08:33 PM, Nick Williams wrote:
>> Bug 4851444 [1] was filed just over 10 years ago and has languished without
>> so much as a comment ever since. I hate to revive something so old, but I'd
>> like t
One of the many reasons for JSR-308 type annotations (as I understand it) was
to improve support for static code analyzers. The additional places that
annotations can be placed now allows static code analyzers to more accurately
assess code for potential bugs, such as NPEs.
However, the various
Currently, MessageFormat /only/ supports SimpleDateFormat and instances of
java.util.Date or java.util.Calendar for date/time values. Because of this,
it's impossible to use Java 8 date/time types with any of the i18n and
localization tools.
MessageFormat really needs support for types in java.
Bug 4851444 [1] was filed just over 10 years ago and has languished without so
much as a comment ever since. I hate to revive something so old, but I'd like
to see what everyone thinks.
I'm working on the Apache project Log4j2. Our problem is we need to get the
Class object that belongs to a pa
77 matches
Mail list logo
