JEP 119 / Implementation of javax.lang.model.util.Types

[Florian Schoppmann]

Hi all,

This Github repository of mine 
provides an abstract skeletal implementation of the type-system related
methods of interface javax.lang.model.util.Types, plus a
concrete realization backed by the core Java Reflection API, akin to JEP
119 by Joe Darcy.

Obviously, there also exists an official JEP 119 implementation, so far
in proof-of-concept state:


In their current states, the two projects have slightly different goals:
E.g., CoreReflectionFactory.java in the official JEP 119
implementation does not yet implement all subtyping-related relations
like, e.g., JLS §4.5.1 "contains", whereas my project is so far only
concerned with subtyping but does not implement any
Element-subinterfaces except TypeElement). Moreover, JEP 119 is only
concerned with backing javax.lang.model by Core Reflection, whereas the
goal of my project is to allow arbitrary backing (say, e.g., by the
domain model of some DSL that needs to support the Java type system).

If there should be any interest in using my code or parts of it for the
JDK, I would be happy to help with any necessary adjustments.

Florian

PS: X-post to core-libs.devel and compiler.devel. Follow-up to core-libs
suggested.

RE: Patch to improve primitives Array.sort()

[Chan, Sunny]

I have looked at the mailing list archive and so far I haven't identify any 
progress on the "space for benchmark"  - so we could include the performance 
test as a part of the patch but it will required JMH access somehow.

From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: 22 May 2015 22:24
To: Rezaei, Mohammad A. [Tech]
Cc: 'core-libs-dev@openjdk.java.net Libs'; Chan, Sunny [Tech]; O'Leary, Kristen 
[Tech]
Subject: Re: Patch to improve primitives Array.sort()

On May 22, 2015, at 3:55 PM, "Rezaei, Mohammad A." 
mailto:mohammad.rez...@gs.com>> wrote:
We have a set of JMH tests.

Great.

I created a bug for this issue:

  https://bugs.openjdk.java.net/browse/JDK-8080945


We'll work with Sunny to make those part of the webrev (where do they go?) and 
the specific test you suggested below.

Not actually sure, for now let's keep 'em with the unit test.

I seem to recall a there was a "space" being arranged for benchmarks but i have 
forgotten if any progress has been made on that.

Paul.

RE: DualPivotQuicksort webrev for JDK-8080945

[Rezaei, Mohammad A.]

Stefan, you're looking at an older version of the code. If you apply Paul's 
suggestions from 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033640.html
the code works as expected.

Thanks
Moh

>-Original Message-
>From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
>Of Stefan Zobel
>Sent: Monday, May 25, 2015 11:23 AM
>To: core-libs-dev@openjdk.java.net
>Subject: DualPivotQuicksort webrev for JDK-8080945
>
>Hi all,
>
>
>Unless I'm doing something immensely stupid, the DualPivotQuicksort
>proposal in http://cr.openjdk.java.net/~psandoz/tmp/gs/sort/webrev.2/
>doesn't work for me.
>
>
>This little program
>
>
>public static void main(String[] args) {
>int[] a = new int[287];
>
>for (int i = 0; i < a.length; i++) {
>a[i] = -((i % 143) + 1);
>}
>
>System.out.println(Arrays.toString(a));
>
>DualPivotQuicksort.sort(a, 0, a.length - 1, null, 0, 0);
>}
>
>
>
>sends the sort into an infinite loop. Something wrong with the test??
>
>
>Stefan

RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields

[Ivan Gerasimov]

Hello!

This is in some way continuation of JDK-8080535 (Expected size of 
Character.UnicodeBlock.map is not optimal).


A new utility class OptimalCapacity was added to jdk.testlibrary package.
The test NonOptimalMapSize.java that had been added with JDK-8080535, 
was rewritten with use of this new class.
A couple more tests were added, which utilize methods of 
OptimalCapacity  for checking sizes of ArrayList and IdentityHashMap 
static variables.


Optimization of initial sizes of two more variables saves us one 
reallocation during java start-time and a few more bytes of memory.


Would you please help review this fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8081027
WEBREV: http://cr.openjdk.java.net/~igerasim/8081027/00/webrev/

Sincerely yours,
Ivan

Re: Review Request 8074432: Move jdeps to jdk.compiler module

[Mandy Chung]

Meant to include jigsaw-dev in the initial post.

> On May 25, 2015, at 12:16 AM, Alan Bateman  wrote:
> 
> On 24/05/2015 05:00, Mandy Chung wrote:
>> This will move jdeps to the same module as other langtools javac and javap.
>> 
>> Webrev at:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.00/
>> 
>> This is the final change to resolve the open issue JDK-8072601 (Re-examine 
>> jdk.runtime and jdk.dev modules) for JEP 200.
>> 
>> Mandy
> I don't see any issues with the patch but I wonder if this is a case where we 
> should introduce jdk.jdeps rather than putting the tool in the jdk.compile 
> module.
> 


serialver and javap are in jdk.compiler that is an appropriate home for jdeps 
while I don’t particularly like it since it isn’t clear to tell from 
jdk.compiler module name where jdeps is there.

The tool modules have been evolved a bit and some tools are put in its own 
module such as jdk.pack200, jdk.policytool, jdk.javadoc, jdk.jconsole, jdk.rmic 
etc.  that are organized around its primary tool which is easy to name, 
document, and understand.

