On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I
On Thu, 3 Jun 2021 03:23:13 GMT, Brian Goetz wrote:
> reasonable options are to either leave it alone, deprecate it, or engage
> in a much more deliberate redesign.?
My favorite option is to leave it alone and test it a bit with the test already
provided in this PR. That however requires one ap
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I
There doesn't seem to be much support for the complete changes in #4245. To get
at least something useful from that endeavor I have extracted the test for
existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this
pull request without any changes to the JVM behavior.
--
On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach
wrote:
> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>
> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code
>
On Mon, 31 May 2021 12:02:13 GMT, Peter Levart wrote:
> A test could be constructed so that it would mimic the migration of an
> annotation from CLASS to RUNTIME retention
The test is ready for review in #4280 - I am closing this PR without
integration as the change of core-libs proposed here
On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach
wrote:
>> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
>> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>>
>> Existing `-XX:+PreserveAllAnnotations` option can be very useful
On Sun, 30 May 2021 23:03:55 GMT, David Holmes wrote:
> But we should add in some tests.
Right, I was surprised by missing tests as well. I've just created a
_"standalone"_ commit 0f689ea that adds such test and also shows the way I am
currently using the `-XX:+PreserveAllAnnotations` flag. I
nnotation(...)`
> useful when `-XX:+PreserveAllAnnotations` option is on.
Jaroslav Tulach has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains tw
nnotation(...)`
> useful when `-XX:+PreserveAllAnnotations` option is on.
Jaroslav Tulach has updated the pull request incrementally with two additional
commits since the last revision:
- Merging with test for long time existing behavior of
-XX:+PreserveAllAnnotations
- Test long time existing b
On Sun, 30 May 2021 19:56:52 GMT, Jaroslav Tulach
wrote:
>> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
>> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>>
>> Existing `-XX:+PreserveAllAnnotations` option can be very useful
nnotation(...)`
> useful when `-XX:+PreserveAllAnnotations` option is on.
Jaroslav Tulach has updated the pull request incrementally with one additional
commit since the last revision:
Only expose non RetentionPolicy.RUNTIME annotations when
-XX:+PreserveAllAnnotations is specified
On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach
wrote:
> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>
> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code
>
This PR exposes runtime invisible annotations via `Class.getAnnotation` when
`-XX:+PreserveAllAnnotations` option is passed to the JVM.
Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that
needs to access annotations with `RetentionPolicy.CLASS` without the need to
par
t; These changes passed Hotspot pre-integration testing and additional
>> requested tests.
>>
>> Thanks,
>> Vladimir
>>
>>> On 11/15/17 5:44 AM, Jaroslav Tulach wrote:
>>>> On úterý 14. listopadu 2017 21:34:45 CET mandy chung wrote:
>>>&g
running with -Djava.security.debug=access:domain:failure
> >
> > This will tell you what ProtectionDomain caused the
> > AccessControlException, which should give you a better idea of where
> > the problem is. Look for messages that start with "domain that faile
try full rebuild on d85284ccd1bd maybe it disappears...
On pondělí 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
> Hello Mandy,
>
> this was a good test:
> > > ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> > > +EnableJVMCI
Hello Mandy,
this was a good test:
> >
> > ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> > +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>
> You can also try running the above command with -Djava.security.manager
> as a sanity test (the application may need additional perm
Hi.
I believe I have a fix for JDK-8189116 - the
jdk.internal.vm.compiler.management needs only few permissions as shown in my
webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/
I have executed all the tests I found and it seems none of them regressed.
Also the Graal Compiler MX bea
Opps. Sorry for causing the problem. I haven't executed the test in question
and thus I thought everything is OK.
Thanks Vladimir for creating the fix.
-jt
On středa 4. října 2017 16:05:33 CEST Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8188775
>
> Changes for 8182701[1]
On pátek 15. září 2017 10:53:45 CEST mandy chung wrote:
> > http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/index.html
>
> Looks good.
Great. Unless there are further comments, then we can plan integration of my
changes. Vladimir, are you "sponsor" of my change? Will you integrate it
som
Thanks for the review Mandy, Daniel. Now, that the consolidated JDK10
repository is available, I have updated my webrev to its structure. In
addition to that I addressed your comments:
On úterý 12. září 2017 11:19:45 CEST mandy chung wrote:
> ./make/common/Modules.gmk
> Nit: can you move jd
Dear reviewers,
after several reconsiderations I have webrev #4 ready for your review. Can you
please take a look at
http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/
and let me know if it is in a reasonable shape? Thanks a lot.
-jt
his is acceptable, I would change documentation of the mbean() method to
mention how the set of mbeanInterfaces() is computed. OK?
Thanks for the review.
-jt
> On 8/18/17 11:49 AM, Vladimir Kozlov wrote:
> > Updated changes in all repos:
> > http://cr.openjdk.java.net/~kvn/8182701/w
2017, at 20:49, Vladimir Kozlov
> > wrote:
> >
> > Updated changes in all repos:
> > http://cr.openjdk.java.net/~kvn/8182701/webrev.01/
> >
> > On 8/18/17 7:12 AM, Jaroslav Tulach wrote:
> >
> > Thanks for pushing me forward, Vladimir. Yes, the change
On čtvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote:
> On čtvrtek 27. července 2017 15:01:17 CEST Alan Bateman wrote:
> > On 27/07/2017 10:07, Jaroslav Tulach wrote:
> > > Yes, it seems like a desirable goal to let Graal compiler work with just
> > > java.base.
On čtvrtek 27. července 2017 15:01:17 CEST Alan Bateman wrote:
> On 27/07/2017 10:07, Jaroslav Tulach wrote:
> > Yes, it seems like a desirable goal to let Graal compiler work with just
> > java.base. Is there a description how to build JDK9/10 with just java.base
> > that I
> This is Graal-specific MBean. It doesn’t seem that it must be registered as
> “platform mbean” which has to implement PlatformManagedObject.
>
> Graal can register the MBean at runtime when java.management is present by
> calling ManagementFactory.getPlatformMBeanServer().registerMBean method.
ices/src/jdk/vm/ci/servic
> es/internal
The location is probably not correct. I am even surprised the code builds fine.
Thanks for catching this.
-jt
> >>> On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov
> >>> wrote:
> >>>
> >>> https://bugs.openjdk.ja
OpenJDK would follow the same habits, but I might have
been wrong.
> On 08/13/2014 07:12 AM, Jaroslav Tulach wrote:
> > As far as I understand Andrew's inquiry, the problem is not (that much)
> > related to finalizers, rather to question whether following method can
>
java.net/browse/JDK-8055183[2] to resolve it somehow. I'll
be
watching from distance eager to know the result.
Dne St 13. srpna 2014 13:12:43, Jaroslav Tulach napsal(a):
> Dne So 9. srpna 2014 07:18:54, Doug Lea napsal(a):
> > > Dne Pá 8. srpna 2014 15:02:41, Stanimir Simeono
Dne So 9. srpna 2014 07:18:54, Doug Lea napsal(a):
> > Dne Pá 8. srpna 2014 15:02:41, Stanimir Simeonoff napsal(a):
> >
> >
> > According to articles provided by Andrew[1], toString() can be on stack,
> > even if obj
> > (e.g. this for toString()) is garbage collected. This is a bit surprising
>
ed?
-jt
>
> On Fri, Aug 8, 2014 at 11:01 AM, Jaroslav Tulach > wrote:
> >
> > Hello Doug,
> > thanks for your reply and clarification about finalization. May I ask for
> > one more
> > clarification, this time about WeakReference behavior?
> >
>
Dne Pá 8. srpna 2014 10:01:14, Andrew Haley napsal(a):
> On 08/08/14 09:01, Jaroslav Tulach wrote:
> > Given the fact that WeakReference & co. has been introduced in JDK
> > 1.2 and that version was released at the end of 1998, I bet it was
> > just a communication pro
to one.
In any case I am really glad a synergy in needs of JDK and NetBeans has been
found. Hopefully that will lead to easier acceptance of the need for a official
public API for lightweight finalization.
-jt
Dne St 6. srpna 2014 12:17:38, Jaroslav Tulach napsal(a):
> OK,
> time to sh
must have been talking about something else than WeakReference +
ReferenceQueue behavior.
-jt
> On 08/07/2014 03:43 AM, Jaroslav Tulach wrote:
> > Dne Čt 7. srpna 2014 08:17:16, Andrew Haley napsal(a):
> >> I'm wondering whether it's really worth your time apply
e assumption
that the new APIs which were designed to replace Object.finalize - e.g.
WeakReference and ReferenceQueue & co. are flawless.
> On 06/08/14 11:17, Jaroslav Tulach wrote:
> > Sure, but that cannot happen with activeQueue() as the referent is really
> > gone before ap
OK,
time to show the code. I've added an alternative patch to JDK-8051843:
https://bugs.openjdk.java.net/secure/attachment/21640/ActiveQueueFinalizer.diff
I suggest to start reading it from bottom - e.g. the test, the documentation
and then the implementation.
Now there is time for some discussi
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 management thread?
> > # 2 - Or because once fin
em!
-jt
> On Jul 24, 2014, at 7:29 AM, Jaroslav Tulach
> wrote:
> > Hi.
> > I'd like to add one new method into java.lang.ref.ReferenceQueue. Can
> > anyone help me go through the review process? I've reported
> > https://bugs.openjdk.java.net/bro
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 keeping the activerReferenceQueue thread alive and holding
> > refer
Hello David,
the following suggestions are hard to argue with as they touch philosophical
aspects of software engineering. In spite of that I will attempt to analyze
and argue:
Dne Út 29. července 2014 18:16:24, David Holmes napsal(a):
> I think the fundamental flaw of activeReferenceQueue is in
Dne Út 29. července 2014 18:16:24, David Holmes napsal(a):
> Thanks for the detailed explanation. It is an interesting problem.
Good. I am glad it attracted your attention. I am also glad Peter came with
his static method...
> On 29/07/2014 6:03 PM, Peter Levart wrote:
> > On 07/29/2014 04:16 A
gt; that ReferenceQueue has been collected and will exit.
>
> Regards, Peter
>
> On 07/28/2014 03:06 PM, Jaroslav Tulach wrote:
> > Hello David,
> > thanks for being patient with me. I'll do my best to describe the original
> > context.>
> > Dne P
Hello David.
Dne Út 29. července 2014 12:16:33, David Holmes napsal(a):
> So ... activeReferenceQueue is a reference queue that embodies a thread
> that does the polling and implements a psuedo-finalization mechanism.
> This works fine in the normal case where the lifetime of the queue is
> the li
Hello David,
thanks for being patient with me. I'll do my best to describe the original
context.
Dne Po 28. července 2014 21:07:45, David Holmes napsal(a):
> I read the issue and still did not understand the nature of the problem.
> The netbeans bugs also did not shed any light on things for me.
aving strong reference to impl - e.g. without impl being on
stack
during the remove call.
-jt
Dne Po 28. července 2014 09:23:55, Jaroslav Tulach napsal(a):
> Thanks for your reply.
>
> Dne Pá 25. července 2014 12:45:02, Brian Goetz napsal(a):
> > So, let’s start with the prob
r, style may get us
closer to
mutual understanding.
-jt
> and then we can
> proceed to evaluating whether the proposed solution is the right one?
> On Jul 24, 2014, at 7:29 AM, Jaroslav Tulach
> wrote:
> > Hi.
> > I'd like to add one new method into java.lang.ref.Refer
Hi.
I'd like to add one new method into java.lang.ref.ReferenceQueue. Can anyone
help me go through the review process? I've reported
https://bugs.openjdk.java.net/browse/JDK-8051843
but that probably is not enough, right?
Thanks in advance for your help.
-jt
Hello.
Can anybody hear me? I'd like to talk to someone who cares about String,
StringBuffer and StringBuilder. I am NetBeans Platform architect and I'd like
to use this opportunity to fasten start of NetBeans as well as improve OpenJDK
project. Here is my story:
I've been investigating the mem
egedTemplatesFactory {
private PrivilegedTemplatesFactory() {}
public static PrivilegedTemplates create(String... names) { ... }
}
and then the "service providers" could:
public class SomeImplClass {
public static String[] myPrivilegedTemplates() {
return PrivilegedTemplatesFactory
without
> fearing a clash with an existing subclass method name), and I guess you
> have in mind that such classes could have their behaviour defined via
> constructor parameters, with each new version adding a new constructor; but
> rather than guessing it would be nice to see an example.
h?
By when?
-jst
[1] I'd like my patch to not be dropped just because, we wait and wait and
wait and then it will be "too late".
Jaroslav Tulach wrote:
> Proposal: Enhance ServiceLoader to understand factory methods
>
> Justification: A lot of our services in NetBeans a
Thanks for the clarification, Mark. I've heard about some umbrella JSR for
each release of the JDK before and I was hoping that my proposed change
could be covered as part of it. Thanks for confirming that such aggregation
is possible.
> With regard to this particular proposal, as the original au
Hi.
I can imagine, dear core-libs members, that you are all busy with your jobs,
however at least give me hope: Can I get my patch into the OpenJDK in
reasonable timeframe or not?
Thanks in advance for your reply.
-jst
Jaroslav Tulach wrote:
> Proposal: Enhance ServiceLoader to underst
know what shall I change to allow
this
to be integrated to OpenJDK7. Thanks a lot.
Jaroslav Tulach
NetBeans Platform Architect
diff -r 14f50aee4989 src/share/classes/java/util/ServiceLoader.java
--- a/src/share/classes/java/util/ServiceLoader.java Thu Oct 02 19:58:32 2008 -0700
+++ b/src/share/cl
57 matches
Mail list logo
