Netbeans 9-beta1 -- AssertionError during Netbeans start-up #382
Comments
|
Only 2.X versions of the plugin (e.g.: 2.0.0.2) is expected to be used in NB 9. Though, I would have expected older versions to work too. Can you try 2.0.02? Non-existent folders should be normal on the classpath. It appears because you have applied the Groovy plugin and so - in principle - there is such an output directory. I don't think NB should be bothered about it. Anyway, I will investigate this further. |
|
I have looked at NB's sources and it seems that it expects those URL's to end with a slash. I'm not sure if it is really alright NB to expect that but it doesn't seem to be needed at the point where it checks it. So - for now -, the easiest workaround is to remove the "-J-ea " from netbeans.conf. This issue was probably there in older versions of NB as well but assertation were not enabled in the past. |
|
I have pushed same changes to the nb9 branch which should fix your problem (even with enabled assertion). You can try if it works for you. |
|
Will I see this on the Plugin update?
I have checked the Netbeans 9 IDE log on my Linux PC and there is not reference to that folder in that log. So calls upon groovy main src and class files is both plain mysterious and may relate to Windows or Gradle on Windows. If you look into the JIRA report; purging ALL and EVERY gradle cache resolved the problem temporarily. |
|
For now, it is only on the "nb9" branch which you could build manually (the plugin should buil out of the box but you can also set up as described on the development page if you want to build it the same way as I do). You shouldn't be bothered about |
|
Hi and thanks for that. I am unlikely to have time to build with Java 6 though. I need to clarify the situation regarding this erroneous folder. The: The flaw as I see it, is that something expects that path to exist. It is an assumption. And there are errors popping up because some assumption some place is incorrect. That might be one or a combination
When software fails looking for something that should not be and is not there ... You have bugs that are merely symptoms. And as I have been experiencing with Netbeans 9 very, very slow and unresponsive. Yes, I believe it is relevant. |
|
No one is asking to build anything with Java 6, I think. NetBeans doesn't run on Java 6, though it is needed for building the plugin: https://github.com/kelemen/netbeans-gradle-project/wiki/Development For now, the fix is only on the "nb9" branch which you could build manually (the plugin should build out of the box but you can also set up as described on the development page if you want to build it the same way as Attila does). Here is the "nb9" branch: https://github.com/kelemen/netbeans-gradle-project/tree/nb9 Note that indeed build/class/groovy/main is not in your project structure, it is a 'build' folder, i.e., that is output from the Gradle process, via the Gradle plugin, when it succeeds in doing your build. Maybe @kelemen can make an NBM available that @aplatypus can use to try it out without needing to build anything? Happy to try it too and provide feedback. |
|
As Geertjan said, there is no need to set up Jave 6 to build one of the subproject. The only reason I have to is because if I didn't people would need the version of Java used for building to evaluate Gradle scripts (i.e. you could only develop project conveniently targeting that Java version or higher). This is irrelevant if you are building it for yourself. Anyway, I have built the plugin and uploaded to here https://www.justbeamit.com/x8v3k (I have never used this file sharing site, so I don't know how long will they keep it). |
|
Anyway, your assumptions are wrong. Given that I know the code, I hope you can trust me that I know what the problem is if I claim so :). NB doesn't "crashes" because it tries to access a non-existent folder (the only reason you see the path is because it logically exists) and having non-existent folders on the classpath is completely normal in NB (because the output folder might be on the classpath of other source sets and obviously you can't expect the build output folder to exist). |
|
I have found another place from where URLs without trailing slashes can creep in, so I have created another build: https://www.justbeamit.com/7m47h |
|
Hi, I built with Java 8 u162 and gradle 4.6. I set the Netbeans exe to point at my Netbeans 8.2. It doesn't fix the problem. I have attached the log files. There's one query on the Gradle plugin. The version from the Plugin Portal shows-up as v1.4.3. The build project is building on a v2.0.x.x lineage. plug in portal built version: I configured the project with the attached root One thing that caused me trouble is that a grep of the whole project did not find the Anyway no cigar as yet. This doesn't look like a plug-in error. Sure the plugin is just the victim of bad data, or bad input. Of course if I remove the Gradle plugin from a Gradle project, there will be no gradle-plugin errors. That actually demonstrates nothing. What I suggest you do is capture such BAD data and add logging to identify the source. Gradle info: |
|
@geertjanw ... Concerning the mooted Groovy path. I am afraid you are not listening to me. Out of 40 project build folder AFTER a complete Also there are no custom components involved. The error occurs with ANY GUI screen but it is not limited to Netbeans 9 / Gradle builds on Windows passes several path names to directories that Do Not exist. And ought Not to exist. Of course when given a non-existent directory to process we have errors. Netbeans 9 on Linux, Netbeans 8.2 on both Windows and Linux don't look for that folder tree. But as before, the problem appears to stem from something in a cache some place. If I ran the Linux project enough times I might see it. |
|
There is no Groovy at all in NetBeans 9. Groovy modules have not been donated yet to Apache, so it is completely impossible for any referenced at all to anything related to Groovy to be in NetBeans 9. It is physically impossible since nothing at all related to Groovy is in NetBeans 9. |
|
unfortunately ...
|
|
Since, you could build the plugin, I assume the download link is no longer relevant. The I believe you that it doesn't exist but it doesn't matter if it exists or not. As you can see in NB's sources, the exception has nothing to do with the folder existing or not. The reason it is there because the 'groovy' plugin were applied to (some) of your projects but since you have no groovy sources, then Gradle won't create the empty folder for nothing. This is all fine and normal. The issue is that NB checks if the URL it got from somewhere (obviously provided by this plugin) doesn't end with a '/' character. If the issue still persists for you (I have uploaded some changes which you might want to try), I'll have to look harder in NB's code to find from where it gets these URLs. |
|
Also, after building the plugin from sources and installing it in the target IDE, please exit NB, remove the Gradle cache (.nb-gradle/private/cache) and start NB again to avoid those bad URLs to creep in from the cache. |
Cache-sI demonstrated that cleaning the cache is a workaround for this but in the JIRA bug thread. However I believe that's part of the bigger picture. Netbeans and individual plugins Must deal effectively with incorrect Cache contents. It is impractical to have to clean-out everything before starting your IDE. The other huge problem is the performance hit that comes with all the Exceptions. If as asserted these file paths are optional then they ought to be coded that way and not cause exceptions. There is a cost in the JVM on exceptions. After the cache-s have been blown away, you need to rebuild the GUI project in order for any screens to load. To test the fix, you must then exit Netbeans. Upon restart with a built GUI, Netbeans should show the GUI panels in design. acceptance criteriaIn my book, we need to be confident that GUI screens will load in Netbeans every time Netbeans is started. The gradle plugin acceptance test
Thanks for looking into it. It seems that Apache Netbeans is NOT supporting Gradle. For the time being our people will have to with 8.2. Which works. That's probably good enough for 3 - 5 years. For this bug, I may get time to make a small project and try to reproduce it. I can't do much on my boss' clock since we are not going to be able to use NB9 in the next year or so. |
|
Many people will not be able to use NB9 since it is only focused on Java SE, not EE, not JavaScript, not Groovy, not PHP. A lot has not been donated to Apache yet. NB9 is definitely not equivalent to 8.2 and no one has said it is. NB is undergoing transition to Apache and a lot has not been donated yet. |
|
Hi ...
Thanks very much for clarifying that situation. This was NOT at all
clear. It makes more sense too.
I suggest the features page:
- http://netbeans.apache.org/download/nb90/index.html
Needs to announce/state these constrictions. *Most* people I have
connection with seem to consider Netbeans 9 to be Netbeans 8 with new
stuff. Such as Netbeans 8 was built on Netbeans 7.
In the open source parlance, it sounds like Netbeans 9 is a fork with
"core" functionality. This makes some sense if the world was a Java
world. Sadly it is no longer.
A very LARGE part of my employer's on-going technical development is due to
the Oracle refusal to build a replacement secure container for Java
applets. We have several mobile applications. These are Gradle,
Javascript/Typescript and Groovy intensive technologies. The gentleman who
sits next to me has IceTea which works with modern browsers. It is
irrelevant now, so we have shifted back to the age of VisualBasic for
enterprise applications. That legacy rewrite is not user/customer driver,
it is just because there is no more Java in the browser.
To be brutally honest VisualBasic was a lot safer and less error prone than
Typescript/Javascript. (*I digress*)
Developer people need to Understand that the next Netbeans (9) will be
*branch* or *diversion* from the known Netbeans 8 <-7<-6 evolution, as we
know it.
One thing is for sure, since I can't use Netbeans 9 in my Day Job along
with my fellow team members, I need to evaluate the alternatives. I feel
it is a shame in a way. Alas, I've witnessed the death,perversion and
neutering of many an operating system and development environment. For
example Netbeans is still the only IDE that really bought into and
Implemented the DevOps idea. *Wow*
One other point. We have quite a few Solaris systams. Will there be
something Netbeans (*legacy*) 8.3 or something?
…On 2 May 2018 at 13:04, Geertjan Wielenga ***@***.***> wrote:
Many people will not be able to use NB9 since it is only focused on Java
SE, not EE, not JavaScript, not Groovy, not PHP. A lot has not been donated
to Apache yet. NB9 is definitely not equivalent to 8.2 and no one has said
it is. NB is undergoing transition to Apache and a lot has not been donated
yet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#382 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEF1AfckiyJP9L-N9ySJ4NJJMNmgubNks5tuSI5gaJpZM4TfE34>
.
--
aloha,
\_w_/
___________________________________
º http://www.facebook.com/will.2016
|
|
So many misunderstandings here, not really sure where to begin. Maybe it’s best to sign up to the mailing lists via netbeans.apache.org and follow ongoing discussions. Everything that is currently in 8.2 will eventually be part of Apache NetBeans, it’s just taking a while to get everything from Oracle to Apache and we’re doing it in stages. Again, best to join the mailing lists to follow the ongoing developments. |
|
This issue is most likely present with all versions of NB, the only reason you don't see it because assertations are disabled in the NB releases (and as I have heard it will be so in NB9 release), so you won't notice this issue in the released version of NB 9. If you want to workaround the issue you can still remove the "-J-ea" from the NetBeans config (though if you are just testing, then of course you don't want to do that). This is - probably - not a cache issue, I just wanted to make sure. Of course, noone wants you to follow a workflow to delete the cache all the time, it is just for testing (to eliminate one source of uncertainty). However, since the issue still exists for you, it means there is still some place where non-existent paths are converted to URLs without a trailing slash, so I will keep looking. |
problem ##
There is a problem with the Gradle 1.4.3 and Netbeans 9-beta1 and Java 10. an
AssertionErroris raised when attempting to load a palette for the Netbeans Designer (see stacktrace below). By comparison the plugin works correctly with Netbeans 8.2 with NoAssertionError.Please refer to the attachments and logs on the Netbeans JIRA issue, here.
The
AssertionErrorconcerns loading of the Swing Designer pallette. This error also occurs if you switch to a GUI designer page -- Palette loading just hangs. TheAssertionErrorexhibits as a "slowness problem" much of the time. Sometimes theAssertionErrorwill be reported directly by the Netbeans GUI.The stacktrack shows an error on a non-existant foler.
build/classes/groovy/mainWhich is not an expected folder path for this project. The project folder tree is shown below. There are NO file under
src/test/groovy/at this point. There is nosrc/main/groovytree and none is required -- the project code is pure Java.The test source would give:
build/classes/groovy/testin any case.---[ Netbeans stacktrace ]---
environment
The text was updated successfully, but these errors were encountered: