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

List:       openjdk-openjfx-dev
Subject:    Re: error in tutorial
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2019-12-31 18:17:09
Message-ID: 52b87213-2e8b-7f64-75fc-281c9a93a940 () oracle ! com
[Download RAW message or body]

Ignoring jmods for a moment, since those are only intended to be used by 
jlink to produce an image that includes the modules (jmods are not a 
runtime format)...

The issue being caused by the src.zip in the lib directory of the JavaFX 
SDK seems more like a problem with the IDE(s) in question than with the 
JavaFX SDK. Both javac and java are perfectly happy with a module path 
that points to the lib directory, and will only consider the .jar files 
in that directory, ignoring other files. I note that in addition to 
src.zip, the lib directory contains several native libraries on Linux 
(*.so) and Mac (*.dylib).

While we could relocate just the src.zip file, as a workaround for what 
looks like an IDE problem, it isn't as trivial as Ty's post suggests. 
For one thing, this would be an incompatible change (although a minor 
one), and would require a CSR. I am not in favor of this change, but we 
can discuss it on this list if others feel differently. Also, as Johan 
pointed out, we will need a bug in JBS to track this.

-- Kevin


On 12/30/2019 8:55 AM, Anthony Vanelverdinghe wrote:
> Hi
>
> Some observations:
> This is the mentioned e-mail: 
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html
> The lib folder contains a src.zip file, both in JDK 13.0.1 and in 
> JavaFX SDK 13.0.1, so this is consistent.
> For NetBeans and IntelliJ IDEA (I didn't check Eclipse):
> - neither supports jmod files in libraries (see [1])
> - both support selecting individual jar files, after which things work 
> as expected
> - neither constructs an optimal modulepath, even if the application is 
> modular
>
> So I believe that this is mostly just a documentation issue: rather 
> than saying "add the lib folder of the SDK" it should say "add all jar 
> files in the lib folder of the SDK". Additionally, IDEs should be 
> improved to support jmod files in libraries, and to construct optimal 
> modulepaths for modular applications.
>
> Kind regards,
> Anthony
>
> [1] https://youtrack.jetbrains.com/issue/IDEA-171448
>
> On 28/12/2019 20:11, Ty Young wrote:
>>
>>
>>
>>
>>
>> On 12/28/19 4:53 AM, Johan Vos wrote:
>>> Hi Ty,
>>>
>>> Since I have absolutely no idea what you are talking about, I have a 
>>> few questions:
>>>
>>> 1. "... push changes to the repo..."? -> It would help giving a bit 
>>> context instead of talking about "the repo". Since this is the 
>>> openjfx-dev list, chances are high you're talking about the JavaFX 
>>> repository at https://github.com/openjdk/jfx. In that case, please 
>>> read the README and CONTRIBUTING files there for advice on how to 
>>> propose/make changes (note that this will probably take longer than 
>>> 1 minute, as we have strong quality checks in place). If you talk 
>>> about a different "repo", please follow the explicit or implicit 
>>> rules on that repo(sitory). For example, if you talk about 
>>> https://github.com/openjfx/openjfx-docs , please create an issue and 
>>> file a PR, and work with the community to get it accepted. (note 
>>> that in this case, this should not be discussed on the openjfx-dev 
>>> list (note the *dev*)).
>>
>>
>> This is not an issue of documentation. IDEs can and do provide the 
>> ability to designate an entire folder as a location of project 
>> libraries. You can specify a directory manually via command line in 
>> which contains Java 9 modules. To continue to entertain the idea that 
>> this is an issue of documentation is simply crazy. It's an easily 
>> fixable technical error.
>>
>>
>>>
>>> 2. You refer to informal or formal talks you had, but it is totally 
>>> unclear to me who you talked to about what. Frankly, we spent lots 
>>> of time moving all code and as much as possible the documentation to 
>>> github, so we can easily track discussions. (for JavaFX bugs, we use 
>>> JBS, so that can be discussed there) If someone said "it’s the way 
>>> we’ve always done it”" please refer to the issue where your request 
>>> has been made and subsequently rejected, so I can have a look at the 
>>> context,
>>
>>
>> It was an email a very long time ago on this list. Too lazy to dig it 
>> up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
>> time ago at this point.
>>
>>
>>>
>>> 3. Can you write a few words about what the word "Community" means 
>>> to you? Many people in the JavaFX Ecosystem spent tons of spare time 
>>> in making the JavaFX "Community" a friendly place. I'm interested in 
>>> your opinion about that word. To give a few options, does it mean
>>> A: I insult people and companies, use words like "smoking shrooms" 
>>> and "stubborn" and I expect everything I think about to be fixed 
>>> magically (since I suppose the volunteers have no life apart from 
>>> doing what I want them to do)
>>
>>
>> "community" is a funny word to describe JavaFX given it is 100% owned 
>> by Oracle and which no one(AFAIK) can contribute to without signing 
>> away their rights to their own code.
>>
>>
>> If this was a feature request I'd understand this nonsense but that's 
>> not at all what this is. This is a self created, self perpetuated, 
>> and needlessly self harming *technical* error defended using the 
>> worst possible defense against very real issues(the creation of this 
>> thread is proof). Source files(or zips containing such) are not 
>> libraries(AKA "libs") and it causes IDE issues(among other things). 
>> The fix is *really* simple.
>>
>>
>> and the whole (in essence) "everyone who works on JavaFX is a someone 
>> doing it in their free time is BS. Oracle developers are payed to 
>> work on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
>> (presumably) the Gradle script. If someone with basically no 
>> knowledge of Gradle such as myself can scan through a file or use 
>> ctrl + f and read variable names then I'd hope someone with actual 
>> experience could do better. Maybe I'm wrong and am the one in 
>> actuality that is smoking shrooms.
>>
>>
>>> B: I friendly discuss issues and opportunities with fellow community 
>>> members, where I respect other opinions, keep discussions polite and 
>>> technical.
>>
>>
>> That's funny because I seem to remember during a JDK(or maybe it was 
>> exclusively JavaFX?) event that a presenter made a rather rude joke 
>> about my multi-threading issue I brought up on this list a long time 
>> ago. I don't remember specifically who made the joke but I do know as 
>> someone who watches said events on YouTube that those events are very 
>> incestuous. I guess because it was the other way around that it was 
>> OK though.
>>
>>
>> TL;DR: People in glass houses shouldn't throw stones.
>>
>>
>>> C: somewhere between A and B?
>>>
>>> - Johan
>>>
>>>
>>> On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997@gmail.com 
>>> <mailto:youngty1997@gmail.com>> wrote:
>>>
>>>
>>>     On 12/27/19 4:40 PM, John-Val Rose wrote:
>>>     > Ty,
>>>     >
>>>     > If it’s so easy to fix then why don’t you just fix it?
>>>
>>>
>>>     I don't exactly have the ability to directly push changes to the
>>>     repo...
>>>
>>>
>>>     >
>>>     > John-Val
>>>     >
>>>     >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997@gmail.com
>>>     <mailto:youngty1997@gmail.com>> wrote:
>>>     >>
>>>     >> 
>>>     >>> On 12/27/19 4:19 AM, Johan Vos wrote:
>>>     >>> Hi David,
>>>     >>>
>>>     >>> What tutorial are you talking about? If you refer to
>>>     https://openjfx.io,
>>>     >>> that is a community-initiative, developed at
>>>     >>> https://github.com/openjfx/openjfx-docs .
>>>     >>> So if you have issues and PR's, that is the place to submit
>>>     and discuss
>>>     >>> with the other contributors to that site.
>>>     >>
>>>     >> Only the Netbeans section has a warning telling you to delete
>>>     src.zip. Neither Intellij nor Eclipse do.
>>>     >>
>>>     >>
>>>     >> A user shouldn't have to do that anyway though! This could be
>>>     easily fixed. Literally all you need to do is in this section:
>>>     >>
>>>     >>
>>>     >> // Zip module sources for standalone SDK
>>>     >>      //
>>>     >>      // NOTE: the input is taken from the
>>>     modular-sdk/modules_src dir
>>>     >>      // so that we don't have to duplicate the logic and create
>>>     another
>>>     >>      // temporary directory. This is somewhat inelegant, since
>>>     the bundled sdk
>>>     >>      // and the standalone sdk should be independent of one
>>>     another, but seems
>>>     >>      // better than the alternatives.
>>>     >>      def zipSourceFilesTask =
>>>     project.task("zipSourceFilesStandalone$t.capital", type: Zip,
>>>     dependsOn: buildModulesTask) {
>>>     >>          destinationDir = file("${standaloneLibDir}")
>>>     >>          archiveName = standaloneSrcZipName
>>>     >>          includeEmptyDirs = false
>>>     >>          from modulesSrcDir
>>>     >>          include "**/*.java"
>>>     >>      }
>>>     >>
>>>     >>
>>>     >> change:
>>>

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