On 27.04.22 12:47, sminervini.prism wrote:
To the Java OpenJDK Java Community Process,
[...]
You could propose a new data type that follows BCDs from IEE754-2008.
You would have to define conversions of course.
You would have to of course define type conversions, find somebody doing
whatever a
Hi all,
this mail is refering to
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-April/032733.html
and JDK-8057919
In a groovy program
def cl = { -> '' }
assert cl.class.anonymousClass == false
the open block {->''} is compiled into an inner class. We had problems
with this in th
Am 15.06.2015 18:04, schrieb Vladimir Ivanov:
[...]
In order to make the class non-anonymous again, you have to specify
inner_name_index and, optionally, outer_class_info_index.
ok... let me try to understand this better... taking this Java source
public class Test {
public static void main(S
Am 16.06.2015 10:40, schrieb Vladimir Ivanov:
[...]
Example:
class TopLevel {
static class Nested {}
classInner {}
void f() {
class Local {}
}
Object o = new TopLevel() {}; // anonymous
}
And here's how they look like on bytecode level.
I'll use both javap and ASM
1/01/70. With the same constellation regarding jdk versions.
Are those expected to fail? Can someone verify this?
bye Jochen Theodorou
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
but both examples set a locale I thought
Am 09.07.2015 21:06, schrieb Naoto Sato:
Hi Jochen,
It is likely that these are caused by the default locale data change to
CLDR with 8008577.
On 7/9/15 10:12 AM, Jochen Theodorou wrote:
Hi,
after fixing some JDK9 related bugs in our build for Groovy
07.2015 21:27, schrieb Naoto Sato:
I meant the root cause seems to be the same between your first issue and
8130845, where parsing short time zone names has some problem regardless
of it's the ROOT locale or not.
Naoto
On 7/9/15 12:23 PM, Jochen Theodorou wrote:
but both examples set a l
ok, so https://bugs.openjdk.java.net/browse/JDK-6712094 tells me that
the long year format is the right one for Locale.UK, and it mentions
also CLDR. So I guess the change to CLDR by default made this change
happen as well.
Am 09.07.2015 21:39, schrieb Jochen Theodorou:
That means the US
/yoonforhatgmaildotcom.asc
>
>> 2015. 8. 29., 오후 10:01, Jochen Theodorou > <mailto:blackd...@gmx.org>> 작성:
>>
>> Am 29.08.2015 10:56, schrieb Kyung Koo Yoon:
>>> Hi, all.
>>>
>>> The javadoc comment of java.lang.Class.getMethod API has foll
requiring
the java compiler to write those out as well. And that especially
because I assume that jigsaw will put all the api needed for this into
hiding by modules.
bye Jochen Theodorou
On 19.10.2015 03:09, John Rose wrote:
On Oct 18, 2015, at 1:49 AM, Jochen Theodorou mailto:blackd...@gmx.org>> wrote:
* Invokedynamic (like invokeinterface and invokevirtual) does not like
calls with null as receiver
:-) Jochen, you are one of the few people on the planet who was arou
On 18.10.2015 10:55, Andrew Haley wrote:
On 10/18/2015 09:49 AM, Jochen Theodorou wrote:
* Invokedynamic (like invokeinterface and invokevirtual) does not like
calls with null as receiver, quitting the call right away with a NPE.
But languages may allow for calls on null. That again means some
On 18.10.2015 18:19, Attila Szegedi wrote:
[...]
I have basically only main points:
* Invokedynamic (like invokeinterface and invokevirtual) does not like calls
with null as receiver, quitting the call right away with a NPE.
This is fortunately not true, and Nashorn can show you that it isn’
On 19.10.2015 12:56, Attila Szegedi wrote:
On Oct 19, 2015, at 10:46 AM, Jochen Theodorou mailto:blackd...@gmx.org>> wrote:
since it is dynalink there is I guess only one master linker in the
end. Can you point me to some code showing how the composition of
linkers is done to refresh my
Hi all,
I know the following does not compile and does right so by the JLS:
public @interface SomeCollector {
Annotation[] value();
}
I know also that it would be easy to support with the existing
infrastructure. What I am looking for, is the reasoning as of why this
is not allowed beside
On 15.09.2016 09:21, Dawid Weiss wrote:
Console is supposed to be a "char/String" based class, "encoding" really
should have no business here in its api.
While I agree with your concerns about the functional side of the API,
I disagree about this method having no practical use. I can give you
On 09.11.2016 17:47, Paul Sandoz wrote:
Hi Peter,
Good point about if such support was added it would break the API and also
(with Remi) about Ephemerons.
You are correct in stating the constraints in more detail regarding classes in
the same loader. However, i think that is going into more
On 09.11.2016 19:18, Doug Lea wrote:
[...]
And: Similar cases can indeed occur with ThreadLocal, but users seem
to mostly avoid them, sometimes after painful experience.
ThreadLocal is already a bad choice once you subclass it.
bye Jochen
resend after I did accidentally send it to Paul directly instead of the list
On 10.11.2016 21:24, Paul Sandoz wrote:
Hi Jochen,
Can you confirm if my analysis of Groovy using ClassValue was correct:
https://bugs.openjdk.java.net/browse/JDK-8136353
AFAICT in this case the issue was not with Cla
Hi,
java.lang.Class has multiple methods annotated with CallerSensitive (see
http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/tip/src/share/classes/java/lang/Class.java).
Now if we in Groovy here want to build our runtime structure for this
class, and the security manager is not allowing
Hi,
since I am indirectly the reporter of this bug I have one remark for the
test. The error happens only for compiled lambda forms. The given test
does imho not use a compiled lambda form. In other words, afaik the test
would pass without the fix. As such it would be useless as regression tes
Am 16.01.2014 09:48, schrieb A. Sundararajan:
The test sets compile threshold to be zero
(-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think
compilation occurs on the first invoke.
Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the
exception being thrown. I ran i
Hi,
we stumbled here about a strange error involving enums generated from
our compiler and that did make me see getEnumConstantsShared() in
java.lang.Class.
Now the implementation more or less says, that if calling values() fails
in any way, return null and ignore the exception. But why is t
Am 28.02.2014 17:36, schrieb Peter Levart:
[...]
The other use of
getEnumConstantsShared() is to support the Enum.valueOf(Class, String)
method which already throws IllegalArgumentException if the 1st
parameter does not represent an enum class, so there's no compatibility
concerns about that use
Hi,
hoping I will not annoy anyway asking this here I was wondering about
how to interpret the javadoc of these methods correctly.
You basically find this sentence for Class#getInterfaces() and
Class#getGenericInterfaces() "If this object represents a class, the
return value is an array con
Am 26.03.2014 16:51, schrieb Guy Steele:
[...]
I am wholeheartedly in favor of allowing “chaining” of dotted expressions such
as
CharBuffer.allocate(26).position(2).put("C").position(25).put("Z”)
this also shows a potential point of critic this proposal will have to
find arguments agains
Am 27.03.2014 20:22, schrieb Steven Schlansker:
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou wrote:
Am 26.03.2014 16:51, schrieb Guy Steele:
[...]
I am wholeheartedly in favor of allowing “chaining” of dotted expressions such
as
CharBuffer.allocate(26).position(2).put("C"
Am 27.03.2014 21:52, schrieb Eirik Lygre:
[...]
The JavaBean specification, with it's "void setSomething()" functions
are fundamental to so many things Java that they will never go away
(good thing, too!).The suggested language change builds on top of that,
is beneficial to a large body of existi
Am 28.08.2014 18:13, schrieb Pavel Rappo:
Hi everyone,
Is there any particular reason why there's no convenience method for iterators
similar to j.u.Collections.list for enumerations? Or at least the one that
adapts Iterator to Enumeration and vice versa. Thanks.
my opinion:
Enumeration is p
On 08.12.2016 22:10, Uwe Schindler wrote:
Hi,
You can first do standard reflection, then use setAccessible
Maybe we have luck here and it does not apply, but if the field comes
from a class of a module and is private, my current level knowledge of
jigsaw says, that setAccessible will fail wi
On 09.12.2016 08:55, Jochen Theodorou wrote:
On 08.12.2016 22:10, Uwe Schindler wrote:
Hi,
You can first do standard reflection, then use setAccessible
Maybe we have luck here and it does not apply, but if the field comes
from a class of a module and is private, my current level knowledge of
On 09.12.2016 12:59, Alan Bateman wrote:
On 09/12/2016 07:55, Jochen Theodorou wrote:
Maybe we have luck here and it does not apply, but if the field comes
from a class of a module and is private, my current level knowledge of
jigsaw says, that setAccessible will fail with an exception. It
On 09.12.2016 23:32, Uwe Schindler wrote:
Hi,
I updated our Jenkins server for the JDK 9 preview testing to use build 148.
Previously we had build 140 and build 147, which both worked without any
issues. But after the update the following stuff goes wrong:
(1) Unmapping of direct buffers no l
Hi all,
motivated by the recent "Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch" thead, I thought I ask... there is
AcccessibleObject#setAccessible(boolean), which will ask the
SecurityManager for permissions and then make itself accessible
according to the boolean flag.
On 10.12.2016 13:08, Alan Bateman wrote:
On 10/12/2016 09:13, Jochen Theodorou wrote:
Hi all,
motivated by the recent "Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch" thead, I thought I ask... there is
AcccessibleObject#setAccessible(boolean), which wi
: Jochen Theodorou [mailto:blackd...@gmx.org]
Sent: Saturday, December 10, 2016 9:23 AM
To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
Core-Libs-Dev
Subject: Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch
On 09.12.2016 23:32, Uwe Schindler wrote:
Hi,
I updated our Jenkins
On 19.03.2017 18:52, Peter Levart wrote:
Hi,
Module system implementation refresh 2017/2 (JDK-8173393) introduced new
API method AccessibleObject::canAccess which can be used to test if the
caller has access to the reflected member (with possible target object
argument for instance members).
n
frankly I would migrate more from the normal reflection API to the
MethodHandles API instead of extending the Reflection API further, but I
see the use case and reasoning here. thanks.
bye Jochen
On 20.03.2017 10:04, Alan Bateman wrote:
On 19/03/2017 22:47, Jochen Theodorou wrote:
not
On 16.05.2017 19:46, Uwe Schindler wrote:
Hi,
I still don't understand why you need to change the environment variables of the actual process. I
was talking with Rémi about that last week, and it's not obvious to me why you need that. Sure, it
is easier to change the environment of the actual
On 19.05.2017 08:08, Noctarius wrote:
Hey Jochen,
Couldn't the gradle call transfer his view of the environment? I know
that's a workaround but it would solve the issue, wouldn't it?
IMHO it could so by calling native code using posix functions. But what
does it matter if getEnv is not update
Hi all,
I started a thread about this already on the mlvm list, but since I get
no responses there I am going to ask here as well. Plus I have an actual
problem with openjdk 7u25 related to this it seems.
First the u25 problem. According to
https://jira.codehaus.org/browse/GROOVY-6246 openjd
Am 20.07.2013 03:41, schrieb Mandy Chung:
Hi Jochen,
I read through the thread in mlvm-dev [1] that has a good discussion
there. I have filed a RFE:
8020785: caller-sensitive methods to skip dynamic generated frames
and look up the true caller
This seems that java.lang.instrument might be
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate frames inserted by those runtimes controlled by the
runtimes? Couldn't the "surface" runtime-insert
Am 30.07.2013 16:16, schrieb Peter Levart:
On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
interme
Am 03.09.2013 05:04, schrieb Mandy Chung:
Hi Nick,
Thanks for the patch.
JEP 176 [1] describes the caller-sensitive method and the need for a
mechanical checking of caller-sensitive methods. Also Peter Levart in
[2] explained the change in MethodHandles.Lookup related to @CS. I
assume you und
Am 03.09.2013 11:04, schrieb Remi Forax:
[...]
So there is a need for an API to get the caller classes which is not
getCallerClass (or any methods in a package sun.*) that will hide you
the method handle API impementation and allow you choose to filter
caller methods using a user defined API.
n
Am 03.09.2013 19:16, schrieb Peter Levart:
[...]
What about a simple restriction on methods returning such instances that
Class objects are only returned when they are resolvable from the
ClassLoader of client code. If they are not resolvable, null is
returned. For example, the equivalent of:
pu
Am 03.09.2013 16:12, schrieb A. Sundararajan:
[...]
If Groovy or any third-party framework gets away with that -- that is
because you need to use modified security policy that gives those
necessary permissions to groovy.jar or whatever third-party jar in
question.
just think of us needing to bu
Am 04.09.2013 02:33, schrieb Mandy Chung:
On 9/3/13 1:17 AM, Jochen Theodorou wrote:
Defining a SE supported @CallerSensitive and also getCallerClass API
poses the risk of "encouraging" developers to implement more @CS methods
while not fully understand its implication.
Again I
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array. This seems
like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.
if you need the full stack, then misusing a Predicate and a dummy
Consumer to colle
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a "stream" that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying the entire
stack trace data even for the short re
Am 20.09.2013 10:50, schrieb Jörn Huxhorn:
[...]
But I have serious doubts that *this* is going to be more efficient than just
iterating over an array.
+1
Feel free to add all that functionality but all we are asking for right now is
access to the call stack array in a way that is as fast,
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
List frames = new ArrayList<>();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole stack
or not. Your code implies it does. If It does, I don't see the advantage
of suing a Stream he
Am 20.09.2013 12:05, schrieb Peter Levart:
[...]
The use-cases described used getCallerClass(int depth) repeatedly to
find a caller by iterating over a range of depths and calling
getCallerClass(depth). You can use either Thread.walkStack or
Thread.firstCaller for implementing those use-cases.
Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
Exposing a StackStream API means that you need to eagerly walk the stack
and copy the stack frames to it before it returns. I agree it is a much
more flexible API. On the other hand, stack walking is sequential and
ordered and a stack stream will
Am 20.09.2013 17:45, schrieb Peter Levart:
[...]
I think the reasoning behind call-back API is that it moves the logic to
construct a suitable data structure to the Java side, skipping
intermediary representations and conversions.
StackFrameInfo is already a conversion for me. I see some value
Am 20.09.2013 18:38, schrieb Peter Levart:
[...]
As I understand the Thread.firstCaller() does exactly that.
"findFirstCallerMatchingPredicate". Choosen name abbreviation is maybe
not making the semantic immediately obvious.
then sorry, I overlooked that in the link
though the usage of this i
Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
I have some trouble in expressing the skipToSecondPredicate without side
effect in lambda. With the help from Paul Sandoz (thanks Paul), if I
had a stack stream, Thread.getCaller() method would be like this:
stream.filter(e -> return
REFLECTION
58 matches
Mail list logo
