Hi All,
Please review https://bugs.openjdk.java.net/browse/JDK-8158510
*Problem:* How to validate annotation, as javac does not allow us to
write wrong annotation so how should we test valid annotation at runtime?
http://cr.openjdk.java.net/~srastogi/8158510/webrev.00/
*Solution:* To test this
> On 1 Jul 2016, at 00:53, Doug Lea wrote:
>
> On 06/30/2016 10:08 AM, Paul Sandoz wrote:
>> Hi Peter,
>>
>> Thanks, that’s interesting. I am uncertain if our 166 fellows will be
>> reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets.
>
>
> Background: we are reluctant
Hi all,
May I request you to review below simple fix for following issue:
Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616
Solution: Removed the unneeded case statement INSTANT_SECONDS from
get(TemporalField field) of java.time.Instant class
Webrev: http://cr.openjdk.java.net/~bgopul
Hi Shilpi,
There is more going on here than just the test since you have modified the
annotation processing to throw an ISE for an annotation type that contains one
or more methods that do not define elements. That behaviour might be too
restrictive.
This is a grey area and implementation spec
Hi all,
May I request you to review below simple fix for following issue:
Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616
Solution: Removed the unneeded case statement INSTANT_SECONDS from
get(TemporalField field) of java.time.Instant class
Webrev: http://cr.openjdk.java.net/~bgopu
Fine by me
Stephen
On 1 July 2016 at 10:01, Bhanu Gopularam
wrote:
> Hi all,
>
> May I request you to review below simple fix for following issue:
>
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616
>
> Solution: Removed the unneeded case statement INSTANT_SECONDS from
> get(TemporalFie
Hi Vladimir,
thank you once more - your comments led to more improvements. The results are
at http://cr.openjdk.java.net/~mhaupt/8143211/webrev.02/, and some details are
inlined below.
> Am 29.06.2016 um 17:57 schrieb Vladimir Ivanov :
> I'd prefer to see loopStateTypes attached to the intrinsi
Hi all,
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681
Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating
Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/
Tests are already covered under *f**actory_ofEpochDay_aboveMax()* ,
*factory_ofEp
Thanks Paul !!
Please see http://cr.openjdk.java.net/~srastogi/8158510/webrev.01/
Regards,
Shilpi
On 7/1/2016 3:12 PM, Paul Sandoz wrote:
Hi Shilpi,
There is more going on here than just the test since you have modified
the annotation processing to throw an ISE for an annotation type that
c
src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java:
+ * Emit bytecode for the loop idiom.
...
+ * loop=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L)=>{
+ * t8:L=MethodHandles.constant(String.class, "");
+ * t9:L=MethodHandle.invokeBasic(a5:L,a7:L);
Fine by me, thanks
Stephen
On 1 July 2016 at 12:38, nadeesh tv wrote:
> Hi all,
>
> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681
>
> Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating
>
> Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/
>
> On 30 Jun 2016, at 13:20, Martin Buchholz wrote:
>
> Webrev regenerated with updates.
> Lots of rework for the atomic VarHandle specs.
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
>
Look good, focusing on the atomics section.
I noted that some text has been
Hi Stephen,
I'm a bit puzzled by the values recommended for the EpochDay Range.
The code should be commented with the computation relative to the range
of year MIN/MAX
so there is a more complete understanding.
I would expect the MIN to be the negative of the MAX or pretty close.
Are the new va
Never mind, I just saw the comment in the bug.
"Just for a reference, EpochDay range = (LocalDate.MIN.toEpochDay() ,
LocalDate.MAX.toEpochDay()) "
That comment is worth adding to the comments for EpochDay.
Roger
On 7/1/2016 9:38 AM, Roger Riggs wrote:
Hi Stephen,
I'm a bit puzzled by the v
+1, looks fine.
Roger
On 7/1/2016 6:39 AM, Stephen Colebourne wrote:
Fine by me
Stephen
On 1 July 2016 at 10:01, Bhanu Gopularam
wrote:
Hi all,
May I request you to review below simple fix for following issue:
Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616
Solution: Removed the
Hi Mandy,
On 30/06/16 19:23, Mandy Chung wrote:
Looks pretty good. What if the application logger is a custom Logger subclass?
Would this mechanism support that?
Yes - this is taken into account, but there are
limitations: by design only data that has been set by
calling the super class sett
Hi Vladimir,
> Am 01.07.2016 um 14:00 schrieb Vladimir Ivanov :
> Stale LF shape in the comment.
Fixed.
> -if (assertStaticType(cls, n))
> -return; // this cast was already performed
> +assertStaticType(cls, n);
>
> This change completely defeats localCl
Stephen, Roger,
Thanks for the comments.
On 7/1/2016 7:11 PM, Roger Riggs wrote:
Never mind, I just saw the comment in the bug.
"Just for a reference, EpochDay range = (LocalDate.MIN.toEpochDay() ,
LocalDate.MAX.toEpochDay()) "
That comment is worth adding to the comments for EpochDay.
Plea
After internal discussion, the fix we arrived at is now here:
http://cr.openjdk.java.net/~mhaupt/8143211/webrev.03/
Looks good.
Best regards,
Vladimir Ivanov
> On Jul 1, 2016, at 7:09 AM, Daniel Fuchs wrote:
>
>
> OK. I was concerned about the cost of creating a doPrivileged call
> for nothing - but then reflected that system classes usually call
> getLogger only once for a specific logger - at which point the
> doPrivileged will be needed anyway (o
Looks ok, btw. doesn't the bug need to be added to the test ?
If that is all there is to it. I don't need to see an iteration.
Thanks
Kumar
Kumar,
I move the call to CreateApplicationArgs before PostJVMInit and dryRun stops
before PostJVMInit which shows the splash screen.
Webrev:
http:/
On 01/07/16 16:09, Mandy Chung wrote:
I was thinking to move the entire doPrivileged block to mergeWithSystemLogger
that will look like:
if (cfg == system.config) {
return;
}
// sanity check
if (!system.isSystemLogger ….
throw new InternalError(…);
final Co
> On Jul 1, 2016, at 8:16 AM, Daniel Fuchs wrote:
>
> On 01/07/16 16:09, Mandy Chung wrote:
>> I was thinking to move the entire doPrivileged block to
>> mergeWithSystemLogger that will look like:
>>
>>if (cfg == system.config) {
>>return;
>>}
>>
>>// sanity check
>>if
On 01/07/16 16:19, Mandy Chung wrote:
I'd prefer to keep the doPrivileged in LogManager so that
> Logger.mergeWithSystemLogger can call checkpermission().
>
> From a conceptual point of view it's only when calling
> this method from LogManager that we want to be privileged,
> even though the meth
> On Jul 1, 2016, at 8:23 AM, Daniel Fuchs wrote:
>
> On 01/07/16 16:19, Mandy Chung wrote:
>>> I'd prefer to keep the doPrivileged in LogManager so that
>>> > Logger.mergeWithSystemLogger can call checkpermission().
>>> >
>>> > From a conceptual point of view it's only when calling
>>> > this m
Mark,
fixed port numbers are always going to be problematic in tests. Is there
any way the port numbers can be assigned after the test starts up ?
Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be
modified/accessed via reflection so that the initUsingIiopUrl can be
re-called once y
Hi Mark,
Instead of spreading around the condition and the port numbers, can you
pass the pair of port numbers (as int's)
to startOrbD and startRmiIiopServer? That would allow the logic for
changing the port numbers to be
put into startTestComponents.
And you could take advantage of the Test
On 01/07/16 16:33, Mandy Chung wrote:
I think the additional check is unecessary but it’s harmless if you prefre to
keep that.
Oh - I see - the permission check in ConfigurationData::merge
can be removed: ConfigurationData is a private class and
config is a private field. I will do that.
chee
> On Jun 28, 2016, at 10:44 AM, Daniel Fuchs wrote:
>
> Hi,
>
> JDK-8056285 has been sighted again (sigh).
> I strongly suspect a configuration issue but I have
> no proof. Here is an attempt at gathering some more
> data to nail down the root cause of the issue.
>
> JBS
> https://bugs.openjdk
Hi Sean,
thanks for the feedback ... we should be ok with fixed ports. The
orbd by default uses the fixed ports of 1050 and 1049.
The selected ports are not in the ephemeral range on any platform.
solaris
/usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port
32768
65535
linux
Hi Roger,
thanks for the feedback and suggestion.
so is the suggestion one of parsing the command line of the test to
extract the -port argument and then fabricate the
NS port with an increment, and then pass this into the startComponents
method and thus, eliminate the
security manager check
Hi Mark,
On 7/1/2016 2:25 PM, Mark Sheppard wrote:
Hi Roger,
thanks for the feedback and suggestion.
so is the suggestion one of parsing the command line of the test to
extract the -port argument and then fabricate the
NS port with an increment, and then pass this into the startComponents
m
+1
Naoto
On 7/1/16 1:08 PM, Kumar Srinivasan wrote:
Hello,
Please review simple fix:
https://bugs.openjdk.java.net/browse/JDK-8145418
Thanks
Kumar
diff --git
a/src/java.base/share/classes/sun/launcher/resources/launcher.properties
b/src/java.base/share/classes/sun/launcher/resources/launcher
Hello,
Please review simple fix:
https://bugs.openjdk.java.net/browse/JDK-8145418
Thanks
Kumar
diff --git
a/src/java.base/share/classes/sun/launcher/resources/launcher.properties
b/src/java.base/share/classes/sun/launcher/resources/launcher.properties
--- a/src/java.base/share/classes/sun/la
34 matches
Mail list logo
