Re: Netbeans "owning" Maven archetypes
Talking about the OpenJFX specifically case: I am personally open to make it as easy as possible to leverage the openjfx javafx-maven-artifact in NetBeans. Actually, it is the main procedure I use whenever I create a new JavaFX project: create a new project from an archetype, specify the org.openjfx... archetype, and then I manually add the javafx:run as a NetBeans action. If this can be made easier if the archetype has a nbactions.xml that is not causing regression for other IDE's or CLI, I think we should consider it, see https://github.com/openjfx/javafx-maven-archetypes/issues/7#issuecomment-824680476 - Johan On Thu, Apr 22, 2021 at 12:28 AM Will Hartung wrote: > On Wed, Apr 21, 2021 at 12:22 PM Ernie Rael wrote: > > > The point is that depending on a 3rd party project for functionality > > that NetBeans provides is a problem. But there is push back to provide > > even simple maven archetypes. And, at least possibly until now, little > > interest in supplying archetypes from NetBeans project. > > > > Then, quite frankly, the baby should be tossed out with the bathwater. > > If there's going to be this clash between the NB project and 3rd parties, > then NB should abandon anything related to third parties that they're > unwilling to maintain. > > Using your Java FX example, if the Java FX new project functionality is > that tied to a 3rd party artifact(s) that NB is unwilling/unable to > maintain, then the "New FX Project" functionality should be ripped out, and > let the FX project perhaps be aware of it. Then the FX project, should they > so desire, can create a NB plugin that can be installed by users that then > enable "New FX Project" functions, plus whatever else they want to add. > > It's a disservice to everyone to go half way. Again, here's something the > IDE is providing that the NB team and contributors can not fix. > > To quote Dr. Venkman: "That's bad." > > Now it would be a nice gift to wrap up the current FX tech in to a nice > project bundle that could be handed off to a/the 3rd party, to lower the > barrier to entry to get this going. But, it's just not right to leave stuff > dangling, ramshackled and broken with no real path to fix them. I think > having these broken things makes the project look bad. NB used to be very > polished. It was known for it's "one stop shopping". Download it, and > shazam, you got all of this stuff and functionality. No crawling the > internet, following blogs, downloading jars from who knows where. But > instead a nice, integrated "look at all the stuff that can be done". > > That agenda and mission has clearly changed, however formal or informally > it's been stated. > > I don't have any experience really with the other IDEs. I don't know if > OpenFX is doing addons for Eclipse or IDEA or, well, anything. I don't know > if it's necessary. > > But having these options in the IDE that flat out don't work, doesn't do > anyone any good. They give the wrong impression that the IDE supports > something. They don't work when used, and issues to fix them fall on deaf > ears, which also looks bad. The ecosystem is bitrotting around us. > > There should also be a conversation about what functionality the team is > willing to maintain, and which it feels should be up to 3rd parties and > should be yanked out, and perhaps how that transition could be > accomplished. > > Regards, > > Will Hartung >
Re: [VOTE] Release Apache VSNetBeans 12.4 Beta 2 with nb-javac (VSIX)
+1 (binding) On 2021/04/16 16:34:50, Jaroslav Tulach wrote: > Dear community, > vote for [Apache VSNetBeans 12.4 Beta 2](https://lists.apache.org/thread.html/ > r94a2caf8ada7c4ed023348c7581015b554eb86dd2192fe99f9ac%40%3Cdev.netbeans.apache.org%3E) > > has successfully finished and I believe it is time for one more vote: > > Let's vote about Apache VSNetBeans 12.4 Beta 2 complementary binary (again), > but this time with `nb-javac` included! > > This PMC vote is a follow up requested when issue > https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-563 > was resolved. > > Warning: this is potentially controversial vote and it may trigger some > discussion. Please use this thread only for voting (possibly with some > justification). If you want to discuss, please modify the subject: remove > [VOTE] and put there [DISCUSS], at least. Thank you for keeping this voting > thread clean. > > I am opening vote for a new complimentary binary. Source code remains exactly > the same as was a part of previous 12.4 Beta2 votings. The build > https://ci-builds.apache.org/job/Netbeans/job/netbeans-vscode/374/ > has however been executed with additional `-D3rdparty.modules=.*nbjavac.*` > option as documented in the build me: https://github.com/apache/netbeans/blob/ > master/java/java.lsp.server/vscode/BUILD.md as a result the new binary > contains following additional files in the `.vsix` ZIP file: > > +licenses/GPL-2-CP > +extension/nbcode/extra/ > +extension/nbcode/extra/.lastModified > +extension/nbcode/extra/config/ > +extension/nbcode/extra/config/Modules/ > +extension/nbcode/extra/config/Modules/org-netbeans-modules-nbjavac-api.xml > +extension/nbcode/extra/config/Modules/org-netbeans-modules-nbjavac-impl.xml > +extension/nbcode/extra/config/Modules/org-netbeans-modules-nbjavac.xml > +extension/nbcode/extra/modules/ > +extension/nbcode/extra/modules/ext/ > +extension/nbcode/extra/modules/ext/nb-javac-15.0.0.2-api.jar > +extension/nbcode/extra/modules/ext/nb-javac-15.0.0.2-impl.jar > +extension/nbcode/extra/modules/org-netbeans-modules-nbjavac-api.jar > +extension/nbcode/extra/modules/org-netbeans-modules-nbjavac-impl.jar > +extension/nbcode/extra/modules/org-netbeans-modules-nbjavac.jar > +extension/nbcode/extra/update_tracking/ > +extension/nbcode/extra/update_tracking/org-netbeans-modules-nbjavac-api.xml > +extension/nbcode/extra/update_tracking/org-netbeans-modules-nbjavac-impl.xml > +extension/nbcode/extra/update_tracking/org-netbeans-modules-nbjavac.xml > > > We are primarily voting on VSIX complimentary binary available here: > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.4-beta2/apache-netbeans-java-12.3.992.vsix > > GPG signature and SHA checksum are available along the binaries: > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.4-beta2/apache-netbeans-java-12.3.992.vsix.asc > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.4-beta2/apache-netbeans-java-12.3.992.vsix.sha512 > > Version of 12.4 Beta2+nbjavac VSIX is 12.3.992 as VSCode does not support > versions like “12.4.Beta2” and to be higher than previous 12.4-beta2 (without > nb-javac). > > Given the only difference from the previous (successful) vote is the > inclusion > of `nbjavac` GPLv2 with "Classpath Exception" component, we are primarily > voting about it and about > https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-563 > and whether PMC believes the "Classpath Exception" applies. > > My understanding is that "Classpath Exception" applies to "certain files ... > that ... contain the Classpath Exception" header. I did "find | grep" check in > https://lists.apache.org/thread.html/ > r821d9e9fdc8d9fd5663e7c326d25e4626e1a27eb13e45f4d639ea199%40%3Cdev.netbeans.apache.org%3E > and I believe all the important files contain such header. > > This vote is going to be open at least for 72 hours, vote with +1, 0, and -1 > as usual. My expectation is that most of the Apache individual contributors > currently employed by Oracle will abstain from the vote. However, I am > willing > to cast my own, personal "+1 (binding)" as a proof that I am really convinced > the "Classpath Exception" applies and I am not aware of any plot or trick > that > would indicate something else. > > Let it all begin! > -jt > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org
Re: Manipulating System Classpath with NetBeans (OpenJFX assumes classes can be loaded by FindClass)
Hi Matthias, Thanks, I missed this message, but the good thing is that by looking into it already, I could understand your PR more easily :) This seems a trivial fix, but of course it needs more review and testing. I don't see major issues with this one, so I hope we can integrate that in a few days. - Johan On 2021/04/08 11:19:34, Matthias Bläsing wrote: > Hi Johan, > > thanks for chiming in. I requested an issue yesterday evening, but is > was not yet made public. Maybe you could see if you can open up > 9069811. It is full version of the report and can be considered a > duplicate of JDK-8264886. It contains the crash info and instructions > to reproduce though. > > I created a PR with a reproducer and a fix here: > > https://github.com/openjdk/jfx/pull/458 > > The code to manually reproduce can be found here: > > https://github.com/matthiasblaesing/reproduce-openjfx-crash2/tree/287ec203da986dc761551687017d973d1b2fe87e > (this is current master) > > In the referenced issue a description is given what is needed to use > the reproducer. > > We can also take the discussion to the openjfx mailing list, as I'm > subscribed. > > Greetings > > Matthias > > > Am Donnerstag, den 08.04.2021, 07:56 + schrieb Johan Vos: > > Hi, > > > > I have some comments inline > > > > On 2021/04/08 03:28:10, Jaroslav Tulach wrote: > > > Thanks a lot guys for investigating JavaFX integration into NetBeans! I > > > still > > > love to use HTML/Java whenever possible and having a working WebView > > > integration is essential for that... > > > > > > > Some comments below > > > > > > > > On 07/04/2021 8:21, Matthias Bläsing wrote: > > > > > Hi Antonio, > > > > > > > > > > Am Dienstag, den 06.04.2021, 23:24 +0200 schrieb antonio: > > > > > [...] > > > > > Here is the stack trace for it (from hs_err_pid*): > > > > > > > > > > Stack: [0x7fa41ce47000,0x7fa41d646000], > > > > > sp=0x7fa41d6449c0, > > > > > free space=8182k Native frames: (J=compiled Java code, A=aot compiled > > > > > Java code, j=interpreted, Vv=VM code, C=native code) V > > > > > [libjvm.so+0x91203a] jni_CallStaticBooleanMethodV+0x7a > > > > > C [libjfxwebkit.so+0x5fd155] > > > > > JNIEnv_::CallStaticBooleanMethod(_jclass*, > > > > > _jmethodID*, ...)+0x85 C [libjfxwebkit.so+0x2a0d82a] > > > > > WTF::FileSystemImpl::makeAllDirectories(WTF::String const&)+0xda > > > > It seems "makeAllDirectories" > > > > (https://github.com/openjdk/jfx/blob/e0ce73a3c8d82d3274bd10799b530f397a90ba6 > > > > 0/modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp# > > > > L143) being invoked by a native thread does not use > > > > jvm->AttachCurrentThread. We'll have unexpected behaviour. > > > > > > > > This is a bug in libjfxwebkit that you may want to report. > > > > > > Right, as far as I know, the AttachCurrentThread call is prerequisite for > > > making calls to JVM. > > > > At first sight, this looks indeed something that needs to be fixed in > > OpenJFX. I filed an issue for that: > > https://bugs.openjdk.java.net/browse/JDK-8264886 > > > > > > > > > > C [libjfxwebkit.so+0x553707] > > > > > WebCore::StorageSyncManager::fullDatabaseFilename(WTF::String > > > > > const&)+0x27 C [libjfxwebkit.so+0x54e83a] > > > > > WebKit::StorageAreaSync::openDatabase(WebKit::StorageAreaSync::OpenDataba > > > > > seParamType)+0x3a C [libjfxwebkit.so+0x54f8a9] > > > > > WebKit::StorageAreaSync::performImport()+0x29 C > > > > > [libjfxwebkit.so+0x553f04] > > > > > WebCore::StorageThread::threadEntryPoint()+0xb4 C > > > > > [libjfxwebkit.so+0x29aa793] > > > > > WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+0x63 C > > > > > [libjfxwebkit.so+0x2a1253d] WTF::wtfThreadEntryPoint(void*)+0xd > > > > > > > > > > > > > > > There is no native frame and thus even if the thread itself would be > > > > > attached to the JVM as suggested in your second email, it would still > > > > > be missing a context to find that invoking java method and its class > > > > > loader. > > > > > > > > What people usually do when using JNI is to create
Re: Manipulating System Classpath with NetBeans (OpenJFX assumes classes can be loaded by FindClass)
Hi,
I have some comments inline
On 2021/04/08 03:28:10, Jaroslav Tulach wrote:
> Thanks a lot guys for investigating JavaFX integration into NetBeans! I still
> love to use HTML/Java whenever possible and having a working WebView
> integration is essential for that...
>
> > Some comments below
> >
> > On 07/04/2021 8:21, Matthias Bläsing wrote:
> > > Hi Antonio,
> > >
> > > Am Dienstag, den 06.04.2021, 23:24 +0200 schrieb antonio:
> > > [...]
> > > Here is the stack trace for it (from hs_err_pid*):
> > >
> > > Stack: [0x7fa41ce47000,0x7fa41d646000], sp=0x7fa41d6449c0,
> > > free space=8182k Native frames: (J=compiled Java code, A=aot compiled
> > > Java code, j=interpreted, Vv=VM code, C=native code) V
> > > [libjvm.so+0x91203a] jni_CallStaticBooleanMethodV+0x7a
> > > C [libjfxwebkit.so+0x5fd155] JNIEnv_::CallStaticBooleanMethod(_jclass*,
> > > _jmethodID*, ...)+0x85 C [libjfxwebkit.so+0x2a0d82a]
> > > WTF::FileSystemImpl::makeAllDirectories(WTF::String const&)+0xda
> > It seems "makeAllDirectories"
> > (https://github.com/openjdk/jfx/blob/e0ce73a3c8d82d3274bd10799b530f397a90ba6
> > 0/modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp#
> > L143) being invoked by a native thread does not use
> > jvm->AttachCurrentThread. We'll have unexpected behaviour.
> >
> > This is a bug in libjfxwebkit that you may want to report.
>
> Right, as far as I know, the AttachCurrentThread call is prerequisite for
> making calls to JVM.
At first sight, this looks indeed something that needs to be fixed in OpenJFX.
I filed an issue for that: https://bugs.openjdk.java.net/browse/JDK-8264886
>
> > > C [libjfxwebkit.so+0x553707]
> > > WebCore::StorageSyncManager::fullDatabaseFilename(WTF::String
> > > const&)+0x27 C [libjfxwebkit.so+0x54e83a]
> > > WebKit::StorageAreaSync::openDatabase(WebKit::StorageAreaSync::OpenDataba
> > > seParamType)+0x3a C [libjfxwebkit.so+0x54f8a9]
> > > WebKit::StorageAreaSync::performImport()+0x29 C
> > > [libjfxwebkit.so+0x553f04]
> > > WebCore::StorageThread::threadEntryPoint()+0xb4 C
> > > [libjfxwebkit.so+0x29aa793]
> > > WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+0x63 C
> > > [libjfxwebkit.so+0x2a1253d] WTF::wtfThreadEntryPoint(void*)+0xd
> > >
> > >
> > > There is no native frame and thus even if the thread itself would be
> > > attached to the JVM as suggested in your second email, it would still
> > > be missing a context to find that invoking java method and its class
> > > loader.
> >
> > What people usually do when using JNI is to create global references to
> > "jclass" and then reuse these global references in different threads.
> > These are thread safe and avoid being finding classes and methods all
> > the time.
>
> Yes, this is what native libraries should do. Before making calls from Java
> to
> JNI store references to essential Java classes (or object instances).
That should be fixed indeed (as part of
https://bugs.openjdk.java.net/browse/JDK-8264886 )
>
> > a) On the JNI_OnLoad method (when the library is loaded) people do a
> > "FindClass" as usual, and then create a new global reference to the
> > jclass for future use in different threads, and store it in a global C
> > variable. Could be something like:
> >
> > static jclass MyWhateverClass = NULL;
> >
> > ...
> >
> > JNI_OnLoad(...) {
> >// Find the class in OnLoad
> >jclass clazz = env->FindClass(...);
> >// And keep a NewGlobalRef for future use...
> >MyWhateverClass = env->NewGlobalRef(clazz);
> > ...
>
> That's the recommended approach. However it shall be stated that this is
> creating a (class loading) memory leak - it is not going to be possible to
> unload the JavaFX JAR file classes once this variable is initialized. Just
> FYI,
> I think we can live with such behavior.
>
> > b) In the native thread people call jvm->AttachCurrentThread (mandatory)
> > and can then use the MyWhateverClass without invoking "FindClass" again.
>
> +1
>
> > These "jclass" allocated with NewGlobalRef are thread safe, and can be
> > used by different native threads (invoking AttachCurrentThread first)
> > without problems.
> >
> > People usually cache also "jmethodID"s for future use, so they don't
> > have to lookup the methods on each call. These "jmethodID" are thread
> > safe by default, so there's no need to create a NewGlobalRef for them.
> >
> > For details on what JNI stuff is or is not thread safe [1] gives a nice
> > summary.
> >
> > So to summarize, I'm afraid they'll need to modify the code like so:
>
> A bugfix release of JavaFX would be the best solution. Hopefully it can be
> release soon.
>
> > a) Use AttachCurrentThread in native method invocations (they may be
> > doing it elsewere, but probably not in the stack trace you're sending).
> >
> > b) Cache the jclass(es?) they're using in native threads, by allocating
> > it(them?) in JNI_OnLoad using NewGlobalRef.
> >
> > c) Use these cached jclass(es?
Re: React Native Support for Cross Platform Mobile Apps Development
Hi, You can use JavaFX and Gluon Substrate (which will manage the building of the native apps for you) for free. The nag screen is part of Gluon Mobile, which adds specific mobile UI controls, and that saves you time. But it is not needed. You can also develop your own UI controls, or use the existing JavaFX ones. I think this is a healthy model. As a business, Gluon invest lots of time in Open Source projects. I think it is only fair that our engineers, who are working very hard on this, get paid for this. Our top 2 goals are: 1. developers should be able to use all software for free 2. companies who want commercial support, should be able to get that. Honestly, I don't really understand your point. You seem to be disappointed that we try to pay our engineers for working on cool stuff, while we also clearly contribute to improve the ecosystem for everyone. It seems you don't like our approach and rather go with the business approach used by Facebook and Google, and that is fine. But Gluon is not Facebook or Google. - Johan On 2021/01/24 03:07:19, Brain Rebooting wrote: > Hi all, > > Recently I learned javafx and after learning it, I thought that I would use > gluon mobile framework to build cross platform mobile apps. But I just saw > their pricing plan for individual developers, which is $499. I just got > astonished. Though they have a free license, which is not for commercial > use. I don't see any reason to spend this amount of money using such a > average tech. Instead, there are numerous open source mobile app solutions > available there. Like, React Native, Flutter and so on. Though I searched > about Cordova, but its webview is like a joke and performance is too not > satisfying. In that sense, as an open source IDE, being Apache Netbeans, > can I/we get support for react native/flutter? Which are true market leader > and true performant framework for mobile. I don't see any option to use > netbeans for using at least react native IDE. > At this moment, I feel little bit depressed and frustrated. > > Is there any hope of getting better react support and at least react native > support in netbeans IDE? > > Even the text editors like, sublime/atom/vs-code too capable of, for using > react native. > > Samiul Alom Sium > Associate of science in computer science, > University of the people, USA > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