Putting jdeps in jdk.jdeps module makes it easy where to find jdeps that is an 
attractive option. 

This also opens up the option to move jdeps to jdk repo in the future - it is 
just a side point and jdeps is currently being used as an interim solution to 
verify module boundaries until the module system is moving further along.

I will post a revised webrev.

> A passing comment is that I see we run these tools with -Xms8m, we should 
> re-visit that some day.
> 

Yes - we should re-visit this for the launchers we have.

Mandy

Re: RFR [9] 8040147: minor cleanup for docs

[Lance Andersen]

Hi Alexander,

Overal this looks OK.  One suggestion for webrevs  is to  change  
to {@code} while you are updating specific comments (not the entire file, but 
at least the lines you are touching).  

Thank you for making the changes.

Best
Lance
On May 25, 2015, at 5:40 AM, alexander stepanov 
 wrote:

> Hello,
> 
> Could you please review the fix
> http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/
> for
> https://bugs.openjdk.java.net/browse/JDK-8040147
> 
> Just a minor fix for docs (some tidy warnings + misprints).
> 
> Thanks,
> Alexander
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

DualPivotQuicksort webrev for JDK-8080945

[Stefan Zobel]

Hi all,


Unless I'm doing something immensely stupid, the DualPivotQuicksort
proposal in http://cr.openjdk.java.net/~psandoz/tmp/gs/sort/webrev.2/
doesn't work for me.


This little program


public static void main(String[] args) {
int[] a = new int[287];

for (int i = 0; i < a.length; i++) {
a[i] = -((i % 143) + 1);
}

System.out.println(Arrays.toString(a));

DualPivotQuicksort.sort(a, 0, a.length - 1, null, 0, 0);
}



sends the sort into an infinite loop. Something wrong with the test??


Stefan

Re: RFR 8068978: All versions of javax.script.ScriptEngine.eval(...) method may clarify ScriptException throwing

[Attila Szegedi]

+1

> On May 25, 2015, at 2:54 PM, A. Sundararajan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8068978/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8068978
> 
> Thanks,
> -Sundar

RFR 8068978: All versions of javax.script.ScriptEngine.eval(...) method may clarify ScriptException throwing

[A. Sundararajan]

Please review http://cr.openjdk.java.net/~sundar/8068978/webrev.00/ for 
https://bugs.openjdk.java.net/browse/JDK-8068978


Thanks,
-Sundar

RFR [9] 8040147: minor cleanup for docs

[alexander stepanov]

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8040147/webrev.02/
for
https://bugs.openjdk.java.net/browse/JDK-8040147

Just a minor fix for docs (some tidy warnings + misprints).

Thanks,
Alexander

Re: RFR JDK-8042125: Japanese character converters incompatible between Java 7 and Java 8

[Masayoshi Okutsu]

Looks good to me.

Masayoshi

On 5/24/2015 9:26 AM, Xueming Shen wrote:

Hi

Please help the change for 8042125

issue: https://bugs.openjdk.java.net/browse/JDK-8042125
webrev: http://cr.openjdk.java.net/~sherman/8042125

It's a regression caused by the changes of JDK-6653797. The direct 
triggers are
(1) the .c2b mapping table for ms932/0208is missing (regardless the 
comment in

 JIS_X_0208_MS932.map says we need one)
(2) mapping entry for those non-roundtrip code points are mistakenly 
commented

out in jis_x_0212_solaris.map and jis_x_0208_ms932.map.

thanks!
-Sherman

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

[Magnus Ihse Bursie]

On 2015-05-22 16:02, Roger Riggs wrote:

Hi Alan,

The change to make the assert about the build numbers in 
getVersionInfo should be a different issue.
Perhaps it makes sense to do that as part of the JEP 223: New 
Version-String Scheme

that is specific to the Oracle JDK.


The current JEP-223 sandbox does indeed have a check in configure that 
build numbers cannot exceed 255.


/Magnus




Thanks, Roger



On 5/22/2015 2:55 AM, Alan Bateman wrote:



On 22/05/2015 01:42, Roger Riggs wrote:

Oops, got the wrong host:

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/

Issues:
8074818: Resolve disabled warnings for libjava
8080007: Stop ignoring warnings for libjava

Thanks, Roger
In JDK_GetVersionInfo0 then I wonder if we should change this assert 
to be a fatal error on product builds. Periodically people set the 
build to numbers > 255 and often only see issues when they use a 
fastdebug build.


Th rest looks okay to me. I don't particularly like the IOE_FORMAT in 
ProcessImpl.c but I think other areas have done similar to deal with 
this warning. ConcurrentPReader_md.c is being removed in another 
patch under review at the moment so might be gone before you push.


-Alan.

Re: Review Request 8074432: Move jdeps to jdk.compiler module

[Alan Bateman]

On 24/05/2015 05:00, Mandy Chung wrote:

This will move jdeps to the same module as other langtools javac and javap.

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.00/

This is the final change to resolve the open issue JDK-8072601 (Re-examine 
jdk.runtime and jdk.dev modules) for JEP 200.

Mandy
I don't see any issues with the patch but I wonder if this is a case 
where we should introduce jdk.jdeps rather than putting the tool in the 
jdk.compile module.


A passing comment is that I see we run these tools with -Xms8m, we 
should re-visit that some day.


-Alan.