Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

[victor . drozdov]

On 12/2/17 7:11 AM, Kevin Rushforth wrote:




Michael Hall wrote:


On Dec 2, 2017, at 8:31 AM, Kevin Rushforth 
> wrote:




Michael Hall wrote:


On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com 
 wrote:


Kevin,

Please review the changes about copying classpath entries on Mac 
and Windows.


JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033
Webrev: 
http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 



Sorry, to comment on this when it is not my place.
But I had looked at this sometime ago and it made no sense.
For the Mac you have…

-Files.copy(new File(srcdir, fname).toPath(), new 
File(javaDirectory.toFile(), fname).toPath());
+writeEntry(new FileInputStream(new File(srcdir, 
fname)),
+   new File(javaDirectory.toFile(), 
fname).toPath());


What is the difference here? You are just changing the method of 
writing the file. Otherwise locations are identical.
Assuming the first way isn’t working, why would the second way do 
better?




writeEntry creates the directory before copying (and also opens the 
file using an InputStream, but its the former that is the main part 
of the fix).



I had just noticed that was different and wondered if it was the fix.
Which is fine.
Although maybe creating the directory and then do the Files.copy 
might be clearer rather than someone later trying to figure out what 
makes the writeEntry call necessary.




Perhaps Victor can comment about this. Since many of the other copy 
operations also use writeEntry, it seems fine to me.


-- Kevin

writeEntry() is supposed to be used for the operations where we need to 
create a directory and then do Files.copy(). I see no reason to avoid 
using it here. Linux bundler is also implemented this way.


/ private void writeEntry(InputStream in, Path dstFile) throws 
IOException {//

//Files.createDirectories(dstFile.getParent());//
//Files.copy(in, dstFile);//
//}/

--Victor

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I am still working on all the necessary changes to actually allow openjfx
to compile.
Tons to learn in that arena and I know the code as it is written won't
totally work.
For example one can no longer:

#include "com_sun_glass_ui_Robot.h"

as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp

But I am not sure how those headers are generated and if I can just simply
change
it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).

On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen  wrote:

