Given that this issue has existed (and been known) since 1.4, I doubt
anyone is particularly inclined to fix it. The most common workaround I
know of is to simply use or create a LogManager that implements reset()
as a no-op. Just subclassing the built-in LogManager is sufficient to
do this.
On 01/13/2014 06:26 PM, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/187
The concept of explicit deserialization constructors is interesting and
is something I've explored a little bit in the context of JBoss Marshalling.
The way construction works today (simple
Since the topic of serialization has come up recently, I'll take it as
an excuse to bring up a problem that I've run into a couple of times
with the serialization specification, which has resulted in user problems.
If you read section 2.3 [1] of the specification, it says:
The class's
Just want to say that we've also had the need to implement an
array-backed Deque+List; we found no surprises implementing it and thus
I believe that extending ArrayDeque to implement List would be a
positive change. Failing that, a combined ArrayListAndDeque class seems
like a good idea.
I
I think making the description contingent on a specific syntax might be
a mistake. I think that making required performance characteristics
(e.g. must be equivalent in performance to Unsafe counterparts) a part
of acceptance criteria is also something that should be done.
On 02/07/2014 12:36
ArrayList and ArrayDeque act as mutual views for each other, though I'd
hate to require the extra object when (as LinkedList shows) it is
conceptually OK to implement List and Deque.
If we have agreement, we can do the relatively easy implementation.
On Fri, Feb 7, 2014 at 10:07 AM, David M. Lloyd
of behavior.
-Chris.
On 07/02/14 15:07, David M. Lloyd wrote:
Since the topic of serialization has come up recently, I'll take it as
an excuse to bring up a problem that I've run into a couple of times
with the serialization specification, which has resulted in user
problems.
If you read section
:37, David M. Lloyd wrote:
I agree that it's a problem; however it's also clear that there are many
classes in the wild which have this problem. It would be nice if the
behavior could _become_ defined *somehow* though. I can see at least
four options:
1) do nothing :(
2) start throwing
On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd david.ll...@redhat.com
wrote:
That's a quote from the serialization spec. I take it to mean,
Don't write fields and everything might go to hell. In practice,
if the reading side doesn't read fields, things
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd david.ll...@redhat.com
wrote:
That's a quote from the serialization spec. I take it to mean,
Don't write fields and everything might go to hell. In practice
On 02/14/2014 09:56 AM, David M. Lloyd wrote:
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd david.ll...@redhat.com
wrote:
That's a quote from the serialization spec. I take it to mean,
Don't write fields
that the serialized form of java.util.Date is defined.
The behavior is defined by the writeObject and readObject methods.
They write and read a time computed from and restored to the state of
the object.
Roger
On 2/14/2014 10:56 AM, David M. Lloyd wrote:
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
On 02/13/2014
in undefined-land.
On 02/14/2014 12:01 PM, David M. Lloyd wrote:
Yes, however given that the lack of reading/writing fields makes it
undefined *in general*, you can only say the behavior is defined as
long as this undefined behavior is actually defined in this (risky)
manner.
Put another way
On 02/17/2014 01:17 AM, Stuart Marks wrote:
On 2/14/14 9:43 AM, David M. Lloyd wrote:
On 02/14/2014 09:56 AM, David M. Lloyd wrote:
In the JDK, java.util.Date does not read/write fields. Perhaps others
as well. Given that the behavior is presently undefined, that means the
serialized
On 02/17/2014 05:42 AM, Chris Hegarty wrote:
Let me try to summarize the issue, as I see it.
Circling back to David's original quote from the Serialization spec [1]
The class's writeObject method, if implemented, is responsible for
saving the state of the class. Either ObjectOutputStream's
This is actually a somewhat unfortunate feature. Had this not been in
place, I could have just used custom bytecodes to perform the lock magic
that I ended up using Unsafe for (I'm the guy that wrote JBoss Modules,
i.e. apparently the one usage in the wild of these methods).
The restriction
A Monitors class could possibly be introduced which simply has three
(intrinsic) static methods: void lock(Object obj), void unlock(Object
obj), boolean tryLock(Object obj).
Could even add a void lockInterruptibly(Object obj) throws
InterruptedException.
Why not? Monitors are not going
On 02/27/2014 11:36 AM, Paul Sandoz wrote:
Hi David,
On Feb 27, 2014, at 3:24 PM, David M. Lloyd david.ll...@redhat.com wrote:
(I'm the guy that wrote JBoss Modules, i.e. apparently the one usage in the
wild of these methods).
Yes :-) the only one i have found so far.
IIUC JBoss Modules
Making the language Kindergarten-friendly at the cost of general
usefulness is a mistake, IMO. And anyway there's nothing that is less
safe about a Monitors class than ReentrantLock; on the other hand,
monitors continue to be considerably lighter (size and (for most of the
history of JUC)
(tm) Specialists' Newsletter
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
David M. Lloyd wrote:
Making the language Kindergarten-friendly at the cost of general
usefulness is a mistake, IMO. And anyway there's
On 02/27/2014 06:38 AM, David Holmes wrote:
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote:
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging and monitoring -
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various pieces of this into the programming
model? This
On 03/03/2014 09:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might
On 03/03/2014 04:53 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various pieces of this into the programming
model? This
On 03/04/2014 03:16 PM, David M. Lloyd wrote:
On 03/03/2014 04:53 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions
On 03/05/2014 02:37 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various
On 03/06/2014 08:48 AM, Tom Hawtin wrote:
On 04/03/2014 15:32, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
We should not introduce anything that allows something that was
guaranteed to be safe by the language, to become unsafe.
Define 'safe'. Because I don't think
On 03/06/2014 09:25 AM, Florian Weimer wrote:
On 03/05/2014 01:05 AM, Doug Lea wrote:
On 03/04/2014 05:12 PM, Florian Weimer wrote:
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
I understand pass-by-reference is an expensive feature, but IMNSHO
On 03/13/2014 07:19 AM, Andrew Haley wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
Arrays.compareUnsigned.
An explosion of methods on Arrays for all types (plus to/from versions) would
be annoying.
Surely it's a
You could definitely safely do a check to see if elementData ==
EMPTY_ELEMENTDATA (irrespective of size), and if so, return
EMPTY_ELEMENTDATA instead of copying.
I don't think however that that method, as is, is actually unsafe. I
can't think of a code path where, say, a sudden concurrent
On 03/24/2014 04:11 PM, roger riggs wrote:
Hi,
I'm starting to work on JEP 102, Process API Updates for JDK 9.
The use cases identified include test execution and build systems such
as Jtreg and Hudson/Jenkins. And there is a use-case for using Java
to monitor the health of a more complex
On 04/01/2014 12:04 PM, Peter Levart wrote:
On 04/01/2014 05:43 PM, Peter Levart wrote:
On 04/01/2014 03:49 PM, roger riggs wrote:
Hi Peter,
The design using enum for the os dependencies does not make it possible
to include only the support needed for a particular platform at build
time.
Where does the requirement to manage grandchild processes actually come
from? I'd hate to see the ability to nicely terminate immediate child
processes lost just because it was difficult to implement some grander
scheme.
On 04/14/2014 08:49 AM, roger riggs wrote:
Hi Martin,
A new API is
On 04/14/2014 10:54 AM, Peter Levart wrote:
On 04/14/2014 03:50 PM, roger riggs wrote:
Hi Peter,
The new API to handle process trees and processes not spawned by the
Java process
also will need a way to wait for exit status and destroy children so
I'm not sure the
issue goes away. It too will
termination of any ancestor enumerated by the API
- (optionally: obtain a Process object of any live direct JVM child that
was spawned by Process API)
Regards, Peter
On 4/14/2014 10:31 AM, David M. Lloyd wrote:
Where does the requirement to manage grandchild processes actually
come from? I'd hate
On 04/16/2014 02:15 PM, Martin Buchholz wrote:
On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
There's already such a race in current implementation of
Process.terminate(). It admittedly only concerns a small window
between
On 04/16/2014 02:34 AM, Chris Hegarty wrote:
On 17/02/14 15:50, David M. Lloyd wrote:
...
Honestly I'm coming to the conclusion that the spec should just be
updated to match the existing behavior. At least this way, it is
possible to establish and explain exactly what is happening and why
, David M. Lloyd
david.ll...@redhat.com mailto:david.ll...@redhat.com wrote:
On 04/16/2014 02:15 PM, Martin Buchholz wrote:
On Mon, Apr 14, 2014 at 1:57 PM, Peter Levart
peter.lev...@gmail.com mailto:peter.lev...@gmail.com
mailto:peter.lev...@gmail.com
On 04/17/2014 02:58 PM, Peter Levart wrote:
On 04/17/2014 05:15 PM, David M. Lloyd wrote:
On 04/17/2014 09:43 AM, Peter Levart wrote:
On 04/17/2014 09:07 AM, Martin Buchholz wrote:
Many possible solutions eventually fail because whatever we do cannot
take ownership of any global resource
On 04/21/2014 04:51 PM, Richard Warburton wrote:
Hi Peter,
I'm suggesting this alternative, because Buffer methods can stay
final in this case. This is more JIT-friendly. And, if I'm not
mistaken, client code compiled using JDK8 onto which this API change
was backported, would
On 04/22/2014 04:17 AM, Peter Levart wrote:
On 04/22/2014 12:02 AM, David M. Lloyd wrote:
Um, do we *know* that there is a performance cost to covariantly
overriding these methods? There would seem to be enough information
to keep them monomorphic, if the optimizer is smart enough to inline
On 04/22/2014 08:24 AM, Paul Sandoz wrote:
On Apr 22, 2014, at 2:48 PM, David M. Lloyd david.ll...@redhat.com wrote:
If the methods were final, AFAICT it'd be more like this:
public final ByteBuffer position(int newPosition) {
// iirc super upcall is already bytecoded as invokespecial
On 04/22/2014 09:53 AM, Peter Levart wrote:
On 04/22/2014 02:48 PM, David M. Lloyd wrote:
On 04/22/2014 04:17 AM, Peter Levart wrote:
On 04/22/2014 12:02 AM, David M. Lloyd wrote:
Um, do we *know* that there is a performance cost to covariantly
overriding these methods? There would seem
On 05/22/2014 08:49 AM, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
Webrev:
On 05/22/2014 10:34 AM, David M. Lloyd wrote:
On 05/22/2014 08:49 AM, roger riggs wrote:
Hi,
The webrev has been updated to more completely describe the pid:
The native process id is an identification number that the operating
system assigns to the process.
Any other comments?
Webrev: http
On 05/22/2014 10:44 AM, Alan Bateman wrote:
On 22/05/2014 16:34, David M. Lloyd wrote:
I guess this is a little late, and minor, but the jstack tool uses
the acronym nid for this purpose, which I believe is mapped to the
same concept (on Linux it is anyway).
I think either this terminology
On 06/25/2014 04:52 PM, roger riggs wrote:
Hi,
The next step for JEP 102, Process API Updates is to provide an API to
enumerate the hierarchy of processes and to be able to terminate a
process tree.
This draft javadoc http://bussund0416/%7Erriggs/pdoc/update [1] includes:
- ProcessHandle
Just want to say that I am also looking forward to progress on this.
On 07/09/2014 12:25 AM, Jeremy Manson wrote:
Thanks for the response, Mandy. I'm looking forward to seeing the final
version.
For CallerFinder, we use reflective goop to get at
sun.misc.JavaLangAccess.getStackTraceElement.
On 07/18/2014 06:36 PM, Stuart Marks wrote:
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun weijun.w...@oracle.com wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) - A proposal.
Works whether A is
On 08/04/2014 06:27 AM, Florian Weimer wrote:
On 08/01/2014 06:39 AM, Jaroslav Tulach wrote:
Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a):
On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
Plus, because there is a single classloader which loads all the classes
from a WAR, by
On 08/04/2014 08:46 AM, Jaroslav Tulach wrote:
Hi.
Last week we touched topic of finalization and what is wrong with it. I
proposed three
reasons why Object.finalize is bad. Is it correct and extensive list or would
you change
it or expand it? Thanks as ...
# 1 - Because of automatic JDK
On 09/03/2014 06:48 AM, Stanimir Simeonoff wrote:
Hi Andrew,
On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley a...@redhat.com wrote:
On 03/09/14 01:15, Stanimir Simeonoff wrote:
Like David Lloyd mentioned finalize() can be invoked concurrently to
some methods (if there is no reachability to
On 10/10/2014 07:31 PM, Mandy Chung wrote:
On 10/10/2014 8:10 AM, Claes Redestad wrote:
Hi all,
please review this patch which attempts to clean up synchronization
and improve scalability when
defining and getting java.lang.Package objects.
I agree with David that getting Package objects
On 11/27/2012 05:56 AM, Stephen Colebourne wrote:
There is also no Javadoc on the default method override. In this case,
passing a null to either parameter will result in an NPE. This should
be documented.
More generally, you/Oracle should define a standard form of words for
describing what a
On 12/06/2012 05:35 AM, Alan Bateman wrote:
On 05/12/2012 11:59, David Holmes wrote:
Java 7 introduced support for parallel classloading by adding to each
class loader a ConcurrentHashMap, referenced through a new field,
parallelLockMap. This contains a mapping from class names to Objects
to
On 12/09/2012 10:03 PM, David Holmes wrote:
Hi David,
On 7/12/2012 1:06 AM, David M. Lloyd wrote:
On 12/06/2012 05:35 AM, Alan Bateman wrote:
On 05/12/2012 11:59, David Holmes wrote:
Java 7 introduced support for parallel classloading by adding to each
class loader a ConcurrentHashMap
On 12/10/2012 06:36 PM, David Holmes wrote:
On 10/12/2012 11:53 PM, David M. Lloyd wrote:
On 12/09/2012 10:03 PM, David Holmes wrote:
That sounds promising. Are you in a position to try out this proposal on
a testbed with your app server?
Sure, I'd love to. What tree should I build?
Please
On 12/11/2012 02:12 AM, Peter Levart wrote:
On 12/11/2012 04:41 AM, David M. Lloyd wrote:
On JDK 8 with your patches, we are loading around 4750 classes and
there are, as expected, 0 define races (I believe, however, that we're
getting a false count though whenever defineClass() returns
for trialling this so promptly!
Do you have any suggestions for what instrumentation you would like to
see accompany this?
David
On 11/12/2012 1:41 PM, David M. Lloyd wrote:
On 12/10/2012 06:36 PM, David Holmes wrote:
On 10/12/2012 11:53 PM, David M. Lloyd wrote:
On 12/09/2012 10:03 PM, David
On 12/20/2012 06:44 PM, David Holmes wrote:
On 21/12/2012 4:22 AM, Aleksey Shipilev wrote:
The astonishment comes from this:
a. racy Unsafe.putInt(...) to byte[] is atomic*
b. racy direct ByteBuffer.putInt(...) is atomic*
c. racy heap ByteBuffer.putInt(...) is NOT!
d. racy heap
Being a devil's advocate here, I'd like to point out that the particular
example given:
logger.log(level, () - String.format(...));
is better done through an API like this one:
logger.logf(level, fmt, ...);
which would in fact allow for the possibility of localization (using the
On 6/25/13 5:42 PM, Mandy Chung wrote:
On 6/25/13 3:04 PM, David Lloyd wrote:
We have a use case within our security manager implementation that
*can* be solved with the existing getClassContext method, which
returns the whole stack, except we don't *need* the whole stack, just
one specific
My mistake, we're not talking about strings. Still you can subclass and
determine whether the buffer size guess was right, and if so return the
array as-is (swap in an empty array or something as needed).
On 07/19/2013 01:28 PM, David M. Lloyd wrote:
It's trivial to subclass
On 07/19/2013 12:43 PM, Remi Forax wrote:
On 07/19/2013 07:15 PM, Ivan Gerasimov wrote:
Hello everybody!
Would you please review a fix for the problem with
j.n.f.Files.readAllBytes() function?
The current implementation relies on FileChannel.size() to preallocate
a buffer for the whole file's
On 07/22/2013 11:19 AM, Martin Buchholz wrote:
On Mon, Jul 22, 2013 at 9:03 AM, roger riggs roger.ri...@oracle.com wrote:
Hi Ivan,
I'm concerned about the change in behavior for the existing working cases.
How many times are the bytes copied in your proposed implementation?
How many arrays
On 07/22/2013 11:22 AM, Paul Benedict wrote:
I find this issue tangentially related to some open source logging
libraries. Some create a stack trace just so they can get the name of the
calling Class instance.
Example:
Logger log = Logger.createLogger(); // for the current class
Are there any
M. Lloyd wrote:
My mistake, we're not talking about strings. Still you can subclass
and determine whether the buffer size guess was right, and if so
return the array as-is (swap in an empty array or something as needed).
On 07/19/2013 01:28 PM, David M. Lloyd wrote:
It's trivial to subclass
On 07/23/2013 10:31 AM, Christos Zoulas wrote:
On Jul 22, 11:58am, marti...@google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR [8020669] java.nio.file.Files.readAllBytes() does not rea
| It's the OS/filesystem implementer deciding to return a bogus number.
|
| More accurate would be to
=8020669
http://bugs.sun.com/view_bug.do?bug_id=8014928
http://bugs.sun.com/view_bug.do?bug_id=8014928
Sincerely yours,
Ivan
On 23.07.2013 18:09, David M. Lloyd wrote:
Here's how it should behave:
- allocate 'size' byte byte array
- if size 0:
- use simple old I/O to read into the array
- do
://bugs.sun.com/view_bug.do?bug_id=8014928
Sincerely yours,
Ivan
On 23.07.2013 18:09, David M. Lloyd wrote:
Here's how it should behave:
- allocate 'size' byte byte array
- if size 0:
- use simple old I/O to read into the array
- do a one-byte
allocating a
new one every time.
Also, I don't see much difference between the original use (before the
Alan's previous change)
of Files.newInputStream(path) vs the compound try in readAllBytes().
That might also be reverted to its previous state as well.
Roger
On 7/24/2013 4:40 PM, David M. Lloyd
On 07/25/2013 12:27 PM, Nick Williams wrote:
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
, David M. Lloyd david.ll...@redhat.com wrote:
On 07/25/2013 12:27 PM, Nick Williams wrote:
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
On 07/26/2013 04:39 AM, Stephen Colebourne wrote:
Its websites and
browsers that define what should be accepted as HTML, not standards.
This is the craziest thing I've read all week.
--
- DML
On 07/26/2013 08:23 AM, Stephen Colebourne wrote:
On 26 July 2013 13:58, David M. Lloyd david.ll...@redhat.com wrote:
On 07/26/2013 04:39 AM, Stephen Colebourne wrote:
Its websites and
browsers that define what should be accepted as HTML, not standards.
This is the craziest thing I've read
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 getContext() method should be reevaluated a bit.
On
. If you
need a single frame, getCallerClass() is the only option that makes
any sense.
On Mon, Jul 29, 2013 at 8:21 AM, David M. Lloyd david.ll...@redhat.com wrote:
I find it very interesting that reflection is no less than two orders of
magnitude faster than the security manager solution. How big
don't want the start working on
something that the community is going to reject, especially having not received
any feedback on this API so far.
Nick
On Jul 29, 2013, at 4:59 PM, David M. Lloyd wrote:
I expect that at this stage, patches speak louder than words :)
On 07/29/2013 03:57 PM, Jörn
, David M. Lloyd wrote:
I don't see how Throwables could be deserialized with the proposed changes to
that class (Class.forName() only works when everything is visible from one
class loader - a trivial case which is rarely true in practice, especially in
an app server situation). I think you'd
On 07/29/2013 08:38 PM, Alan Bateman wrote:
On 29/07/2013 15:48, Paul Benedict wrote:
+1 with Nick. There's no point in submitting a patch unless someone
who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no
On 8/21/13 5:37 PM, Brian Burkhalter wrote:
With respect to this issue
http://bugs.sun.com/view_bug.do?bug_id=6470700
the code of concern from java.lang.Math is
701private static Random randomNumberGenerator;
702
703private static synchronized Random initRNG() {
704Random rnd
It's simple enough to just create an accessor object and add a security
check on creation. There does not need to be a significant jam-up over
this issue afaict.
On 09/03/2013 07:24 AM, Nick Williams wrote:
On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams
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 openly. I can get a Class object MANY different
ways without a security check. I don't see or understand any
On 09/03/2013 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
caller-sensitive. I keep seeing you suggest this and it is unclear
On 09/03/2013 01:11 PM, Peter Levart wrote:
On 09/03/2013 07:41 PM, David M. Lloyd wrote:
Now for that part, the public API equivalent
(StackTraceFrame.getCallerClass() or whatever it is called) need not be
restricted to methods annotated with any annotation, but that means that
this public API
On 09/04/2013 02:56 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset that will fix
8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship.
http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.00/
LogManager class initialization is
On 09/04/2013 06: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 7u25/8.
Class? getCallerClass(int):
On 09/05/2013 02:45 AM, Daniel Fuchs wrote:
Hi Mandy,
On 9/5/13 2:46 AM, Mandy Chung wrote:
On 9/4/2013 12:56 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset that will fix
8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship.
Another thing to consider is that there may be more modes than just
32/64 as time goes on (x32 on Intel springs to mind). Whether that's an
argument for keeping dual mode, or dropping it even faster, I'm not sure.
On 09/06/2013 12:20 PM, Martin Buchholz wrote:
Google is interested in using
On 09/08/2013 09:34 PM, Mandy Chung wrote:
On 9/4/2013 6:02 PM, David M. Lloyd wrote:
This seems reasonable on the surface but falls over once you capture
the caller for more than one purpose. For example, say a logging
framework captures the caller for the purpose of supplementing log
On 09/09/2013 04:56 PM, Mandy Chung wrote:
On 9/9/13 10:01 AM, David M. Lloyd wrote:
I'm not sure if we can be very certain about the depth in a runtime
environment (non-debugging) unless it requires all VM implementation to
support a reliable way to return a frame at a given depth.
The stack
On 09/10/2013 11:54 AM, Mandy Chung wrote:
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, mark.reinh...@oracle.com wrote:
:
Well, looking ahead to when the platform will be composed of modules,
those modules will declare that they export
On 09/10/2013 06:26 PM, Joseph Darcy wrote:
On 9/10/2013 10:08 AM, David M. Lloyd wrote:
On 09/10/2013 11:54 AM, Mandy Chung wrote:
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, mark.reinh...@oracle.com wrote:
:
Well, looking ahead
If that's the only consideration then just use 0x300 instead, which is
easier to read *and* makes more sense anyway, in the context of the test.
On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
Should we change conservative constant 1100 to optimal constant 768 ?
My opinion is no (in JDK7),
On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
*AND* that Reflection.getCallerClass() can only be called from within
methods annotated with @CallerSensitive.
Now for that part, the public API equivalent
(StackTraceFrame.getCallerClass() or whatever it is called) need not
be restricted to
On 09/19/2013 07:03 AM, Peter Levart wrote:
On 09/18/2013 05:21 PM, David M. Lloyd wrote:
On 09/03/2013 12:16 PM, Peter Levart wrote:
[...]
*AND* that Reflection.getCallerClass() can only be called from within
methods annotated with @CallerSensitive.
Now for that part, the public API
On 09/20/2013 10:45 AM, Peter Levart wrote:
On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
ListStackFrameInfo frames = new ArrayList();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the
On 10/03/2013 12:12 AM, David Holmes wrote:
On 3/10/2013 2:11 PM, Martin Buchholz wrote:
I was responding to Peter Levart's suggestion of checking for the
presence
of a security manager before calling doPrivileged. Which is not an
important question now, given that the primary question is
Anyone else beginning to get the sense that maybe some brainstorming for
a more sweeping/complete change to log manager initialization is
necessary? I suspect that these deadlocks and init order bugs are just
going to keep on coming, and every fix seems to add more complexity than
the last.
1 - 100 of 238 matches
Mail list logo
