[foreign] RFR : Move array-like methods from Pointer to Array

Tue Nov 20 13:02:08 UTC 2018

So, IntelliJ is a more supported option to hack on the JDK. But I had 
some success to get VSCode up and running. I've installed the "language 
support for Java" extension (do not install the full Java pack, as that 
will bring in maven dependencies an all that).

My local configuration looks like:

"workbench.editor.enablePreviewFromQuickOpen": false,
     "extensions.ignoreRecommendations": false,
     "terminal.integrated.rendererType": "dom",
     "java.errors.incompleteClasspath.severity": "ignore",
     "java.configuration.updateBuildConfiguration": "disabled",
     "java.import.gradle.enabled": false,
     "java.import.maven.enabled": false,
     "java.autobuild.enabled": false,
     "java.home": <PATH TO BUILT JDK>

Then I have a toplevel .project file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
     <name>jdk</name>
     <comment></comment>
     <projects>
     </projects>
     <buildSpec>
     </buildSpec>
     <natures>
<nature>org.eclipse.jdt.core.javanature</nature>
     </natures>
</projectDescription>

And a toplevel .classpath file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
   <classpathentry excluding="module-info.java" kind="src" 
path="src/java.base/share/classes"/>
   <classpathentry excluding="module-info.java" kind="src" 
path="src/jdk.jextract/share/classes"/>
   <classpathentry excluding="module-info.java" kind="src" 
path="src/java.logging/share/classes"/>
   <classpathentry excluding="module-info.java" kind="src" 
path="src/jdk.internal.opt/share/classes"/>
   <classpathentry excluding="module-info.java" kind="src" 
path="src/jdk.internal.clang/share/classes"/>
   <classpathentry excluding="module-info.java" kind="src" 
path="build/linux-x86_64-server-release/support/gensrc/java.base"/>
</classpath>

(you might need to tweak the last entry)

This setup works for me.

If you go down the IntelliJ path, there's plenty of support. From a 
cygwin terminal you should be able to run (from toplevel JDK folder):

sh bin/idea.sh <module names>

e.g.

sh bin/idea.sh java.base

And this will inject all idea configuration files (specific to your 
platform/OS!) in the toplevel folder, so that you can open it with IntelliJ.

Maurizio

On 20/11/2018 12:41, Jorn Vernee wrote:
> Oh, I see I forget to remove the unused imports from BoundedArray. Can 
> you take care of that before pushing?
>
> My IDE (Visual Studio Code) is having a lot of trouble with the JDK 
> code, probably because of the dependency graph. I basically have no 
> intellisense at all. Do you have any IDE tips? There seems to have 
> been a netbeans project for the JDK in the past, but it no longer 
> seems to be present. Most of the advice I've found on the internet is 
> from <=jdk8.
>
> Thanks,
> Jorn
>
> Maurizio Cimadamore schreef op 2018-11-20 13:30:
>> I like it, really good
>>
>> Thanks
>> Maurizio
>>
>> On 20/11/2018 12:20, Jorn Vernee wrote:
>>> I realize I forgot about that yesterday.
>>>
>>> I like your implementation, but LAST should be a pointer one past 
>>> the end of the array to iterate over all elements. That's how it 
>>> works in C/C++ as well, where you're allowed to have a pointer one 
>>> past the last element of a container, as long as you don't 
>>> dereference it. (I've also added a small test to check that the 
>>> returned stream has the right size)
>>>
>>> Naming it `iterate` as well makes sense to me, as it's essentially 
>>> just another version of the Pointer::iterate method.
>>>
>>> Updated webrev: 
>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/arrays/webrev.05/
>>>
>>> Maybe not in the scope of this RFR; should Array implement 
>>> Iterable<X> and stream()? Currently we can get a stream of 
>>> pointers-to-elements, I can imagine people being interested in 
>>> getting a stream of just elements as well. Or should they just 
>>> convert to a Java array for that (using toArray())?
>>>
>>> Jorn
>>>
>>> Maurizio Cimadamore schreef op 2018-11-20 02:42:
>>>> Looks good - can the code in BoundedArray be rewritten in terms of
>>>> Stream::iterate too? E.g. if you produce a pointer to the last element
>>>> - call it LAST - then it should be that
>>>>
>>>> Array::elements()
>>>>
>>>> ~=
>>>>
>>>> Array.elementPointer().iterate(LAST)
>>>>
>>>> Right?
>>>>
>>>> Also, don't we want to rename this to iterate() too?
>>>>
>>>> Maurizio
>>>>
>>>> On 19/11/2018 18:20, Jorn Vernee wrote:
>>>>> Update webrev: 
>>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/arrays/webrev.04/
>>>>>
>>>>> Added 2 `iterate` methods to Pointer, one that takes a predicate, 
>>>>> and one that takes a pointer. Should I also add tests for these? 
>>>>> (elements() was not being tested previously it seems).
>>>>>
>>>>> Thanks,
>>>>> Jorn
>>>>>
>>>>> Maurizio Cimadamore schreef op 2018-11-19 16:27:
>>>>>> <snip>
>>>>>>>>
>>>>>>>> Stream<Pointer<T>> elements(Predicate<? super Predicate<T>> 
>>>>>>>> hasNext)
>>>>>>>
>>>>>>> Yes, this is a nice idea. Maybe we'd also want to have an 
>>>>>>> overload that just takes a `Pointer<T>` as an argument, and 
>>>>>>> iterations will be up until that pointer.
>>>>>> Sure, the pointer-end overload sounds like a nice idea!
>>>>>>>
>>>>>>>> And this would generally applicable to both arrays and 
>>>>>>>> pointers. No
>>>>>>>> guesswork involved, users iterating on pointers will have to 
>>>>>>>> provide
>>>>>>>> an explicit termination condition; if they get it wrong, they 
>>>>>>>> will get
>>>>>>>> some exception when dereferencing the wrong memory location.
>>>>>>>
>>>>>>> Well, for native-allocated pointers this will invoke undefined 
>>>>>>> behavior or possibly crash the VM (or enable access to VM 
>>>>>>> internals? I'm not sure what security is in place there currently).
>>>>>>
>>>>>> A possibility there would be to avoid using EVERYTHING as a backing
>>>>>> region. That is, the binder could, in principle, generate regions 
>>>>>> that
>>>>>> are small enough only to contain the region that we actually want to
>>>>>> access (e.g. starts at base address , ends at base address + pointee
>>>>>> layout size). If the client is not happy with that and knows that 
>>>>>> the
>>>>>> pointer is a pointer to some kind of a buffer, perhaps an (unsafe?)
>>>>>> operation could be provided to relax the memory region boundaries
>>>>>> beneath the pointer.
>>>>>>
>>>>>> But overall I think we should strive for the 'no VM crashes if 
>>>>>> you are
>>>>>> only using the safe API' (although we don't have to get there in one
>>>>>> step).
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> As a final point, I think we should implement elements() using
>>>>>>>> Stream.iterate (and possibly document it in the API).
>>>>>>>
>>>>>>> Agreed. Maybe we should also rename Pointer::elements to 
>>>>>>> Pointer::iterate ?
>>>>>>
>>>>>> I like that.
>>>>>>
>>>>>> Cheers
>>>>>> Maurizio
>>>>>>
>>>>>>>
>>>>>>> Jorn