> I have created a (small) proposal (building on the work of Benjamin
> Gudehaus) about moving some classes in to the public API so that TestFX (a
> JavaFX UI testing framework) can continue to work with future JDK releases.
> The somewhat nicely formatted proposal can be found as a Github gist:
>
> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19
>
> All suggested changes can be found by using Github Compare View:
>
> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5e1f4f1cb8f204
> 30feaa53b6...master
>
> But I have copied it to this email for convenience:
>
> --- PROPOSAL ---
>
> TestFX, the JavaFX GUI testing framework currently requires 4 (four)
> classes that are part of the JDK's private API. They are:
>
> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/
> openjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/
> main/java/com/sun/glass/ui/Application.java)
> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/
> openjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/
> main/java/com/sun/glass/ui/Pixels.java)
> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/
> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/
> com/sun/glass/ui/Robot.java)
> [com.sun.javafx.application.ParametersImpl](http://hg.
> openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/
> javafx.graphics/src/main/java/com/sun/javafx/application/
> ParametersImpl.java)
>
> In order to compile the project with Java 9, we use the following flags:
>
> ```sh
> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx
> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx
> ```
>
> If the --add-exports flags are disabled in a future Java release TestFX
> will require these four classes to be moved into the public API to
> continue working.
>
> While these classes are probably not very useful for applications to use
> directly, any JavaFX application wanting to write UI tests will most likely
> use TestFX and thus they will indirectly be using these classes.
>
> JavaFX internal tests also use these classes for essentially the same
> purpose (UI tests).
>
> ### Details of Usage For Each Private API Class
>
>  com.sun.javafx.application.ParametersImpl
>
> # TestFX Usage
>
> ```java
> ParametersImpl parameters = new ParametersImpl(applicationArgs);
> ParametersImpl.registerParameters(application, parameters);
> ```
>
> The parameters are set on a constructed Application.
>
> # Suggested Public API Replacement
>
> `javafx.application.Application`:
>
> ```java
> /**
>  * Sets the parameters for this Application.
>  *
>  * 
>  * NOTE: this method should not be called from the Application constructor,
>  * as it will return null. It may be called in the init() method or any
>  * time after that.
>  * 
>  *
>  * @param parameters the parameters to set for this Application
>  */
> public final Parameters setParameters(String... parameters) {
> ParametersImpl parameters = new ParametersImpl(parameters);
> ParametersImpl.registerParameters(this, parameters);
> }
> ```
>
>  com.sun.glass.ui.Application
>
> # TestFX Usage
>
> ```java
> return Application.GetApplication().createRobot();
> ```
>
> The Application class is used to instantiate a Robot.
>
> # Suggested Public API Replacement
>
> `javafx.application.Application`:
>
> https://github.com/brcolow/openjfx/blob/master/modules/
> javafx.graphics/src/main/java/javafx/application/Application.java#L527
>
>  com.sun.glass.ui.Pixels
>
> # TestFX Usage
>
> ```java
> @Override
> public Image getCaptureRegion(Rectangle2D region) {
> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> {
> Pixels glassPixels = useRobot().getScreenCapture(
> (int) region.getMinX(), (int) region.getMinY(),
> (int) region.getWidth(), (int) region.getHeight()
> );
> return convertFromGlassPixels(glassPixels);
> });
> }
>
> private Image convertFromGlassPixels(Pixels glassPixels) {
> int width = glassPixels.getWidth();
> int height = glassPixels.getHeight();
> WritableImage image = new WritableImage(width, height);
>
> int bytesPerComponent = glassPixels.getBytesPerComponent();
> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) {
> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels();
> writeIntBufferToImage(intBuffer, image);
> }
>
> 

Re: Error on build

[Michael Ennen]

Try changing line 275 of the root build.gradle from:

ext.IS_64 = OS_ARCH.toLowerCase().contains("64")

to:

ext.IS_64 = true


On Sun, Oct 8, 2017 at 6:24 PM,  wrote:

> Hi,
>
> I possess an AMD 64 bit machine.
>
> My JDK_HOME points to a 64 bit JDK.
>
> MS C++ redistributables reported as installed on my machine (determined by
> control panel -> uninstall a program -> reviewing resulting list of
> installed sw) report both 32 and 64 installations.
>
> MS VS was installed as I reported below.
>
> AFAIK Cygwin is not versioned x86 or 64-bit or if it is (can't actually
> recall) it cannot effect the result of the build.
>
> Are they any other factors at play I am unaware of?
>
> Cheers.
>
>
> On Sunday, October 8, 2017 6:45 AM, David Bimamisa <
> ketch...@googlemail.com> wrote:
>
>
>> Which version of JDK are you using? 64-bit or 32-bit?
>> I remember getting these types of errors only if there was a mismatch
>> between the JDK and c++ compiler machine type
>> As noted in  wiki: "the version of the JDK you have set as JDK_HOME will
>> determine whether you build 32 or 64 bit binaries"
>>
>>
>> Regards
>> David
>>
>> 2017-10-07 1:09 GMT+02:00 :
>>
>>> This is the result of using *VS 2017 CE- every option selected,
>>> downloaded and installed*
>>>
>>> I would say  there is an external symbol _fltused (float used?) and a
>>> few other such errors and also the assumption that the builder is on a 32
>>> bit machine ?? (see final error).
>>>
>>>
>>> _fltused
>>> __GSHandlerCheck
>>> __security_check_cookie
>>> powf
>>> __imp_IsProcessorFeaturePresent
>>> _DllMainCRTStartup
>>>
>>> and
>>>
>>> C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/LIB\MSVCRT.lib :
>>> warning LNK4272: library machine type 'X86' conflicts with target machine
>>> type 'x64'
>>> C:\cygwin64\home\mdbg\rt\modules\javafx.graphics\build\libs\jsl-decora\win\decora_sse.dll
>>> : fatal error LNK1120: 7 unresolved externals
>>> :graphics:linkDecoraNativeShadersWin FAILED
>>>
>>>
>>> MS Studio 2017 CE doesn't ask you if you want a 32 bit or 64 bit
>>> installation, only WHERE you want it installed.
>>>
>>> The user choice of Program Files vs Program FIles x(86 ) might
>>> constitute a choice of sorts so after failing with the default x86 place, I
>>> uninstalled everything and tried the other only to have it fail much
>>> sooner. The first fail (x86) actually got through building part or most of
>>> .graphics, which gave me false hope.
>>>
>>> That non-question usually means the install itself knows what to do or
>>> has a preference and in this context especially  - VS 2017,install- should
>>> not lead to x86  vs 64 bit  type problems .
>>>
>>> Also, the instructions on the wiki , outdated I am told, also say the
>>> default project is sdk. I do not think this is the case. It seems mandatory
>>> to type "sdk" after gradle to hit the sdk build task.
>>>
>>> Any help or experiences from anyone is much appreciated.
>>>
>>>
>>>
>>> Full output:
>>>
>>> SSEPhongLighting_POINTPeer.obj : error LNK2001: unresolved external
>>> symbol _fltused
>>> SSEPhongLighting_SPOTPeer.obj : error LNK2001: unresolved external
>>> symbol _fltused
>>> SSESepiaTonePeer.obj : error LNK2001: unresolved external symbol _fltused
>>> SSEUtils.obj : error LNK2001: unresolved external symbol _fltused
>>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external
>>> symbol _fltused
>>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external
>>> symbol _fltused
>>> SSEPhongLighting_DISTANTPeer.obj : error LNK2001: unresolved external
>>> symbol _fltused
>>> SSEBrightpassPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEColorAdjustPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEInvertMaskPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_SRC_INPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_SRC_OUTPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_SRC_OVERPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol _fltused
>>> SSEBlend_REDPeer.obj : error LNK2001: unresolved external symbol _fltused
>>> SSEBlend_SCREENPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_SOFT_LIGHTPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_SRC_ATOPPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_HARD_LIGHTPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_LIGHTENPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>> SSEBlend_MULTIPLYPeer.obj : error LNK2001: unresolved external symbol
>>> _fltused
>>>