Re: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles

[Chris Bensen]

+1 I did a quick test on Mac and it worked for me.

Chris


> On Nov 8, 2016, at 4:11 PM, Kevin Rushforth  
> wrote:
> 
> Hi,
> 
> Please review the following fix to include jake-compatible versions of 
> module-info.java with our input bundles:
> 
> https://bugs.openjdk.java.net/browse/JDK-8169417
> http://cr.openjdk.java.net/~kcr/8169417/webrev.00/
> 
> These new files end up in a new "modules_src_jake" subdirectory of 
> modular-sdk, and are zipped up delivered to the JDK build as 
> javafx-exports.zip along with the existing directories. The existing jdk9 
> build will not be affected. The jisgaw/jake build will take the 
> modules_src_jake files in preference to modules_src.
> 
> NOTE: for the files that have a jake-equivalent, we will need to keep them in 
> sync going forward for as long as we need both.
> 
> -- Kevin
> 

Re: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles

[Mandy Chung]

Looks good to me.

Mandy

> On Nov 8, 2016, at 4:11 PM, Kevin Rushforth  
> wrote:
> 
> Hi,
> 
> Please review the following fix to include jake-compatible versions of 
> module-info.java with our input bundles:
> 
> https://bugs.openjdk.java.net/browse/JDK-8169417
> http://cr.openjdk.java.net/~kcr/8169417/webrev.00/
> 
> These new files end up in a new "modules_src_jake" subdirectory of 
> modular-sdk, and are zipped up delivered to the JDK build as 
> javafx-exports.zip along with the existing directories. The existing jdk9 
> build will not be affected. The jisgaw/jake build will take the 
> modules_src_jake files in preference to modules_src.
> 
> NOTE: for the files that have a jake-equivalent, we will need to keep them in 
> sync going forward for as long as we need both.
> 
> -- Kevin
> 

Modular build: understanding addExports

[David Hill]

There are times when you just have to break the rules :-)

And when it comes to module package internals visibility, we have to at least 
bend the rules a bit, particularly for testing.

In comes the 'addExports" file. These files in the FX tree are actually 
'argfiles' passed to javac and/or the java command.

Lets look at an example apps/tests/Robot

This test application uses non public/internal FX API, but is valuable to 
visually test that functionality.

To get around the visibility issue, we use --add-exports arguments to 
explicitly allow access. Looking at the file we see:

$ cat apps/tests/Robot/addExports
--add-exports=javafx.graphics/com.sun.glass.events=ALL-UNNAMED
--add-exports=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED

As the Robots.jar is an "un-named" automatic module, we export to the magic 
ALL-UNNAMED.

Nothing in the tool chain knows about this addExports file, so we do a small 
amount of Ant magic in nbproject/project.properties to add it to the compile 
and run paths. All of this means that 'ant clean run' just works :-) (But of 
course manually launching Robot.jar does not unless we add to the command line).

There are other uses worth mentioning.

