[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: BUG: zip file in sdk lib folder causes bugged JDK build
From:       Ty Young <youngty1997 () gmail ! com>
Date:       2018-09-26 7:17:51
Message-ID: f0f2c281-8b05-4465-7984-9a6ee2178e66 () gmail ! com
[Download RAW message or body]


On 9/22/18 9:01 AM, Kevin Rushforth wrote:
> I have never seen this problem. As for including src.zip in the "lib" 
> directory, that matches what the JDK has done for years. It may have 
> something to do with how you are building your JDK?


No, I compile JavaFX the same everytime - remove -Werror from the Linux 
gradle file and ignore all web tests via -x :web:test.

Maybe something was changed on the JDK side of things(an exclude list 
maybe)?


I don't remember having this issue before either compiling the 
pre-release versions of JDK11 and JavaFX either. I used both the JDK11 
and JavaFX 11 release branch for the source code.


> In any case, as mentioned in a previous email, I do not recommend 
> using a boot JDK with JavaFX modules to build FX. This is no longer 
> the expected way to build FX and will quite likely stop working at 
> some point.
>
> -- Kevin
>


Why exactly does having the modules in the JDK matter? Worse case 
scenario they just aren't used, right? Even if it isn't the "expected" 
way to build JavaFX, it still has advantages over using the standalone 
SDK and IMO should still be supported.


I'm having a hard time understanding why people at Oracle(or Oracle 
itself) seems to just want to drop features/tools/options and replace 
them with completely inferior, incomplete, or not as good replacements, 
like jLink(though the reduced file size is useful). You all must realize 
that by doing this that you are breaking projects that utilized these 
features/tools/options(like JPackager) and increasing the amount of work 
for IDE developers as they have to support whatever feature that is 
supported on JDK release X but not on release Y(they have to do this 
anyway for new language features, but why complicate more?).


To add salt to the wound, non LTS releases are only supported until the 
next JDK so you need to adapt your project for every few releases 
because of this. Netbeans *still* doesn't have a way to convert a non 
modular JavaFX application(where JPackager would've been used) to a 
modular one easily, and modules were released with *Java 9* and many 
third party libraries still haven't moved to modules yet either(not that 
I use them, I've just read elsewhere that they haven't).


I literally have a non modular JavaFX program that used to use jPackager 
that doesn't even compile anymore because Apache Netbeans 9 still hasn't 
added any code to remove jPackager from the ant scripts(or whatever). 
The project isn't worth anything but that isn't the point. Why break 
support for it if it isn't hurting anything? Why introduce something and 
then abort it like it's an unwanted baby? Isn't developing these 
features/tools/options and dropping them so fast costing time and money?


If there is a completely legitimate reason like is the case with Swing 
interop(as stated before) then that's understandable, but some minor 
bug(like above) that could probably easily be fixed is just kicking 
yourselves. No one wants to utilize a feature/tool/option only for it to 
be pulled from under them all of a sudden for no good reason or a 
*PROPER* AND *COMPLETE* replacement. It happens so often you can't 
depend on any new feature/tool/option since you have no idea if it isn't 
just going to get removed a few JDK releases later.


And no, a standalone SDK isn't a replacement for a JDK that has built in 
support for JavaFX. Does it continue to allow you to compile the 
project? Maybe? At what cost? HDD space, memory(see below), convenience, 
and reproducibility(multiple JavaFX versions potentially being used).



I didn't even know about it until I compiled and tested it, but a 
"client" build of the JDK uses less memory than a "server" variant 
regardless of the application itself. Without being able to build JDK 
with JavaFX support baked in, my application would be unnecessarily 
allocating more memory than it needs to. Most JDK/JRE builds are 
"server" builds and not "client" builds and use around 250MB which is 
insane and will cause people to complain. If there is no other *PROPER* 
AND *COMPLETE* way to reduce the insanely high memory usage of "server" 
JDK/JRE builds, is that use case not enough reason to support it?


(Side note: A "client" build of the JDK fails to finish a JavaFX test 
because it runs out of heap space. Guess I'll need to build a server and 
client variants from now on.)


>
> On 9/18/2018 7:30 PM, Ty Young wrote:
>> The zip file "src.zip" located in rt/build/sdk/lib/ after building 
>> JavaFX from source causes a bugged build of OpenJDK with JavaFX 
>> integrated into it. The build itself completes just fine, it's just 
>> that resulting build has issues.
>>
>> Because a zip file isn't a supported module format, Netbeans spits 
>> out an error saying as such when attempting to compile a JavaFX 
>> application(unsure if the project being modular matters here or not, 
>> but it is.). It also seems to cause any attempt to build a new build 
>> of OpenJDK to segmentation fault using that same bugged JDK as the 
>> boot jdk.
>>
>>
>> Is there somekind of special exception for unsupported module formats 
>> for the standalone SDK or is it just manually removed after it's done 
>> being compiled?
>>
>>
>> Not sure if it's worth creating a bug report for this since this 
>> seems to be some minor mishap. Including a zipped file of the source 
>> code in a lib file doesn't make a whole lot of sense to me... I would 
>> think it should be in the parent directory(rt/buid/sdk), next to the 
>> legal and lib folders.
>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]