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.