Most of our unit tests have cases that need special access. These are handled 
in modules/*/src/test/addExports, and might need to be touched if you are 
adding a test case with new needs.

Lastly there are some really special cases in build.gradle that don't quite fit 
the pattern. The Decora build for example has the --add-exports explicitly in 
build.gradle.




--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

FX Modular build - FIVE Shocking things you need to know about the new build....

[David Hill]

What do you need to know about the new modular build (or how does this affect 
me ?)

I have covered the need for a new Gradle 3.1+, JDK 9 build 142+ already, so 
moving beyond that

FIVE Shocking things you need to know about the new build !!!  :-)

FIRST:

There is NO jfxrt.jar anymore. This quite a change, but the new practice has 
already been talked about before. The build produces:
rt/build/run.args
rt/build/compile.args
(Note: run.args was renamed from xpatch.args as the java command line arguments 
changed)
These are "argfiles" which is a way of batching up command line option for ease 
of use. Fyi, argfiles work with javac in JDK8, and were added to the java command in JDK9.

Assuming you have reset JDK_HOME to point to JDK 9 ea build 142+, then building 
an running an FX application from the command lines would look like this:
$JDK_HOME/bin/javac @_path_to_/compile.args -d build 
src/mytest/MyTestApp.java
$JDK_HOME/bin/java   @_path_to_/run.args -cp build mytest.MyTestApp

Please note that these arg files contain absolute paths to your repository 
artifacts. If you want to copy the artifacts (rt/build/modular-sdk) to another 
location, then there is a script (rt/tools/scripts/make_runargs.sh) to generate 
a new run.args file

There is a corresponding set of argfiles that contain the test "shim" classes 
as well as the full modules. These are testrun.args and testcompile.args. Because the 
test modules modules contain a module-info.class (it is filtered out when we copy to 
rt/build/modular-sdk) it is quite likely that you will see one or more:
WARNING: module-info.class not allowed in patch: (path to the module)
These are annoying and harmless, and there is nothing we can do to suppress 
them.

SECOND:
   The FX built class files are "target=1.9". This is required by javac when we 
are building modules. If you have an existing netbeans project, you may need to edit it 
to update the value. This also means that any application like an IDE that parses class 
files may have a problem with the newer version.

THIRD:
  Module test classes are now split apart. Before we had the "shim" classes and 
the unit test classes all in one hierarchy. This does not work so well with the modular 
build, and so the shim classes have been separated into a new hierarchy.

before:
   modules/javafx.base/src/test/...
now:
   unit tests in modules/javafx.base/src/test/...
   shims in modules/javafx.base/src/shims/java/

For unit tests, we rebuild the modules that needs shims again, but this time 
add in the shim sources. The resulting module is then passed into the unit test 
run using -patch-module.

FOURTH:
  In the past we often used jfxrt.jar via a bootclasspath. One side effect of this was 
"all permissions" for the FX classes, which matched how the bundled FX classes 
are treated in the JDK. This does not work with JDK9 and -patch-module.

If you run into security issues with a test application, then you will need to 
use a java.security.manager, and a policy file that starts with the one we 
generate during the test task of our build: rt/build/test.java.policy (again, 
one that contains absolute paths). It is reasonably easy to add to an ant file 
an action that will start with this file, and add in any test application 
specific additions, and the resulting file can then be used for the application 
run.

FIFTH:
  There are early access editions of IDEs. Let us know if you find ways to get 
these to work :-)
Netbeans: http://wiki.netbeans.org/JDK9Support 

Intellij: https://confluence.jetbrains.com/display/IDEADEV/EAP


--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

ACTION - JavaFX modular build is here

[David Hill]

The new modular build has been committed to 9-dev !!!

To ensure a continued happy development, please consider the following advice 
:-)

Clean up your old repository before syncing.
   gradle clean
consider (but not required)
  hg purge --all

unset JIGSAW_HOME   # this enviroment variable is no longer used in 9-dev

Download, install and verify you have the version you think you have.
Gradle 3.1+ [1]
JDK 9 build 142+ [2]
Ant 1.8.2  (note, that there are known issue with 1.9.x) [3]

Remember, if you still need to work with older workspaces like 8, keep gradle 
2.11 around, as Gradle 3.1 will NOT work. To help with this, I set to 
environment variables:
GRADLE2_HOME=__path_to_gradle_2
GRADLE3_HOME=__path_to_gradle_3
and then now add $GRADLE3_HOME/bin to my path as this is the default I use. But 
this allows me to use $GRADLE2_HOME/bin/gradle in older repositories.

At this point, sync in the new changes and build it !

export JDK_HOME=_path_to_jdk_9_ea_142+
$GRADLE3_HOME/bin/gradle clean sdk


[1] https://gradle.org/gradle-download/
[2] https://jdk9.java.net/download/
[3] https://ant.apache.org/bindownload.cgi


--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

Re: Fwd: Re: Marlin-Renderer and JavaFX

[Laurent Bourgès]

Hi,

I think we should wait for OpenJFX9 Jigsaw build patch that is coming and
rebase / test again the proposed patch Marlin for JavaFX.

Maybe jdk.internal.Cleaner or Unsafe.allocateDirect methods will be then
available to the javafx.graphics module or that may be acceptable to export
such jdk API to OpenJFX.

Finally I will have a look at the native prism sw code to see if I can fix
the forementioned method by adding 1 integer to give the output_minx
coordinate and only process pixels where the alpha coverage != 0.

Please give me your opinions.

Cheers,
Laurent

Le 7 nov. 2016 23:55, "Laurent Bourgès"  a
écrit :

> Jim,
>
> Here is the new patch:
> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/
>
> Changes:
> - cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner)
> - modified PrismSettings as recommended and renamed all Marlin properties
> to use the prefix 'prism.marlin'
> - SWContext: added Marlin SW support: I had to tweak the processed
> range[x; pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does
> not handle properly the bbox so it processes many extra pixels on the left
> side (empty coverage) = to be discussed as it can be fixed in the native
> prism-sw code ... See my comment in the code:
>
> +@Override+public void 
> setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+  
> final int pix_from, final int 
> pix_to)+{+// use x instead of pix_from as it 
> cause artefacts:+// note: it would be more efficient to skip 
> all those empty pixels [x to pix_from[+// but the native 
> implementation must be fixed too.+//
> pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from, pix_to, 
> rowNum);+pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, 
> pix_y, x, pix_to, rowNum);
>
> I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143
> (xpatch.args) with Ensemble8 + DemoFX.
>
> Maybe it is time to start the review for the FX enhancement ?
> https://bugs.openjdk.java.net/browse/JDK-8169270
>
> Cheers,
> Laurent
>
>
> 2016-11-04 19:55 GMT+01:00 Jim Graham :
>
>> On 11/4/2016 11:33 AM, Laurent Bourgès wrote:
>>
>>> For SWContext, I figured out that only openpisces.* classes were used
>>> directly via imports (hardcoded) so I left it unchanged. So you propose
>>> to generalize use of marlin or native pisces ?
>>>
>>
>> I didn't notice that, I was just searching on the use of
>> "doNativePisces".  We can look at that separately, and Kevin would know how
>> frequently we end up in the SW pipeline these days...
>
>

Re: Issues porting to Monocle EPD platform

[Erik De Rijcke]

Hi John,

In regard to your input issue. If it's a possibility, I'd recommend looking
at 'libinput'. It's an generic input abstraction library. It might be more
up to date and provide quirk fixes for (all kind of) input hardware.
https://wayland.freedesktop.org/libinput/doc/latest/
It's already the default input library used by X.org and Wayland
compositors but is in no way dependend on them.

regards,

Erik


On Mon, Nov 7, 2016 at 7:07 PM, David Hill  wrote:

> On 11/7/16, 12:55 PM, John Neffenger wrote:
>
> Hi John,
> I am probably the guy that will be looking over these, but I am in the
> middle of a big push. Feel free to ping me offline if I don't get back to
> you by early next week.
>
> Dave
>
> While porting OpenJFX to devices with an electronic paper display, I
>> resolved three issues in the graphics module that I thought I should pass
>> along. The following merge request on GitLab lists the issues and my minor
>> changes. See the Commits and Changes tabs in the middle of the page for
>> details.
>>
>> WIP: Patches to OpenJFX
>> https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1
>>
>> Did I understand the code correctly? I would appreciate any feedback.
>>
>> As a brief summary, the first issue, "QuantumRenderer modifies buffer in
>> use by JavaFX Application Thread," may be of general interest because it
>> occurs on the Monocle Headless and VNC platforms.
>>
>> The second issue, "zForce touchscreen input device fails when closed and
>> immediately reopened," might affect only my platform, or maybe just the
>> older Linux kernel and device driver I'm forced to use, but I couldn't find
>> a good workaround without duplicating the entire LinuxInputDevice class.
>>
>> The third issue, "Get two bytes for the Linux input event type, not
>> four," doesn't seem to cause any problems, but may still be worth fixing.
>>
>> Thank you,
>> John
>>
>
>
> --
> David Hill
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should survey
> the world."
> -- George Santayana (1863 - 1952)
>
>