Hi Mandy,
I like the API shape and this capability is very much needed. Thanks!
It does bring something related to mind and that is that the current Java
ecosystem is already very dependent on accurate stack frames (i.e. not removing
them when inlining) and with this API this will probably only
Hi Sherman,
As a (minor) data point, IKVM.NET has been using a pure Java ZipFile
implementation since day one (based on the GNU Classpath version) and other
than a few compat bugs in the early days people have never complained about it.
For obvious reasons, I'd certainly prefer the pure Java ve
David Holmes wrote:
> But if the JVM acts upon annotations to change how it executes those
> bytecodes then, as Peter said, the JVM is implementing the language
> semantics.
The JVM synthesizes a native method, this has *nothing* to do with language
semantics. From the language point of view, nat
> -Original Message-
> From: Peter Levart [mailto:peter.lev...@gmail.com]
> Sent: Wednesday, March 5, 2014 18:07
> To: Jeroen Frijters; Brian Goetz; core-libs-dev@openjdk.java.net; Doug
> Lea
> Subject: Re: JEP 193: Enhanced Volatiles
>
>
> On 03/05/2014 05:5
Brian Goetz wrote:
> I'm all for unintrusive. Though note that the intrusiveness metric on
> language features I(f) is not uniform across observers :)
Indeed :-)
> > Here's my straw man
> > proposal:
> >
> > Add an annotation that can be placed on native methods to synthesize
> > atomic accessor
--Original Message-
> From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
> On Behalf Of Paul Benedict
> Sent: Wednesday, March 5, 2014 16:19
> To: Christoph Engelbert
> Cc: Jeroen Frijters; core-libs-dev@openjdk.java.net
> Subject: Re: JEP 193: Enhanced Volatiles
Brian Goetz wrote:
> Right now, the semantics of method calls in Java are simple --
> everything (primitives, object references) is passed by value. Adding
> pass-by-reference would add significant complexity. And method calls
> are not a niche feature; that added complexity will be borne by ever
Brian Goetz wrote:
> Embedded in this proposal is the desire to not provide a full-blown
> "lvalue" form for variables; supporting any form of pass-by-reference at
> the language level is a super-non-goal here.
Why is this? It solves these problems in an extremely clean way and also
provides lots
David Holmes wrote:
> I don't think this is workable. Exposing a monitor as Lock would allow
> you to break the guarantees/requirements involving balanced-locking for
> monitors.
Where are these guarantees/requirements documented?
Regards,
Jeroen
System.out can be null, because System.setOut(null) is legal.
Regards,
Jeroen
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Thursday, December 19, 2013 11:14
> To: Alan Bateman
> Cc: Jeroen Frijters; core-libs-dev@openjdk.java.net
> Subject: Re: Request: Remove S
Hi,
I'd like to propose to change Class.checkInitted() to check if the VM
initialization has completed by using sun.misc.VM.isBooted() instead of
System.out != null.
The current check needlessly triggers System class initialization (thus
complicating bootstrap initialization order on VMs that
John Rose wrote:
> I think the next interesting version of String will mix header and body
> together in a hybrid layout, with private char (or byte) elements and a
> few instance variables at the beginning of the layout.
It would be good to prepare for this by modifying the JNI spec to explicitly
Hi Mandy (and Mark),
The getter can be optimized away, the static field can't, so this is probably a
tiny bit more expensive.
Regards,
Jeroen
> -Original Message-
> From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
> boun...@openjdk.java.net] On Behalf Of Mandy Chung
>
Hi Mandy,
Thank you. Patch looks good.
Regards,
Jeroen
> -Original Message-
> From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
> boun...@openjdk.java.net] On Behalf Of Mandy Chung
> Sent: Friday, November 1, 2013 19:16
> To: core-libs-dev@openjdk.java.net
> Subject: JD
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 is a desire
> to have a new API for this (StackFrame) instead of adding it to
> StackTraceElement. I'm very open to how it's implemented, as l
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't access, but nothing in the documentation
> indicates that's the case, so I'm operating under the assumpt
jdk.java.net
> Subject: Re: Time to put a stop to Thread.stop?
>
> On 05/14/2013 04:45 PM, Jeroen Frijters wrote:
> > IMO Thread.currentThread().stop(new Throwable()) should continue to
> work. It is not unsafe and it is probably used in a lot of code to
> workaround the madness
IMO Thread.currentThread().stop(new Throwable()) should continue to work. It is
not unsafe and it is probably used in a lot of code to workaround the madness
that is checked exceptions.
> -Original Message-
> From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
> boun...@o
John Rose wrote:
> Making Runtime and/or Runtime.load* final is an API change, which is
> harder to do than an implementation change.
I worry about compatibility a lot and my (selfish) reasoning is that it is
better for the CCC to break someones code (there has to be someone somewhere
that uses
Hi,
Thanks for this. This is a really great change.
I reviewed the changes and my only comment is that there is a typo in
java/lang/reflect/Field.java ("scurity").
Somewhat unrelated (but relevant for my implementation of CallerSensitive), but
would it be possible to mark java.lang.Runtime as
Hi Joe,
I notice that Method.isDefault() returns true for static interface methods. I
assume that is not correct.
Regards,
Jeroen
> -Original Message-
> From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
> boun...@openjdk.java.net] On Behalf Of Joe Darcy
> Sent: Thursda
John Rose wrote:
> Remi's idea (using invokedynamic) makes a good proof of concept, too.
> But because we use getCallerClass to observe a non-forgeable caller
> identity, the @CS mechanism has to be something that works "underneath"
> any visible bytecode pattern, at least in the caller.
Yes. In I
Remi Forax wrote:
> I've always found that getCallerClass() was done at the wrong side of
> the problem, i.e. asked inside the callee instead of being inserted at
> callsite.
Yes, I agree and in fact in the IKVM implementation a CallerID parameter is
added to each method that has the HasCallerID
Hi John,
This is really great. I've been using an annotation for caller sensitive
methods for many year in IKVM as a performance enhancement and I can say that
my experiences with my simple mechanism are really great.
I've got a class ikvm.internal.CallerID that looks something like this:
publ
I agree, but at the same time CLASS retention is really the worst of both
worlds in my opinion. It doesn't have any (convenient) runtime benefit, but you
can be sure that someone will depend on it at runtime by parsing the class
files (this happens surprisingly often).
I'd really like to see th
Regards,
Jeroen
From: core-libs-dev-boun...@openjdk.java.net
[core-libs-dev-boun...@openjdk.java.net] on behalf of Jeroen Frijters
[jer...@sumatra.nl]
Sent: Monday, October 15, 2012 9:30 PM
To: Remi Forax
Cc: David Holmes; core-libs-dev@openjdk.java.net
Subject: RE: CloneNotSupported
October 15, 2012 7:08 PM
To: Jeroen Frijters
Cc: David Holmes; core-libs-dev@openjdk.java.net
Subject: Re: CloneNotSupportedException should extends RuntimeException not
Exception
Hi Jeroen,
On 10/15/2012 01:48 PM, Jeroen Frijters wrote:
> The solution is actually pretty easy. Just deprecate
The solution is actually pretty easy. Just deprecate Object.clone() and add a
new method to Object:
protected final native Object shallowClone();
It doesn't require the useless Cloneable interface and doesn't conflate shallow
and deep cloning.
(This is similar to .NET's Object.MemberwiseClone(
Hi,
I'm not a formal reviewer, but I've implemented this same thing for IKVM.NET
which has to simulate the behavior of CreateProcess when running on Windows
(because it uses the .NET API to start a process and that doesn't have this
hack).
Your algorithm doesn't match CreateProcess, because th
Xueming Shen wrote:
> I'm not a GC guy, so I might be missing something here, but if close()
> is being explicitly invoked by some thread, means someone has a strong
> reference to it, I don't think the finalize() can kick in until that
> close() returns
This is not correct. You can re-publish the
David Holmes wrote:
> The fact that Object.clone() is implemented via a native call into the
> VM is simply an implementation detail.
That's not what we're talking about. We're talking about the fact that arrays
(appear to) have a *public* clone method. The argument is about the return
type[1]
Martin Buchholz wrote:
> On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters wrote:
>
>
> Sorry to be late with my comment, but as a VM implementer I can't
> really agree with this modification. The return type of X[].clone() is
> clearly Object, not X{]. That illusion is
Sorry to be late with my comment, but as a VM implementer I can't really agree
with this modification. The return type of X[].clone() is clearly Object, not
X{]. That illusion is a javac compiler trick. IMHO it belongs in the JLS not in
the Object.clone() documentation.
Regards,
Jeroen
> -
David Holmes wrote:
> Fortunately, as Brian stated, compatibility is not an end unto itself
> here and we often do have documented incompatibilities across major
> releases. In this case there is far more harm, in my opinion, leaving
> the possibility of people trying to clone threads than there is
Andrew Haley wrote:
> Please, someone tell me Windows isn't still using the old 18.2 Hz DOS
> timer for its system clock. No
Not that it is true, but why would that be bad?
By default (most) multi core/cpu Windows systems run at a 15 ms timer interrupt
interval (10 ms for single cpu/cor
Naoto Sato wrote:
> Hi Roman,
>
> Thank you for bringing this up. Yes, it's a bit unclear but the
> Currency class belongs to the i18n group.
>
> As to the issue, I have a question. Under jre/lib directory, there are
> other files that are not read via the ClassLoader method. For example,
> ther
36 matches
Mail list logo
